After a hectic last week or two of tuning and calibration, the mbed rover is finally ready. As a test of its odometry, inertial sensors and filter I decided to drive the rover around in a 1 metre square and see how close it could get back to its starting position.
I programmed the movements commands for it follow like so:
The movement distances are in metres, and the amount to turn is in degrees.
Here's how the rover performed:
The rover keeps track of its heading during the straight line sections, and corrects its orientation on the turns based on how far it has deviated from the initial heading at the start of the straight line section.
Conclusions
I started off this project with very little knowledge about robots, inertial sensors or closed loop control. Now that I've reached the end, I have not only learnt a great deal about all these things, but I have also implemented them to a relatively high degree both in terms of the final application and the mbed libraries I have created along the way.
Feedback
The most important thing I have taken away in the construction of this robot and its ability to perform dead reckoning is the use of feedback. As mentioned in an earlier post, it's easy as humans to forget how much we rely on it - we use our eyes to see how far we've walked or turned and things like the fluid in our ears help us to maintain balance.
A robot requires exactly the same sort of feedback - I had to use quadrature encoders to determine how far [and how fast] the wheels turned, and an accelerometer and gyroscope to keep track on the rover's orientation including its current heading. Without these things the rover would not be able to perform as well it does.
Future Work on Feedback
One part of the rover that could improved is adding more feedback during the straight line sections of the course:
There are currently two PID controllers making the motors run at the same speed. Currently there are a large number of interrupts to handle these controllers, reading the inertial sensors, logging data and performing filter calculations. As all the interrupts currently have the same priority it means some of the interrupts on the quadrature encoder pins can get delayed waiting for other interrupts which can throw off the feedback for the PID controllers. This can cause difference in motor speeds and thus a slightly curved path.
There are several solutions to this problem, all of which should really be combined to give incredibly accurate results -
1. Keep tracking of the heading during the straight line sections and use the deviation to correct on the turning sections (this is the simplest solution which I have implemented in the final release).
2. Have another PID control loop performed the current heading making it change motor speeds according to how far the rover is deviating from its initial heading. This can combined with solution 1 to ensure a correct turn is made, if the rover has driven relatively straight in one section but ended up in a slightly awkward orientation.
3. Make the interrupts on the quadrature encoder pins higher priority than other interrupts to ensure the most up to date feedback always gets through.
Inertial Sensors
One of the hardest parts of the project was interfacing with the inertial sensors and combining them with the IMU filter. The analog sensors that I tried originally were incredibly noisy to the point of being unusable. I had to switch to digital versions [ones that had high precision ADCs built in] before I was getting results that had any chance of being used.
I was initially using a triple-axis magnetometer along with the accelerometer and gyroscope, however there was a great deal of magnetic interference in doors and this resulted in the orientation being completely thrown off whenever it moved into certain areas.
In the end the accelerometer, gyroscope and filter alone provided high fidelity results, especially for making accurate turns, but could cause the orientation estimate to drift over time; because of this frequent re-calibration is done. Luckily this takes fractions of a second, but it still means that no absolute reference for heading is kept - everything done is relative to the most recent re-calibration point [which is every time the rover enters the Stationary state].
Future Work on Inertial Sensors
In order to really improve the inertial measurement unit I would conjecture the best thing to do is to separate it from the mbed and create a dedicated PCB with the sensors and a DSP to provide accurate sampling, reduce noise, and reduce the load of the mbed in order to allow it to focus on the high level control the rover.
Software Abstraction
The rover application class brings in all the libraries I have created and is not necessarily tied to the hardware being used. All the libraries can be used separately for other robot applications or for different projects entirely.
Source Code
You can find all the source code for the libraries used in this project in the links below:
