Pete @ Techno-Stuff has just sent me another new sensor from Techno-Stuff. This time it’s a Accelleration / Tilt sensor. Instead of going into great detail on how it works, I will quote from his site:
“ The Accel Sensor lets your robot measure it’s acceleration. The sensor can also be used to measure tilt. This is a two channel device that lets you measure acceleration or tilt along two perpendicular axis. Acceleration is a change in speed. When you push the gas pedal of a car, and the car speeds up, this is acceleration. The Dual Acceleration/Tilt Sensor (Accel) measures acceleration by it’s effect on a small mass. The sensing mass is also affected by gravity. Because of this, the sensor can be used to measure gravity. Gravity is constant, and points straight down. Since the Accel sensor can measure gravity, you can use it as a tilt sensor. The sensor is most sensitive to tilt when it is mounted so the sensing channels are perpendicular to gravity. (the electrical connector is horizontal) When mounted this way, the light sensor value will be 50, indicating zero acceleration. The value will increase or decrease depending on the direction of tilt. “
So, to put the sensor to the test, I thought what better way to do this than to use my NXT kit.
Kill 2 birds with one stone – test the sensor, and see how it works using the NXT and a home-made NXT conversion cable. The general idea was to build a robot that would navigate over varying terrain (eg. a few books etc), with a high center of gravity so that it could easily flip forward or backward. Then, to have the center NXT brick unit (seen in picture) to auto level itself to ensure that the robot weight was balanced and not flip over.
The Tilt Sensor would allow for it to detect when it was riding up on an object and then shift the NXT unit forward or back depending on where the weight was shifting.
A close-up shows the Tilt Sensor mounted in the front area (grey brick). The sensor must be mounted parallel to the ground to ensure that true “flat” can be calibrated. The Ultrasonic sensor was also programmed for basic object avoidance. Mounted high to only catch large objects in front. (The goal was to have it avoid things like walls etc, but not obstacles that it would be able to climb over).
When programming and testing the sensor on the robot, I found that the sensor is quite sensitive to slight movements. This is not a bad thing – it is by design and necessary as you want the sensor to return ALL values it is reading. The issue is that as the robot is running, the sensor is returning values between 0 and 99 that indicate level readings for the robot. In my case, a value of approx 38 – 42 was used to indicate “parallel” to the ground. This is the place the robot was programmed to stay at. When a value would dip below this, the motor would trigger and attempt to bring the sensor back within range. This all works fine when everything is happening in show motion and little vibration is introduced.
However, bring reality into the game, and this not the case. In reality, the robot is moving around, jerking a bit here-and-there. When the robot goes off balance, the motor will trigger it to come back into balance (hence more vibration and jolts to the sensor). All of this causes the sensor to throw erroneous values as it is operating (at no fault of the sensor or its design). In order to compensate for this, you have to develop an “averaging” function that will take multiple readings every so often and take the average of those. That average value should be the value that you use to tell the robot whether or not it should attempt to re-balance itself.
I did many tests to figure out the best way to do this. At first I introduced a delay of 1 second between each check loop. So, the robot would only check every second if it was out of balance. This had pretty harsh results. In the end, I realized I would let the loop cycle as fast as the firmware/cpu would let it (reads – no delays between the loop). Inside the loop, I initiated another loop that would take 10 readings over a very short period of time and then average them out so that a more accurate value could be used to check the balance. This smoothed the response of the robot. I also found that motor speed played an important role on how fast the robot would react as well as how harsh the reaction was. A motor speed of 100 was too harsh, while 65 was not quite enough. I settled on 75.
Summary: After some fine tuning, I manage to get a function that worked quite well. However, even after all of this, there are still times where the robot seems to get stuck in a constant rebalancing routine. When it gets started, it cycles back-and-forth between the centrepoint. The only way to stop it is to limit the shaking of the sensor. I suspect that with some more fine tuning of the balance function, this could be eliminated. In all, this is an interesting sensor. I have not yet tested the acceleration feature. Why? Well, I have not yet thought of a robot idea! However, I am already working on my next test robot for the tilt sensor. Hint – it uses some never-seen Lego tracks and an intuitive “track widening” mechanism to spread the weight (and balance) over a larger area…. More in this in the coming month or so…. Click image for a larger pic.
This picture shows the robot in a mode where the NXT unit is tilted to the back. To envision this, picture it just finishing a climb and then driving back down a steep slope. The NXT unit would be forced to the back to counterbalance the robot. Click pic to enlarge.
Showing a close-up of the NXT balance drive mechanism. A NXT motor is directly connected to two turntables which in turn connect to the main chassis and allow for the NXT center console to rotate freely from the main chassis. Click pic to enlarge.
Another close-up of the balance drive mechanism. Click pic to enlarge.
A view from the underside. Shows some techniques used to build a semi-rigid chassis foundation platform. The gray corner connector pins are a MUST for studless building. Click pic to enlarge.