Ok, so we have a sensor that can detect X- and Y-movements, and two motors who can make the device go forward, to the left or to the right. The sensor can detect forward movement just fine. The sensor isn't made to detect angular movements, though, but the way it's built in should help here. If the bot turns, the exact point it turns around probably is somewhere towards the front. Because the sensor is all the way back, the sensor gets dragged around this point and will notice the movement on its x-axis. So, any reading of x-movement from the sensor should indicate it's turning... at least, that was the idea.

I've never been really good in implementing feedback loops, it all happens by trial-and-error a bit... but I eventually ended up with code that at least seemed to do the right thing: The main loop of the program reads out the mice, then adds the X-displacement to a global variable. Normally, this variable should be 0, because there shouldn't be any movement in that direction with the bot going straightforward. If the cumulative displacement does fall under or above a certain treshold, the bot will gradually turn off one of its motors to try to get the value back to 0 again.

Did it work? Well, at least it's better than a plain ole el-cheapo bristlebot:

What seems to be happening here is that the movement of the bot is a bit more complex than I thought. The bot not only goes forward or turns, it 'strafes' too, meaning that it goes sideways without actually changing the direction it looks in. The problem with that is that the mouse sensor picks this up too, and the firmware doesn't know better than to interpret this as a change in direction. It'll try to compensate for this by turning, and that's where it all goes bad. This strafing-like behaviour seems to have both a constant and a random factor in it. In the above video the firmware compensates for the constant error, but the random factor still makes the bot deviate from its ideal path.

« Prev 3 Next »

© 2006-2016 Sprite_tm - Contact