Assembling the components


The first prototypes we put together used an Arduino, and it was with these first prototypes that we had many problems with the motors.

The first thing we tried was to run each motor from one of the Arduino’s digital pins. They were 5v motors, and the digital pins on the Arduino supplied 5v each, so we assumed the motors would run. We wrote then uploaded a simple drive script to the Arduino.

However, the motors didn’t turn. We debugged the code and found no errors, we checked the pins were supplying voltage and yet the motors still didn’t turn. Eventually, we realised that there was a limit on the amount of current able to be drawn from each digital pin on the Arduino, and that we were exceeding this limit. The motors ran from the Arduino high current 5v supply perfectly, but there was only one of these constant 5v pins. We initially considered using transistors or relays to control each motor individually, and built this circuit with transistors, which worked well. Then we realised that this only allowed the motors to go forwards, and if it got stuck in a corner it wouldn’t be able to get out unless the motors turned backwards. This was solved by using a dedicated motor driver to control the motors.

While we assembled the ReCoRVVA, we tested it as we went, mainly using the Ardumote app (see controllers/user interfaces section). We had problems with nearly everything including:

1. Power – current draw was too high. Adding on more battery packs solved this.
2. Jittery servos – this made the camera judder. This was fixed by using a hardware PWM library on the Pi to send control pulses more accurately to the servos.
3. Weight balance problems – the additional battery packs caused the vehicle to become unstable so we had to re-arrange them to make sure the vehicle didn’t tip over.

Although these kinds of problems seemed difficult to overcome at the time, we learned immensely from them in the long term.

The importance of backups


During early development our main Pi was dropped, and though we managed to fix the small amount of damage, the SD card with all our programs on could very easily have been damaged or corrupted. We realised at this point that we should make regular backups to preserve our work. Not only this, but we wanted there to be the option that if a similar incident occurred again, we could substitute another Pi with a different SD card onto the ReCoRVVA and have it work immediately again. We wanted this as an option not only for the drive computer/server Pi, but also for the client Pi used for the control of the server. Therefore we decided to extensively use GitHub and git (a command line application for GitHub) to achieve this, to make sure we could apply the server and client scripts to any Raspberry Pi simply by running a “git clone” command.

You can see the frequency of ‘commits’ (saved edits to the project software scripts) during March to late May on our GitHub repo and also to the right. Most of the development took place in March and April with the majority of the later (May) work being bug fixes after two testing periods.

Testing

Throughout the testing procedure we found a lot of things to be improved that we wouldn't have noticed in the theoretical design process.

An example was our code for controlling the pan/tilt of the camera mount servos.

We found when we tested the pan/tilt function that the servos would only move to their extremes; i.e. if we sent a command to move them left (intending to move them left a small amount) the mount would move all the way to the left. This was only a small bug in our code, and we rectified it so that the mount can now be moved in small increments on both axes.

Another example of this was testing the ReCoRVVA with the wiimote. Since the code was designed to steer the ReCoRVVA when the wiimote was tilted, the ReCoRVVA would start moving left/right when it hadn’t even been told to move forwards yet, as a result of someone picking up/nudging the wiimote. Again, this was easily resolved, and now the accelerometer in the wiimote is only being read when the ReCoRVVA is already moving forwards or backwards.

We hadn’t noticed these bugs until we physically tested the ReCoRVVA, and this showed us the importance of rigorous testing as it highlights things we wouldn’t have picked up otherwise.

When the final assembly was complete (Figure 17), we tested the robot over a 50 mile operator/ReCoRVVA distance to test speed of interaction and response speeds. Footage of this test is shown at the end of this YouTube video:

Finnian, with the ReCoRVVA, dictates instructions to Ben over Skype (50 miles away) who controls the ReCoRVVA with a wiimote according to Finnian’s instructions. At this point we were having issues with the camera feed working over the VPN. This is now fixed.

The data flow looked like this:

Once we’d tested the ReCoRVVA ourselves, we decided to make sure it was fully user friendly by giving our family a controller and only a few words of instruction and seeing what happened! The results were good; after a few minutes they really got the hang of it and we were pleased that they found it easy and logical to control.

We also tested the ReCoRVVA outside on various surfaces, to test its mobility and durability. Again, we were pleased with the results, though we found that when faced with a steep incline the ReCoRVVA has a tendency to tip over, due to its fairly high center of gravity (partly because of the servo mount). If we were to build the ReCoRVVA again we’d try to improve this.

On the whole we were very pleased with the results of testing.