The G.A.R.E.V. is a device intended for exploring remote environments using any standard web browser over the internet. It has two servos and a camera mounted on the top to enable pan and tilt viewing of the surrounding environment, as well as a temperature sensor to provide some rudimentary environmental information. More sensors could be added at a later stage for expansion. It makes use of software running on a nearby PC to capture the video from the camera and to send/receive data to/from the Bluetooth radio on-board the vehicle. The video is sent over a separate 2.4GHz link, not via the Bluetooth connection. The web interface was written in Java, the server software to run on the PC in Python and the microcontroller on the vehicle in ASM.
The idea for this project is based around the fact that people are becoming more and more interested in automated control and surveillance systems for use in the home. The amount of people designing and building home automation systems based around a computer is growing rapidly, and these systems are usually used both for enhanced living and security. Cameras form a major part of these systems, and are usually quite an expensive part at that, especially if the user needs to cover a large area of their home requiring many cameras. The Global Access Remote Exploration Vehicle provides a solution to the problem of needing a large number of cameras.
The aim of the project is to provide a mobile surveillance solution, meaning that only one camera is required to cover a lot larger area than a single fixed camera can. A vehicle will be constructed which will have a mount for the camera on the top, and will be able to cope with various terrain that could be found when using it in the household. The vehicle should have various inputs that can be used for external sensors such as temperature and humidity for environmental monitoring purposes.
Throughout this report the Global Access Remote Exploration Vehicle will be referred to as “GAREV”. “The client” or “the remote client” refers to the end user, using a web browser anywhere in the world via the internet. “The remote environment” refers to the environment that the GAREV is situated in when in use.
The specification of the GAREV had to be decided upon before the design stages of the project could commence. There are three main components in the whole system to be considered; the GAREV itself, software running on a base station and software running on the remote client’s computer to generate the control signals depending on what the client wants to do.
The GAREV itself should be of a tank like structure to give it all-terrain ability relative to its size, this means it will not have steering but instead have independent caterpillar tracks running on either side which can be used to provide skid steering functionality. A high torque gearbox should be used so that the GAREV will be able to pull or push itself over any obstacles that may attempt to block its path, as well as being able to turn and run properly on high friction surfaces such as carpet.
The camera mount is a main part of the GAREV, as it will hold the camera high above the vehicle in order to be able to see where it is going and what obstacles may be present. Two servos will be incorporated into the camera mount in order to provide pan and tilt movement to further increase the viewing angle of the camera, this reduces the chances of there being somewhere in the environment where the camera will not be able to see.
Electronic systems on the GAREV will be based on a microcontroller which will have the main purpose of receiving control commands via a wireless link from the base station and processing them accordingly. In addition to this the microcontroller has to take temperature readings from the connected sensors and send the resulting values back to the base station for processing, as well as providing the pulse width modulation (PWM) signals for controlling the motor speed and the servo control signals. Additional to the microcontroller there are several other major components which allow it to function correctly. These include the motor driver, which provides isolation from the relatively high current motor power lines that would otherwise destroy the delicate processor, as well as the wireless radio link back to the base station and a voltage regulator to ensure the microcontroller gets the desired voltage.
Base Station Software
The software that runs on the base station performs the vital role of being the ‘middle-man’ in communications between the GAREV and the remote client on the internet. The software needs to accept connections via the internet as well as communicating wirelessly with the GAREV itself. It needs to receive the commands from the remote client via the internet and pass them down to the GAREV so it can perform the desired action, and it needs to receive the data packets from the GAREV containing the sensor values and send them to the remote client. In addition to this bi-directional link it also needs to capture the live video stream from the GAREV and make it available for live streaming over the internet, preferably with minimal delay.
Client Computer Software
The client software will be a Java applet that can run in a standard web browser in order to provide compatibility over multiple platforms without needing to download and install any specialised software, other than the Java Runtime Environment (JRE) of course.
The main function of this part of the system is to interface with the user via a Graphical User Interface (GUI) for ease of use, and to generate the control command packets depending upon the user’s actions. There are two main things that need to be controlled on an almost constant basis in order to use the GAREV, and these are the vehicle movement control and the camera mount control. The software has control over the client’s connections to the base station software, and is able to pick up the live video stream from the GAREV for display in the client’s web browser.
Research and Design
When designing the GAREV system, it was felt that minimal large ready-built components should be used, such as the chassis, Printed Circuit Board (PCB), camera mount and software. This means that nearly all of the components used to create the GAREV are completely custom designed and manufactured, which allows the whole system to be more application specific and hence perform better.
The hardware was all designed from scratch and because of this all performs very well together. The specification stated that the chassis was to be of a tank like structure to provide relative all-terrain capability to reduce the risk of the GAREV getting beached or stuck anywhere in the remote environment, as this is the last thing the client wants to happen if they are in a different part of the world, as it would render the vehicle useless until it could be tended to manually. There are only two main hardware components which can be taken off the shelf, and these are the twin motor gearbox, and the wheels with caterpillar tracks. All of the other components are designed and manufactured specifically for the GAREV.
Both of these off-the-shelf components are manufactured by Tamiya. The gearbox is a twin-motor gearbox, with part number 70097. This gearbox comprises of two motors, each with separate gears, to drive the caterpillar tracks independently. The gearbox can be built with two different gear ratios, 58:1 and 203:1. The GAREV will use a ratio of 203:1 which will give a lot less speed, but provide a lot more torque, which allows it to drive up steep slopes and over obstacles. The track and wheel set has part number 70100, and provides a range of different sized wheels and pieces of track which allow for many different configurations.
The chassis design is based on a twin-vertical plate (TVP) system, as used in some model monster trucks. This design gives good strength and resilience to impact or intrusions from either side. The two plates are held together by a central shelf running the length of the vehicle; it is this shelf upon which all of the other components are mounted. The gearbox is bolted directly to this shelf, and the PCB is mounted to it using PCB stand-off mounts, which raise the PCB up off the metal to prevent shorts from occurring. The camera-mount is bolted directly to the vertical plates on either side, but uses the central shelf for secondary support.
100% of the electronics in the GAREV system are on-board the GAREV itself. The electronic systems were designed to fit on one single sided PCB, which was then specifically designed to fit within the limitations of the hardware.
The electronics are based around a Peripheral Interface Controller (PIC) microcontroller manufactured by Microchip. This microcontroller has the job of bringing all the individual electronic systems together and controlling them all simultaneously. Below is a list comprising of the aforementioned individual electronics systems on-board the GAREV.
- Wireless link
- Motor driver
- Camera mount (2 servos)
- Environmental sensors
The PIC microcontroller range from Microchip is a very popular and inexpensive way of adding customisable control to a project. The microcontroller is essentially a very basic computer based on “Reduced Instruction Set Computer” (RISC) architecture. This means on-board the device it has its own processor, random access memory (RAM), read-only memory (ROM) and storage. The ROM part of the device is where the user’s custom written software is stored. Upon power-up the processor reads the program instructions from the ROM and executes them. Many of the devices in the PIC range feature the use of flash memory for their ROM, this means that they are re-programmable for an almost infinite number of times, so one device can have many different uses over time, although as previously mentioned they are so inexpensive that this is rarely needed to be the case. It is more likely that the flash memory is made use of by allowing the software the user puts on the device to be updated and changed at any time. The storage part of the device is usually handled by a section of Electrically-Erasable Programmable Read-Only Memory (EEPROM) on-board the device. This memory is non-volatile, in that data stored there by the program will remain there until it is replaced, even throughout power loss.
The Microcontroller is the brain of the GAREV. It is a fundamental device which allows all the other elements of the vehicle to be connected together and controlled independently by the remote user, giving full control over all the abilities from the remote location. Without a device as versatile as the PIC, all the simultaneous functions would have to be performed by individual devices, which would drastically increase the amount of electronics needed to be placed on-board, increasing the size and weight of the final product.
Choosing a device
There are a wide variety of devices available which have many different features to help the user accomplish their own specific tasks. There are several features provided by Microchip on their devices which can handle the tasks required by the PIC on-board the GAREV. Examples of the features available are:
- Hardware Universal Asynchronous Receiver Transmitter (UART)
- Capture/Compare/PWM (CCP) modules
- Analogue to digital conversion (ADC)
Even if a device is used without any of the required features, they can of course be written in software and downloaded onto the device as part of the normal program, but this makes the program a lot bigger and more complex, and as such takes a lot longer to write. The features are usually known as hardware modules because of this reason – they take away the need for the program to contain software to provide these functions. Making use of hardware modules can give more accurate results as well.
The GAREV can and will make use of all the features listed above. The hardware UART handles all of the serial communication between the microcontroller and the wireless module, which means that there are barely any instructions needed in the software to run the serial port successfully. At the start of the program the UART is initialised, by setting the speed and modes in the control registers on-board the microcontroller, then it is activated and the hardware module does the rest. The software only needs to tell the UART when it wants to receive or transmit data. CCP modules will be used by the GAREV for their PWM capabilities; they are set up in basically the same way as the UART. There are registers in the memory of the PIC which allow the configuration and the activation of each CCP module. In this case one module has three different modes, capture, compare and PWM, so the right one must be selected in the option registers before the module can be activated. The motor driver accepts a PWM signal which allows the microcontroller to individually control the speed of the motors. The ADC modules allow the microcontroller to read analogue voltage outputs from any of the connected environmental sensors and save the result as a digital value in memory. Timers on the PIC can be used to trigger an event at regular intervals; on the GAREV these will be used to pulse the servos on the camera mount with location information every 20ms.
Other than looking at the special features each device provides, there are more common specifications to consider, like those that would be considered when purchasing a normal computer. Clock speed, ROM, RAM, storage and pin count are all important things to consider when selecting a device.
Microchip provides many different ranges of PIC microcontroller, the PIC16 series was chosen for use on the GAREV as it is both readily available and inexpensive. It does not need the higher processing power of the PIC18 series. Microchip provides an extensive search facility on their website which allows the selection of a device based on criteria given. The GAREV needs two CCP modules, which narrows down the selection of devices quite considerably, to only 13 devices with two modules, and an additional 4 which have 3. The next thing to consider is the pin count of the device, an unnecessarily large device with too many pins can adversely affect the size of the final PCB design. Out of the devices selected with two or more CCP modules, two different pin counts are available, 20, 28 and 44 pin. 28 pins is the closest match to that needed to accommodate all of the projected features of the GAREV, so the selection is narrowed down further, to a count of 7 devices.
Out of the final selection of 7 devices given by the search facility on the Microchip website, the PIC16F876 was chosen to be the processor for the GAREV. It has 14KB of flash program memory, 368B of RAM, 256B of EEPROM storage in addition to all of the specific features required.
As the microcontroller is designed to be a tool for accomplishing a wide variety of electronic tasks, when it arrives it is completely blank and useless. Powering up the microcontroller in this state would not achieve anything as the ROM on-board the device contains no instructions to be executed. To customise the device for a specific application the user needs to download their program or instructions into the ROM so that the processor can execute them. To do this a PIC programmer is required. This provides an interface between the PIC and a computer of some sort which allows the instructions the user has written to be downloaded onto the PIC.
There are many different types of programmer available, using either the parallel port, the serial port or the USB port on a computer. A lot of the PIC range supports In-Circuit Serial Programming (ICSP) which allows the device to be programmed while it is in place in the circuit. To do this, a higher end programmer is required which also supports the ICSP protocol, and will have a connection on-board for linking the programmer to the circuit containing the PIC to be programmed. More basic programmers usually make use of the parallel port, and are much less expensive. The only problem with these programmers that do not support ICSP is that the device needs to be removed from the circuit and placed in the programmer whenever it needs to be programmed. For development purposes this can be very time consuming, as there are many occasions where the software previously downloaded on to the device will not work as expected. This leads to repeated removal and replacement of the device in the circuit which can cause damage.
On the computer the programmer is connected to, software is required to download the program onto the PIC. The software used depends on the type of programmer chosen, as there are many different types of programmer which cannot all be supported by one program alone. This software allows you to open the hex file containing your program and download it onto your device, as well as other features such as device blanking to remove previous code from the flash ROM memory on the device. The hex file is created by an assembler which converts human readable instructions into their counterparts which the processor can understand. Creating this file is covered later in this report.
The programmer decided upon for use with the GAREV project is one that connects to the host computer using the parallel port and does not support ICSP. This programmer is known as the “P16PRO40” and is provided either as a complete and tested unit ready for use or in kit form from many different suppliers.
In the specification it was specified that the GAREV should have two wireless links back to the base station. One link comprises solely of the live video stream, which comes directly from the camera. In addition to this, a separate link for data is present which will allow the base station to relay commands to the GAREV from the remote client and allow the GAREV to send data collected from the on-board sensors back to the base station for processing and sending on to the remote client.
Due to the nature of the GAREV, it is important to obtain a robust wireless link. For this, the use of a system where packets are almost guaranteed to get across the link is required, as well as a module which is easily interfaced with the microcontroller using a serial communication link.
One consideration for the link was Easy Radio, produced by Low Power Radio Solutions (LPRS). It has transceiver modules which can interface with the UART on-board the microcontroller, and can operate on 433MHz and 900MHz. The protocol used between these modules is not robust and there is no guarantee that what is transmitted will reach the other side correctly, each data packet is sent once and that is it. It was decided that using this solution would not provide a robust link like what is needed between the GAREV and the base station.
The use of Easy Radio with a computer also requires that a second transceiver be purchased for direct connection to the computer. This means that a level converter circuit must be constructed as the modules only work with Transistor-Transistor Logic (TTL) level signals, whereas a computer serial port works at true RS232 levels.
Bluetooth was found to be a wireless solution that provides a more robust link than the Easy Radio. Bluetooth communicates using a frequency of 2.45GHz, or between 2.402GHz and 2.480GHz to be more exact. Bluetooth does not need line of sight to communicate correctly, which is a definite requirement for the GAREV, as the requirement of being within line of sight of the base station would severely limit the range and therefore usefulness of the whole system. There are two classes of Bluetooth which are important to consider, as one severely outperforms the other, these are known as Class 1 and Class 2. Mobile phones and other devices that are for use within close range of each other, headsets and keyboards for example, use Class 2 Bluetooth. This means they are limited to a theoretical maximum communication link distance between two devices of 10 metres, which is clearly of no use for a device such as the GAREV. Class 1 Bluetooth has a limit of 100 metres, which is far more acceptable, as any walls and other obstacles will limit the range further anyway. There are more factors which make a Bluetooth radio link a suitable system for the GAREV too. Bluetooth is very resilient when it comes to dealing with interference, this is very important as the control signals are critical to the correct operation of the GAREV. A loss in communication between the vehicle and the base station could be catastrophic. Bluetooth needs to be strong link due to the amount of devices that could be found all within range of each other, as more often than not a person will have a mobile phone with Bluetooth enabled within range.
The robust link that Bluetooth creates is accomplished by not using a specific frequency to transmit on; this technique is called spread-spectrum frequency hopping. Using this method makes it extremely unlikely for more than a single device to be transmitting on the same frequency at any one time. The frequencies used by a device are chosen at random within the frequency range. 79 different frequencies are chosen, and the transmitting device will switch between them 1600 times per second, or once every 625μs.
After considering both Easy Radio and Bluetooth as viable wireless solutions for the link between the GAREV and the base station, it was decided that Bluetooth would be used as it would provide the more robust link.
The module purchased for use on the GAREV is called the BlueSMiRF and is manufactured by Spark Fun Electronics. The BlueSMiRF provides a TTL level link at 9600bps for connection directly to the microcontroller without any extra electronics, so whatever comes out of the UART on the microcontroller goes directly into the BlueSMiRF and is sent when a Bluetooth connection is created by the base station. It is possible to connect the BlueSMiRF directly to a PC serial port, via RS232 level conversion, in order to access it directly for configuration. When connecting directly to the BlueSMiRF with a serial terminal program on a computer, it is possible to access the configuration menus and change almost any aspect of the operation of the radio. There is one option which is important to change straight away for an application like the GAREV, and that is to enable and set the Bluetooth passkey. Setting a passkey prevents any unauthorised users from connecting to the GAREV with whatever device they are using and causing undesired operation. It is also possible to change and set the Bluetooth device name, so when looking for the GAREV with another Bluetooth enabled device it is possible to pick out the device amongst a list of others with ease.
At the base station side of the Bluetooth connection, another Bluetooth radio is needed. As the Bluetooth radio at this end does not need to be customised or configured in any way, a normal Class 1 USB Bluetooth dongle can be used, just like what would be used when connecting any other Bluetooth device with the PC. The Bluetooth dongle selected for use in the GAREV system is the GN-BTD02 Bluetooth USB dongle manufactured by Gigabyte Technology. It was selected for use because of its small size and low cost without sacrificing performance.
Connections to the GAREV via Bluetooth are always initiated by the base station, as the base station is the closest part of the system that knows when a remote client has connected. Using the system in this way ensures that the Bluetooth connection is only active when it needs to be, therefore decreasing power consumption and therefore increasing battery life. When a remote client accesses the web interface of the GAREV system, the base station initiates a connection to the GAREV which creates the robust Bluetooth link between the two devices. Once a connection is established, the microcontroller can use the wireless link as if it were connected directly to the base station with a cable. This form of operation is known as a virtual COM port, as it performs exactly like a physical COM port with a cable.
Specifications of the PIC microcontroller say that each pin on the device can only source or sink a maximum 25mA of current. Obviously this is nowhere near the amount needed to drive the high-torque gearbox with high speed motors on-board the GAREV, so an interface is needed which can isolate the microcontroller from the high current draw of the motors. This device is called a motor controller, or driver, and is sometimes known as an H-bridge.
The motor controller consists of power transistors that allow the low, logic-level control signals from the microcontroller to switch and reverse the power to each of the motors independently. To do this, four control lines are needed from the microcontroller, using four of the pins available. In addition to these four control lines, two enable lines are connected, one for each motor. It is these additional two enable lines which are connected to the CCP PWM module output pins on the microcontroller. These enable lines are used to explicitly control the on/off state of each of the motors, if the enable line is low the motor cannot operate regardless of the state of the control lines. This operation allows us to control the speed of the motors using PWM at a specific frequency. Varying the mark duration in the PWM waveform allows the microcontroller to change the average voltage applied across each of the motors independently, and hence vary the speed.
Motor controllers are sometimes known as H-bridges due to the configuration of transistors inside the device. The schematic for each motor involves four transistors, which form the shape of an ‘H’ when connected together.
The motor driver decided upon for use on the GAREV is the L298 manufactured by ST Microelectronics. This device allows the logic level outputs of the microcontroller to control motor currents up to 4 amps at 46 volts. The only disadvantage to using this device is that it requires external back-electro motive force (EMF) protection diodes to protect it from damage.
The camera used on-board the GAREV can be any form of wireless camera because it does not interface with the GAREV directly. The wireless video signal from the camera is sent directly back to the base station to be captured by a Universal Serial Bus (USB) vide capture device which allows the software on the base station to receive the live video stream. The power supply to the camera is fed from a specific output on the GAREV PCB which allows it to be switched on and off as required by the microcontroller. The camera is mounted on a camera mount which is constructed to fit the selected camera. The mount is made up of aluminium brackets for support with 2 servos to provide the pan and tilt movement. The servos are controlled directly by the microcontroller as they contain the required electronics to take the current handling away from the controlling device, in this case the microcontroller.
The microcontroller used on-board the GAREV has an ADC channel which allows the conversion of a voltage between 0 and 5V present on an external pin to be converted to a digital value and be stored. Only a single external pin can be internally connected to the ADC module at any one time, and there are a total of 5 pins that can be connected to it. When making an analogue to digital conversion, the pin required can be selected in option registers before the conversion is initiated, allowing only the desired value to be obtained. All of the pins capable of being internally connected to the ADC module are connected to pin headers on the PCB. This allows any sensor with an analogue output to be connected, with or without supporting circuitry, directly to the microcontroller. The microcontroller will make analogue to digital conversions at a set interval using the values present on the external channels. Once the conversion is complete, the value can be sent back to the base station.
In addition to the main components such as the microcontroller and the wireless module, there are many other smaller components needed for the correct operation of the vehicle. Many of the larger, more complex devices depend on these smaller items to operate correctly.
The twin vertical plate chassis the GAREV is built on was designed to be wide enough to allow an AA size battery to fit length ways between the two plates with spare room on either side. This means that any sized battery pack made up of AA cells can fit under the central shelf in the GAREV, mounted above the axles; the only limiting factor is the length of the chassis. Due to this the maximum amount of cells that can fit without protruding at the ends is 9, giving a voltage of 10.8V for rechargeable Nickel-metal hydride (NiMH) cells, or 15V for alkaline cells. It was decided that a battery pack built with 8 NiMH AA size cells would be used on the GAREV as it is slightly smaller in length, allowing space for fixing hardware to be attached. This pack of 8 rechargeable AA size cells gives a voltage of 9.6V which is plenty for the microcontroller and other logic level electronics as they only need 5V, and gives a bit extra to give a full range of speeds from the motors. The cells chosen for the assembly of the battery pack are one of the highest capacities available at the time, and that is 2200 milliamp hours (mAh), which means they can drive a 2.2A current for 1 hour.
As mentioned previously, the battery pack on-board the GAREV gives a voltage of 9.6V, which is far too high for the operation of logic level devices, which require 5V. In order to get a current independent voltage source of 5V, a voltage regulator is used. This provides a steady 5V power line on the PCB, without being dependent upon the battery voltage, as it could vary dramatically in normal operation. The regulator used is the 7805 from ST Microelectronics, it is capable of providing up to 1A at 5V, and requires no external circuitry other than some noise suppression capacitors. It has 3 pins, VIN, VOUT and ground, so is very simple to integrate into the PCB design and use. With the voltage regulator on-board, there are now two power circuits on the PCB, one running at the regulated 5V for the microcontroller and servos, and a second running directly from the battery, from which the motors are powered.
Since the GAREV PCB will be used as a development platform for the microcontroller software, it is useful to have some LEDs on-board to help indicate the status of the program as it runs. Two LEDs are connected directly to the microcontroller with current limiting resistors, so it is possible to add lines of code to switch them on or off as desired at any point in the program to help with debugging. The LEDs are also used as status indicators for the GAREV when it is running; they allow the user to visibly see the state at which the GAREV is in at a glance.
The microcontroller depends on this device to run. The oscillator provides the signal at which the instructions on the microcontroller execute, it runs at 20MHz. The signal from the oscillator is fed directly into the microcontroller, and then the instructions are executed at ¼ of this frequency, so 5MHz in this case. Increasing or decreasing the speed of the oscillator gives some control at the rate at which instructions are executed, but the device is not certified to run over its specified frequency. Keeping the oscillator frequency to a pleasant round number greatly simplifies timing calculations when writing the software to run on the microcontroller.
Due to the number of components of the GAREV that can not be directly mounted on or connected to the PCB, it is required that sufficient connectors be placed on the PCB to give the design some modularity. A socket is placed on the PCB wherever there is a need for external wires to attach, and then the corresponding plug is connected to these wires. This method allows each separate item to be connected and disconnected with ease without any extra tools. The motors, servos, battery, camera power and sensors are all connected to the PCB with these connectors, allowing the PCB to be removed from the GAREV without having to dismantle the entire vehicle.
A custom PCB design is essential to the GAREV design as it allows all of the electronic components to be positioned together on board as small as possible. The chassis design of the GAREV limits the size of the PCB in all three dimensions. It has a width limited by the width of the actual chassis, which in turn is limited by the width of the gearbox. The inside distance between the two vertical chassis plates is 58mm, hence the width of the PCB cannot be larger than 58mm. The length of the PCB is limited due to the length of the chassis, and the fact that the gearbox takes up a lot of room on the central electronics shelf. Due to these two factors the length of the PCB is limited to a maximum of 73mm. The height of the board is not so important, rather the height and positioning of the components placed on the board. It is important that the PCB sits low enough within the chassis so that no components protrude above the vertical plates. This allows a top surface to be fitted to the chassis at a later date without any obstructions. The distance between the top of the central electronics shelf and the top of the vertical chassis plates is 33mm, so the height all of the parts of the PCB including stand-off mounts must total less than this amount or the devices will protrude.
The PCB will sit a distance of 5mm above the central shelf due to the PCB stand-offs that allow the PCB to be fixed to the shelf, and the PCB thickness adds another 1.5mm to that, giving 6.5mm that cannot be used for components. Subtracting this 6.5mm from the total of 33mm gives a final measurement for the maximum component height of 26.5mm. The tallest components to be used are the L298 H-bridge and the 7805 voltage regulator, the L298 being the tallest out of the two and coming in with a height of 21mm, well below the 26.5mm height limit.
The PCB is designed on computer using the Proteus software package. This software allows the specified design limitations to be applied, and then the components are placed to give a final board size within these limitations.
In the GAREV system, there are three major pieces of software which must all work together seamlessly in normal operation. These are;
- Microcontroller program (on-board the GAREV)
- Base station software
- Remote client software
The microcontroller program is the program downloaded onto the PIC microcontroller which is then in turn placed into the DIL socket on the GAREV PCB. This software is written in assembly language using the Microchip integrated development environment (IDE) called MPLAB. This IDE provides an environment both for writing the software and the assembler which produces the hex file for download onto the PIC. Assembly language is one of the lowest level forms of programming language, the only thing lower is writing the machine code directly, but this is not different from assembly, as the mnemonics are translated directly into a list of instructions that the processor directly supports. Using assembly language gives the user direct control over the functions of the processor, giving the best performing and most precise operation. It is possible to directly access the option registers of the microcontroller for configuration, and very accurate timing can be achieved, as the time each instruction will take to execute is a known value.
Base station software
The base station software is that which runs on the base station and works as a middle man between the GAREV and the remote client. This software is written in a scripting language called Python, purely because it offers very simple access to the virtual COM ports present on the computer, and very simple methods for accepting and handling multiple TCP/IP connections over the internet. This software has the simple function of passing the control characters received over the internet connection on to the GAREV via the virtual COM port created by the Bluetooth connection, as well as sending sensor data back in the opposite direction from the GAREV to the remote client. This software also handles multiple users, making sure that only one remote client can have control of the vehicle at any one time, reducing the risk of any loss of control due to outside interference.
Remote Client software
The remote client software is that which the remote users see in their web browser when accessing the GAREV system web interface. This is the only software in the system which has a graphical user interface (GUI) as it is the only piece of software which is not autonomous and deals directly with a human user. The GUI allows the user to easily see what is going on in the system and gives them control over the vehicle without needing to know any complex commands and without needing to remember any specific control details. The computer mouse is the only device needed to have full control over the movement controls of the vehicle and the camera pan and tilt functions.
There are just two main stages in the physical construction of the GAREV; this is the hardware – chassis and camera mount, and then the electronics.
All the custom hardware components of the GAREV are manufactured from 1.3mm aluminium sheet. This helps to keep the final cost of the device down, as only one material is needed for the bulk of the construction.
The designs of the parts to be cut are laid out onto the aluminium sheet and then were cut out using a jigsaw. If this were to be done commercially it would be a very simple task to use a Computer Numerically Controlled (CNC) router or water jet to cut the parts in mass numbers at high speed. The GAREV was designed to keep fixing hardware to a minimum, meaning that only 4 machine screws and nuts are required to hold the main chassis together with the central shelf running down the centre. After the components have been cut from the sheet aluminium, some components have to be bent into their required shape to complete the manufacturing process.
Many of the components now need to be drilled to allow the use of fixing hardware to hold the chassis together. The sides of the chassis need to be drilled to allow the insertion of the five axles that make up the caterpillar track assembly, as well as two holes on each side to allow the mounting of the central shelf. The parts of the camera mount need to be drilled to allow the fixing of the servos that provide the pan and tilt motion, and to allow the mounting of the camera. The mount is again held together with small machine screws and nuts. The twin motor gearbox is fixed to the central shelf with yet more machine screws and nuts, and all the wheels are push fitted onto the axles.
As the GAREV electronics are designed to be as modular as possible, construction and testing is very simple. The PCB design created on computer was exported and made into a PCB. The components are then attached and the board tested for complete functionality without faults.
The transformation of the PCB from the state at which it arrives to final assembly is very simple. First, holes are drilled in the board for all the through-hole components to be mounted. In the case of this board, all of the components use through-hole mounting, so the components are placed on the opposite side of the board to the side on which they are soldered. Lower profile components are placed and soldered onto the board first, which allows them to be pressed against the board fully without obstruction from larger components. From then on components are soldered on in order of height. A dual-in-line (DIL) socket is used for the microcontroller which allows it to be removed and replaced as often as required without the use of soldering equipment. This is essential as the microcontroller needs to be removed from the board every time it needs to be programmed.
First of all, basic visual checks are carried out before power is applied to ensure no tracks are bridged that could cause shorts and damage the PCB. Once it is ensured that nothing out of the ordinary will happen when power is applied, it can be connected to the supply and then the next part of testing can commence.
Testing a PCB with a microcontroller is very simple, as long as the microcontroller is executing code ok, and to do this all it needs is a power supply and the oscillator. The microcontroller is powered from the 5V line supplied by the voltage regulator; this can simply be tested with a multi-metre set to a DC voltage range. The oscillator can be tested using an oscilloscope to make sure it is running at the required frequency.
Once these requirements are met and the microcontroller is executing code, it is very simple to test the rest of the system, as a custom microcontroller program can be downloaded and run to test each individual component in turn.
There is only one component that could really be damaged and that is the wireless module. All of the other modules in the system cannot be damaged by shorts or power applied in the wrong direction. Because of this it is important to test the wireless module connector on the board for proper connectivity before connecting the wireless module. This ensures a minimal chance of the module ever getting damaged due to a fault on the board.
As specified in the design and research chapter of the project, the GAREV system is to have three main software components. Each of these components is programmed separately, in a different language and for different platforms. The three components are as follows: GAREV on-board microcontroller program Base station software Remote client web-based software
GAREV on-board microcontroller program
This part of the system is the part which actually runs on-board the GAREV itself. It is the part which allows all the other aspects of the system to interface with the GAREV hardware; the motor controllers and other systems on-board. The program is written for the PIC microcontroller previously specified in assembly language. This is a low level language which allows direct control of all aspects of the microcontroller, allowing for the most accurate operation. The PIC runs on what is known as a Reduced Instruction Set Computer (RISC) architecture, which means assembly language is very easy to use due to the small instruction set. The instruction set is specified in the datasheet for the chosen microcontroller, and consists of 35 individual instructions.
The purpose of this part of the system is to receive the commands relayed via the base station and perform the corresponding operation. Once the microcontroller has been initialised it sits waiting for a command character so that it can perform the operation, then once that operation has been perform it goes back to waiting. The beauty of using a PIC microcontroller with assembly language is that it is very popular, so there are many resources and code excerpts freely available from sources such as books and the internet. The GAREV software makes use of several such code excerpts for menial tasks such as delay routines and number conversions. Such excerpts are clearly marked and referenced in the source code.
The full microcontroller program source code, written in assembly is included in appendix 1. Line numbers are printed at the start of the line, and comments are preceded by a semi-colon.
When writing the program for the GAREV, it was important to keep everything as modular as possible. This means using a lot of subroutines and macros which can be called into the current place in the program at any time without having to re-write the same thing continually, and it means that if one thing needs to be changed, it only needs to be changed once and it changes for every instance, which allows for easy modification of an older version of the program.
A macro is simply a block of code that is given a name. Once it is defined you are able to type the name of the macro and the assembler will replace the name with the actual block of code. All of the macros used in the program are listed in the source code from line numbers 38 to 114. Each macro is preceded with a line telling the assembler the name of the macro and that the code following is to be a macro, and then followed with ‘endm’ which ends the macro. To include the macro anywhere in the code, all which is required is to type the name of it and the assembler does the rest. For examples of macros being called, see lines 347 to 362.
A subroutine is different from a macro in that the code is not just copied to all the required places. When a subroutine is called, the processor moves to the location in code where the subroutine is written and executes it while it is in place, then when it reaches the end, it jumps back to where it left off. These operations involve the use of the program counter (PC) on the microcontroller, which is the register that stores the location of the current instruction being executed. When a subroutine is called, the current value of the PC is saved on a memory stack, and the PC is loaded with the address of the subroutine. When the end of the subroutine is reached, the processor reads the old value of the PC off the top of the stack and so can return to the precise location where it left off. Subroutines are defined with a label, which is basically a friendly name for a location in memory, and ended with a ‘return’ instruction. See line 240 onwards for examples of subroutines.
When the microcontroller starts executing instructions, it first looks at memory location 0x00, so the assembler needs to be told where to put the first instruction; this is done on line 31 with the ‘org’ (origin) command. In this case the processor is straight away being told to ‘goto MAIN’, which means it jumps straight away into the main section of code. Below the first origin instruction there is a second one, as when the processor is interrupted, by any event, be it internal or external, the processor looks at memory location 0x04 for instructions, so an instruction is put here to tell it to jump to the interrupt service routine (ISR).
When the microcontroller is first powered up all of the registers and on-board modules are all in their default state. This usually means none of the modules are running, interrupts are turned off and all of the option registers are blank, which means all of the required modules need to be setup and turned on. All of this is accomplished in the ‘INITANDSETUP’ section of the source code, starting on line 532. One of the very first things to do is setup the pins, they can either be set to inputs or outputs, and this is accomplished by setting values in the tri-state option registers, ‘TRISA’, ‘TRISB’ and ‘TRISC’, one each for ports A, B and C respectively. A ‘1’ in this register means the corresponding pin is set as an input, a ‘0’ means output. The only inputs that need to be set are the ‘receive’ (Rx) line for the serial communication, the environmental sensor connections and the external interrupt.
The next thing to be done is to setup and turn on the UART. There are several option registers which set the speed of the port and the operation mode. The speed in this case is set to 9600bps and the mode is set to asynchronous. The microcontroller has a baud rate generator on-board so it needs to be set depending on the frequency of the external oscillator used, which in this case is 20MHz. Once the UART is setup it will run independent of the main program, and interrupt if a character is received.
The PWM channels are setup at a frequency of 2.5 KHz and then started. The PWM modules on the PIC rely on one of the timer modules as well, so if the PWM modules are being used, you lose the functionality of one of the timer modules. This is not a problem for the GAREV though, as only one timer module is needed, to ‘fire’ the pulse to the servos every 20ms. TIMER1 is used for the servo pulses, the frequency pre-scalar is set to a value so it takes roughly 20ms for the timer to overflow, which then triggers and interrupt which can be serviced with the ISR.
Once all the required modules have been setup and started, the PIC can go into its main loop where it waits for the command characters. The command set is simple ASCII characters running from ‘a’ to ‘k’. Using standard ASCII characters makes resolving the character to its corresponding command very simple. In assembly language there are no switch statements like would be used in higher level languages, but you can jump ahead in the program by a certain number. All that needs to be done is a list of the commands and then you can jump down the list as required. A simple 0-10 set of decimal numbers can be extracted from the ASCII values with a simple subtraction. For example, the hex value for ‘a’ is 61, incrementing upwards with each letter, so subtracting hex 61 from each command that comes in results in a number that I can use with my jump table. The command jump routine is from line 317 onwards.
When in use on the GAREV it is important that the microcontroller have a sleep mode due to the GAREV only running from batteries. Without the use of the sleep mode the batteries would not last very long at all and reduce the overall usefulness of the vehicle. The green status LED on-board the GAREV indicates the state of the microcontroller – when the LED is on this means the microcontroller is awake, all the internal modules are running and it is ready to accept any command. If the green LED is off, this means the microcontroller is in sleep mode, where all of the internal modules bar the UART are shut down. The power to the camera is turned off in this mode as well. The microcontroller needs a certain bit pattern to arrive via the wireless connection to allow it to come out of sleep mode, if the pattern is correct then all the modules are started up again and it is ready to go. Doing this greatly increases the battery life of the vehicle, test results showed the battery lasts over 4 times longer with sleep mode.
The base station software has the job of relaying the ASCII command characters from the remote client to the microcontroller on the GAREV, and relay the environmental sensor data from the GAREV back to the remote client. It manages connections from multiple remote clients, preventing confusion created by more than one remote client trying to control the GAREV at any one time. It is a very simple program.
Due to the requirement of being able to access the virtual Bluetooth serial port, as well as to be able to open and listen on a TCP port, it was decided that a language that could access both of these very easily and be fast would be used – Python. Python is an interpreted language so requires the installation of the interpreter on the base station to run, however with the correct tools, a portable version of the interpreter can be compiled along with the Python code so it can be run on computers where the interpreter is not installed.
The full source code written in Python for the base station software is included in appendix. Comments are preceded with a hash.
When using Python all the functions cannot be accessed without including them, so at the start of the code all of the necessary modules need to be imported. In the main code itself there are two main functions, one which is called whenever a client connects, which checks to see if the tank is in use already or not and allows them a connection depending on that. A second function is used to read the temperature values from the tank periodically. The configuration for the base station software is held in a configuration file which must be placed in the same directory as the program when it is run. The configuration file defines the TCP port number to use and the COM port number to use. When the program is run, it opens this file, extracts the relevant information and then stores it in variables for easy access. The TCP listen socket is then created and opened, and the program will go into an endless loop waiting for connections. When a connection is established from the remote client the program executes the function “clientthread”. This function then checks to make sure somebody isn’t already using the GAREV, and if it is free allows them to connect. Once the client has connected the software then initiates the virtual COM port Bluetooth connection to the GAREV and then begins relaying information between the remote client and the vehicle. If a client tries to connect and the GAREV is already in use their connection will be rejected and the client left to try again. The program does not drop out of the first instance of “clientthread” until the client disconnects. In this loop it reads one line at a time from the remote client and then sends it via the Bluetooth connection to the GAREV when something is received.
The second piece of software that runs on the base station is that which captures the live video stream and streams it over a second TCP port. This software is called WebcamXP (http://www.webcamxp.com). This software captures the video from the USB video capture device, and allows it to be accessed via the internet, so wherever the remote client is the video can be accessed. This is the only non-custom piece of software in the GAREV system. WebcamXP is a highly configurable piece of software so it gives no disadvantage to writing a piece of software dedicated to doing the job.
The remote client software is that which runs in the web browser on the computer of the remote client. Due to this it needs to be written in such a way that it will run independently of the computer platform. Java was chosen because it runs on a virtual machine. Java virtual machines (JVM) are available for almost all of the available computing platforms, including Windows, Linux, Solaris (Sun), Macintosh and many others. For this reason it is the only candidate language for this part of the GAREV system, as use on many different systems is a definite requirement.
The GAREV control software uses a Java GUI applet which is downloaded by the remote web browser when the GAREV web interface is accessed. When the applet has completed downloading, the JVM on the remote computer runs it and the user is able to connect to the GAREV and start controlling the vehicle.
The full source code for the GAREV control software, written in Java is included in appendix. Line numbers are printed at the start of the line and comments are preceded by a double forward-slash.
This program is the most complex out of the three programs in the system, mainly due to the fact that it has a GUI. Referring to the source code, the first 175 lines all consist of lines that are building and initialising all the parts of the GUI. The controls for actually moving the vehicle are used by rolling the mouse over the arrows on the applet. This means that several invisible areas have to be defined, so when the mouse is within one of them, the applet can send the appropriate command to the base station. A mouse-motion listener is added to the applet, which means a certain piece of code can be executed whenever the mouse is moved, in this case when the mouse is moved; the location of the mouse at the current time is compared to the boundaries of the invisible areas. This allows the program to know which, if any of the areas the mouse is in, and send the appropriate command. All of the rest of the commands are sent via normal button clicks, so all the buttons need to be defined, labelled and added to the GUI.
The GUI includes connect and disconnect buttons, and a status box to display the current status of the connection to the base station, and the current temperature from the GAREV when a connection is active. When the connect button is clicked, the applet tries to open a socket back to the base station, which will then reply with the base station software version. If the base station says that the GAREV is currently in use, the connection will be cancelled and the applet will revert back to being disconnected. If the base station says that the GAREV is free for use, it will try to initiate the Bluetooth connection to the GAREV itself, which, if successful will complete the connection procedure and the GAREV will send its software version before sending the current temperature every 2 seconds.
The image from the remote camera on the GAREV is not received by the control applet; instead a small excerpt of Java script is used to retrieve the motion JPEG video stream as quickly as possible. This means the speed at which the image from the camera updates is purely dependant on the speed of the TCP connection between the base station and the remote client.