At the end of our project our initial objectives had now been added to and matured through the development process.
Objectives at the start
The objective of this project was to build an all terrain vehicle which could be used for various applications and controlled from anywhere in the world. We wanted it to be operational in all circumstances, which meant being able to operate in low light/pitch dark conditions and being able to traverse all terrain. It was essential for the user to be able to see from the ReCoRVVA’s point of view in real time. We also wanted the ReCoRVVA to be able to sense when it was about to crash and automatically stop to avoid collisions.
Objectives at the end
The ReCoRVVA is controllable from anywhere in the world, the user can see in real time where they were driving and knows the environmental conditions they were operating in. The ReCoRVVA is able to automatically stop if it senses an obstacle.
We have also shown that it can be adaptable to any circumstance and any user or their medium of control.
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:
Power – current draw was too high. Adding on more battery packs solved this.
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.
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.
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.
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.
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.
Last year, I and two of my friends, Ben James and Angus Ledesma, decided to create a Raspberry Pi powered robot for a Silver CREST project. I posted an overview of the project last July and have finally got around to converting the CREST report to a blog-friendly write-up!
The ReCoRVVA will help and assist people in many different ways; as the name suggests, it is designed to be used for many purposes.
At its simplest it is a vehicle designed to be controlled remotely by an operator with the aid of a live video stream from the robot. It could be used as a security patrol vehicle for surveillance, or to regularly check on an elderly relative remotely. It could also be used to inspect small, hard to reach areas with its camera and lights that humans wouldn’t be able to reach. Young people will benefit by being able to play with the ReCoRVVA or maybe by using it to play espionage or sneak up on their friends and family. Or their hamsters. Though designed for the role of remote access and communication it’s truly adaptable.
Our initial ideas for applications came under 5 main categories: Security, exploration, human safety/communication and remote sensing.