Let's Make Robots!


Navigates via accelerometer

This is only complete in so far as it is a completed intermediate step in the development of another machine, but as a test platform I won't be developing it any further*.  As it stands, DAUGFOETUS is about putting into practice the methods and code that OddBot so generously generated in my tip/walkthrough on using the MMA7361 outboard on an Arduino.  The platform is for my K-9 WIP, not posted yet (thus, the name refers to a pre-nascent dog.  It's is also kind of a shout out to our homie Kariloy who has a brilliant knack for coming up with long, esoteric robot names.)

The base is 6mil Sintra, the motors are 6v 72rpm geared sets from eBay and the motor mounts are custom aluminum.  The motor controller is a Hex A00331 L298-based unit, which I'm loving.  I bought three of them for a hair under U$12.  They work brilliantly.  The wheels are Banebots 3 7/8" hard 50 shore.

Lesson Learned #1: As you can see in the video, figuring out the values for the sensitivity variable is of great importance.  The platform responds to each forward impact (I didn't code for when it backs into anything) but it also responds to bumps in the floor, shakes of the "stalk" on which the sensor is mounted-just about anything.  This was not optimal mounting for the bot-essentiallly I zip-tied the DuPont wires connecting the accelerometer to the Mega together.  That probably accounts for most of the false impacts that it reacts to. (For K-9 I'm actually breaking down and having a PCB made to mount the MMA over an ATTiny 44 so that I can use the ADCs in the ATMel Chip to talk to the BeagleBoard via serial.)

Lesson learned #2: a castor in the front of a bot is a losing strategy in any situation where rugs come into play.

Lesson learned #3: if you aren't going to put a power switch on a platform this size (ie, you're using the battery plug to determine the on/off state) don't engage the battery harness while the robot is in your lap and you're wearing flannel pyjama bottoms.



(*Also, I just got tired of seeing the same bot jump to the top of the queue without any content updates.  For that reason, I provide the following counter, which will allow me to change only it whenever that other, unnamed machine mysteriously is updated without updating anything:)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

could you use a standerd arduino

You can use any processor with analog inputs. The Accelerometer we are talking about has 3 analog outputs, one for each axis. It needs a 3.3V supply so to get full resolution on a 5V Arduino you need to connect the 3.3V to Aref and be careful not to use any analog sensors with a 0-5V output.

My original accelerometer Impact Dectection code measures all 3 axises when determining the magnitude of the impact. In your design you really only need to use two axises, X and Y as shown in the diagram. Any acceleration on the Z axis is likely to be a result of a bumpy floor and can be ignored except when determining if your robot has accidentally flipped over and is now doing the backstroke.

mounting the accelerometer on the wires like that more or less disables the impact detection ability. The accelerometer must be mounted hard on the chassis so that an impact is a sudden, sharp change in acceleration / decelleration.

When you mount it on a soft springy mount then this completely filters out the impacts and leaves you with low frequency vibrations being amplified by your wobbly mount.

I was surprised that it worked at all with the sensor on the end of what amounts to a shock absorber, truth be told. I was rushing and trying to prove the concept for the next steps in development. When I saw a)occasional uninterrupted forward motion and b) the predicted reaction to a crash (reversal and turning away from the impact zone) I was way more than happy and took it as further validation of my faith in your method, Oddbot! (In other words, even my laziness can't overcome your mindfulness!)

maybe a rubber washer between it and the body would cut down on the sensitivity of the accelerometer

Many thanks for the reference-'homage' bit. However, I must say that when I first saw this earlier this morning what I first read was "DOGFECES", then I look at the author pic and think... "oh, max, this must be an update on the dog-poop-scooper", *clicky* look at the picture and think "wait a minute, this looks only barely similar, and those wheels are not good garden wheels" only then did I read the description :-p

Anyhow, it's looking good but yeah it clearly need tune up so that not every tremor is a registered bump, but hey, it's just me stating the obvious, which btw has already been stated before :-)

P.S. - I'll should see if I have any project in need of adding/removing punctuation on description so I can join in on the un-named "fun" ;)


great stuff... this is purely bump navigation?  I think with an accelometer for bump navigation a wire hoop around the robot as a bumper would work really well to give an accurate bearing for the contact.

I haven't looked at oddbots code so i apologise if this is already covered:

How about a dynamic sensitivity variable, possibly via an updated average 'terrain' variable if you get my drift?  I used an ultrasonic library where it also gave a return of something called a ... deviation? standard deviation?  can't remember exactly but it was pretty much a number that told you how far away from the current average reading each result was, which then let you filter the results very easily (this is what i mean by a dynamic average terrain variable). It also let you see any really significant bumps as the deviation variable would be a lot larger than usual.

any plans to try out the accelerometer for localization to replace/assist wheel encoders?   I would like to get an accelerometer to try this.

Is the racing pack 3300 mAH?  What sort of power circuit are you using?  How much were the gear motors?



Well, the whole point of OddBot's code is to avoid having a ring of contact switches around the perimeter. This method is fairly effective at achieving the same effect in that regard. (Neiter method-in fact NO method of crash/object detection is fool proof of course.) There are several variables in the code that deal with the magnitude of the crash and one version of the code even converts the readings into degrees. I didn't use that version here though-this was quick and dirty proof of concept stuff. In the tip/walk through, I theorize a little about using it for localization, but Oddbot is skeptical of its viability. The problem is that it senses acelleration, not motion, so if the motion it achieves is steady enough the sensor won't know the difference between rest and motion states, just the states in between. Obviously there would be a zone of error for every bot. Okay, let's see... The racing pack is the one you mentioned, the power is supplied to everything via the Rex board and the motors were I think about U$6.

sorry i wasnt clear... not a ring of contact switches, just a wire hoop attached firmly to the chassis to make the contact distances on any bearing an equal distance from the center of the bot.... basically just a round bot i guess hehe.  nevermind, silly idea xD

i really should start work on localization for my bots