Technical development

Hardware

Core controller

This was to be the brains of the ReCoRVVA. Its task was to control all the peripherals on the ReCoRVVA, to manage all communications with the client and, by extension, the user. It needed to be capable of handling multiple tasks at once and be able to use multiple electrical inputs/outputs to control the physical aspects of the ReCoRVVA. It also needed to be customisable, so that we could quickly and easily change things, e.g. software or, if we had a accident, interchangeable controllers. It needed to be able to support the data inflows/outflows shown in figures 4 and 5.

1. Arduino

   The first option we explored was to use an Arduino (a programmable microcontroller with a number of inputs/outputs) to control the physical aspects of the ReCoRVVA, such as the motors, servos and ping sensor, but we eventually found ways to do all these through the  Raspberry Pi, and we found that the communication between the  Raspberry Pi and the Arduino, which was required, was far too unstable to be used.

   Despite the fact that it didn’t make it into the final model, it was a valuable tool for prototyping, developing and testing our ideas before applying them to the robot.

2. Raspberry Pi

   The  Raspberry Pi was always intended for handling the communication functions but after the testing of the Arduino described above, it was eventually used to control everything. A Pi is used as the server and drive computer on the robot, and if the robot is to be controlled by a wiimote or Xbox controller, another Pi is required as the client for those.

Power

1. Dual 6v AA battery packs

   The main power draw for the ReCoRVVA is the motors. Originally we were going to power these with 9v batteries, but soon we realised that we would have to put these through a 5v regulator which would lose power as heat, and packs of AAs have more capacity, so AAs it was. We chose a battery pack which held 4 AAs as this provided 6v; 6v was the highest voltage (and therefore the fastest RPM on the motors) within 1.5v intervals (AAs are 1.5v each)  that we could drive the motors at without blowing them. Since we were using the AA pack for the main motors, it made sense to use it for the servos as well. However, when we fully tested the ReCoRVVA the motors turned very slowly, showing a high current draw on the pack, so we connected another 4-AA battery pack in parallel, which doubled the amperage supplied to the motors while keeping the voltage at 6v.

2. USB 5v power block

   The  Raspberry Pi is powered by a micro USB port (5v). Initially we were going to use a small, lightweight power block (5v) with one port which would be used by the Pi. Though this adequately powered the Pi during tests with just the Pi, when we tested it with peripherals (LED headlights, servos, ping sensor, wifi dongle, motor driver) it failed to supply the Pi with enough current. Since the dual AA battery packs were nearly at their amperage limit powering the servos and motors, we also needed some way of powering the ping sensor and "enable" pins on the motor driver. This is why we opted for a two port high amperage, high capacity power block, which allowed us to power the Pi with one port and use the additional port for other things – the ping sensor.

Chassis and Tracks

Motor driver

Our first prototype was built using an Arduino on an old toy car chassis. As soon as we tested it we realised we had no way of making the motors turn backwards. We were initially considering manually building a 14 transistor H-bridge, but we decided that we wanted something that saved space, was totally reliable and something that wouldn't lose so much power as heat, so we bought an L298N motor driver which was fully compatible with the Raspberry Pi and has it own on board 5v regulator for the motors. Once we'd tested the L298N and configured it to work with the Pi, we built more prototypes, this time on the dedicated chassis, and without the Arduino (see the section above on the Arduino for why we decided not to use it).

Chassis

We wanted the ReCoRVVA to be able to climb up rough terrain; volcanoes, crevices, earthquake disaster zones - to name a few examples of where we imagined it might be useful. We decided to put tracks on the robot to aid its traveling and mobility as tracks can climb up steep and difficult surfaces, whereas wheels would slip and lose traction. We also needed it to be used in enclosed environments like buildings.

This type of chassis is also much easier to steer, because it is attached to tracks. With wheels you would have to program a steering wheel but with this type of chassis all you have to do is stop one of the tracks and it will turn. With a steering wheel you would also have to put a servo in the front of the vehicle, which would involve a lot more unnecessary programming and hardware, which is not unnecessary if you have this type of chassis. Plus they have more traction than wheels - better for climbing difficult surfaces.

So in conclusion these chassis are better suited for the job asked of the ReCoRVVA.

Dual motor gearbox

The ReCoRVVA’s tracked chassis meant that for it to be able to steer and turn, it had to have independently controllable tracks. This meant two individual motors, driving a track each.

A gearbox with a high gear ratio was essential, as the motors were small (to save space and weight), and needed a high gear ratio to drive the tracks with ease. A ratio like this was also essential, as we didn’t want the ReCoRVVA to travel too fast. This is because (over a long distance) there is a very small delay between the operator sending a command to the ReCoRVVA and it acting upon it. If the ReCoRVVA travelled at high speeds it could travel a further distance between the operator pressing stop and it actually stopping; therefore a lower speed means more control. If it went too fast, there is also a possibility that it would lose network connection which would mean that the user couldn’t control it.

All the above reasons are what justified our choice of a Tamiya double gearbox, with dual motors and adjustable gear ratios.

Visuals

1. Camera

   Initially, we were going to use a USB camera for the live video stream, but quickly discovered that the quality was inadequate and that a USB webcam used a lot of power - throughout the project we had tried to save power as the ReCoRVVA was battery powered - so we turned to the Raspberry Pi camera board. This was a good choice because we got high resolution (5MP, 1080p), low power consumption and a fast and reliable video stream.

2. Servos

   We wanted to be able to pan and tilt the camera 180 degrees each way, and decided to achieve this by mounting the camera and headlight on a mount rotatable on two axes, X and Y. We would have a servo for each axis. Since we were always trying to keep things light, we went for two micro servos, as they were lightweight yet had enough torque for the task required.

3. Mount

   [gallery size="medium" ids="370,369"]

   At first we considered using a bought mount made of metal, but this was quite expensive, so we decided to design and laser cut our own. Before we designed and cut the mount we thought carefully about the requirements it needed to fulfill, 180 degrees rotation horizontally and vertically, room for the camera and headlights, sturdiness and durability, and, of course, remaining lightweight. We designed the mount using Computer Aided Design software (2D design) then laser cut it on the machine at Brockford Barn education center.

Our laser cut mount was light, and was specifically designed to accommodate both the camera and headlight and enabled full rotation on two axes. It was however, a bit too big, which hindered its movability on the robot as it got caught up in the wires and other components.

The mount shown in Figure 7 with 1 servo attached, the whole thing is mounted on a second upward facing servo (not shown in this picture).

Sensors

1. Ultrasonic distance sensor

   Initially we used the Arduino to test the ping sensor, to clear our minds as to how it works, before integrating it into the actual robot. It works by sending an ultrasonic wave out (initiated by turning the trigger pin on) of one of the drum encasings and timing how long it takes to come back (via the echo pin) to the other. We then used this data to create an average of the distance from the ReCoRVVA to the nearest object in front of it, and used that to satisfy Objective 1, automatic stopping on detection of an obstacle.

2. Temperature/Humidity sensor

   The ReCoRVVA needs a humidity/temperature sensor so that when it’s in dangerous situations (e.g. volcanoes/crevices/underground) it can sense that the temperature is rising, sending the data to the user so the user knows they shouldn’t go any further. It also uses this data to automatically stop if the temperature gets too high.

Software

API

An API (Application Programming Interface) was used to make control of the ReCoRVVA as versatile as possible. This worked by using a Python socket to create a server on the ReCoRVVA and using a wrapper (to make connections and control as easy as possible) on the client side (as seen in Figure 3 and Figure 4). We spent quite a lot of time, possibly slightly too much, making this fool proof and reliable, which we all thought was necessary. However, it allows the robot to be controlled from ANY internet enabled device which, we think, is a really great feature.

The server has separate threads dedicated to different aspects of the robot, e.g. communication, movement control and camera/servo control, among others. Having different threads allowed us to do everything simultaneously which made everything much more reliable and made the control of the robot instantaneous. The API had a set of specific commands that the client could send and use.

Table 1: API Command reference

Command	Purpose
F	Move forward until next command
B	Backwards (ditto)
L	Left (ditto)
R	Right (ditto)
S	Stop
CamOn	Turn camera on
CamOff	Turn camera off
pan_left/right/centre	Control camera servos – turn by a unit of 10°
tilt_forwards/backwards/up	As above but tilt
HH	Switch headlight to high setting (on)
HL	Switch headlight to low setting (off)

If the server receives an unrecognised command, it refuses it with no feedback to the client but logs the event to the server log. The server also denies connections from all unauthorised clients by checking that their hostname matches a preset list of allowable clients. This is a useful security feature as although not secure it provides a basic security measure.

The API’s main feature is that it allows anyone to write a client for his or her own controller. For example if the client/user wanted to use a radio control device to control the robot, all that they’d have to do is to write the script(s) that incorporate the radio controller and then insert the wrapper’s commands inside that as we did for the Wii and Xbox (see below).  The Python wrapper was just a simple example script showing how to communicate with the server using the API.

Controllers/User Interfaces

We had two ideas to start with: the Ardumote app for development and the TKinter for testing. We also planned to try to integrate an Xbox and a Wii remote to provide an easier and more intuitive way to control the vehicle.

1. Ardumote App

   The Ardumote app was simply to be a testing platform and was not intended to be a means of controlling the finished ReCoRVVA.

   The Ardumote app provides a means of easily sending small packets of information to a particular IP address, by pressing buttons on screen, which we preset to send certain messages to the ReCoRVVA server. In this way it was possible to develop and test the drive function and camera pan/tilt easily, though Ardumote had its drawbacks in the fact that it could not receive video/images or large amounts of data back from the ReCoRVVA server.

2. TK user interface

   

   During the research stage of the project we came across a platform for Python that is a framework for building simple interfaces called TKinter (TK Interface). We immediately tried it out and were very pleased with the results.

   We then investigated using the interface as a control point for the ReCoRVVA. After some fiddling around, we got it to work using a modified version of the wrapper script.

   The next step was to get the camera feed to appear inside the interface. This, to our surprise, was very simple to do and worked perfectly using a second thread to display the camera feed. Until this was done, the feed forced the control window to update every 0.5 seconds - making it impossible to click on the buttons!

   We used this interface mainly as a test platform but it is understood by the team that anyone with Python installed on their computer can use this interface. We think it greatly contributes to our objective of versatility, allowing even more people to control the robot in their own way.

3. Xbox controller

   Our plan for the mobility of the robot included devising a program for an Xbox controller that enabled the user to move the ReCoRVVA forwards, backwards, left and right.

   The main job to connect the Xbox controller to the ReCoRVVA was to use a Python script, which could talk to the API. First we had to obtain a controller, and a wireless receiver. The receiver needs to pick up the signal from the controller and send the data to the ReCoRVVA. We had to do this by connecting the controller to the receiver via a Raspberry Pi and using an existing Xbox controller library. We then had to hold down the connect button on the Xbox controller while doing the same action on the receiver to make them connect to each other. Then we used the API combined with the wrapper that took care of the communication with the ReCoRVVA. The wrapper makes it a lot easier to communicate with the ReCoRVVA as it takes care of all the server communication behind the scenes and making it easier to control it. Therefore we didn’t have to use lots of Python socket commands every time we wanted to send something. Then we connected the controller to the Pi, which enabled the wrapper to send the data to ReCoRVVA. Initially there was some difficulty connecting the Xbox controller as it wouldn’t connect to the receiver. To solve this problem we had to run the command rmod xpad on the Pi, which rebooted the receiver, enabling it to connect to the Xbox controller. Python was the best programming language because it is simple and easy therefore enabling us to do the above.

4. Wii control

   

   We also wanted to use a wiimote to control the ReCoRVVA. The wiimote communicates using a Bluetooth protocol so by using a Bluetooth dongle plugged into a Raspberry Pi it is possible to communicate with the wiimote. We used an online library called ‘cwiid’ and wrote a Python script, which reads button presses and accelerometer readings from a wiimote. This script then uses the Python wrapper intended for the communication with the ReCoRVVA API to send the control messages to the vehicle. Initially we faced some problems with the server communication but we worked together over GitHub and improved both the wiimote script and the wrapper. This included modifying the behaviour so that the client properly disconnected from the server, so that the server could start new connections to other clients. It could not do this before.

5. Web-based interface

   

   Although we had originally not planned to build a web-based interface, towards the end of the project, we had some time left and we found an online toolkit, PiUI, which is a web development toolkit written in Python and is designed to be used to control a Raspberry Pi via a web browser (Figure 13). So we used this to make a simple web-based GUI using the wrapper script to communicate with the API and we were able to include the camera feed as a regularly refreshing image. This worked really well.