Let's Make Robots!

Dagu Adventure / Mr.General - Is "turn on all the servos" an error of some sort?

So I've gotten my Dagu Adventure Bot running and have successfully been putting code on it.  I've turned off the sound, I've played around with the "light chase" mode and edge detection sensors, and so on.  So I'm pretty confident that the code I see is the code that's making it down to the bot.

Here's the weird thing.  Whenever I run the out of the box code, with nothing commented out?  Almost immediately the robot's head whips around until it is tucked down and to the right, and then it tries to go into some sort of spin.  I don't know much about the mechanical bit of what's going on but it seems to suddenly go all "Drive all the servos to the max". It is unclear to me whether it's gone to the max position and stopped, or if it is actually attempting to drive past its limits and potentially break itself. When it gets like this it seems to be ignoring the sensors, and no amount of trying to get my hand in front of the head will make it leave this position.

Is there any sort of error condition that might cause this as an expected behavior?  I've not yet found anything in the code that would make it do this -- all the movement routines seem wrapped in a combination of "only move X amount at a time", and "make sure you don't go past the defined range for this motor."

I am working my way through the code systematically to determine if this is in fact something the code is telling it to do.  If I turn off the wheel motors completely, I can never make it do just the head thing.  

Is such an error even a possibility? Where, despite my code saying "Turn the motor off", they are all still powered?

Comment viewing options

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

Yes, you will need to tweak the leftmotorstop and rightmotor stop values to suit your servos. They may also need tweaking with a change in temperature such as a cold night or a hot day. Same goes for head center positions although make sure the head looks up slightly. Some floor surfaces reflect the IR very well and then the robot just runs along staring at the floor.

Keep the value of 1500 in the formula as this is the theoretical centre position. Ajdust your neck LR center and neck UD center as required. This allows for mechanical variation within the servo.

Ok, none of those photos showed me the motor inside of the servo. doesn't matter, try this. In the sample code below I have added a simple formula to reverse the direction of the servo when updating the servo position.

void loop()
  if (millis()-time>249)                                      // has 250mS elapsed (1/4 of a second)
    time=millis();                                            // update time
    lightchase=lightchase+1-4*(lightchase>3);                 // change LED pattern every 250mS
  leftmotor.writeMicroseconds(leftspeed);                     // update the speed of the left motor
  rightmotor.writeMicroseconds(rightspeed);                   // update the speed of the right motor
  neckleftright.writeMicroseconds(1500-pan+1500);             // update the position of the pan servo
  neckupdown.writeMicroseconds(1500-tilt+1500);               // update the position of the tilt servo

  IReye();                                                    // read the eye sensors
  IRfollow();                                                 // move the head and body to follow an object
  ObjectDetection();                                          // read corner sensors, turn on corner LEDs and prevent collisions



I got a fresh download of the sample code, to make sure that none of my messing around would get in the way, and applied your change.

Success!  He now headtracks properly, turns his body in the right direction and drives forward toward a nearby object, but backs away from an object that is right up in his face, just like he did out of the box.  Thanks!

There's a little roughness around the edges, but I think I can work those details out.  For instance when just standing still, he actually is rotating in a slow circle by driving one wheel.  Maybe the value for one of the stops (currently set at 1480 and 1490 out of the box) are not precise enough?  After posting this I will play around with setting those values differently.

Likewise I notice that his head turning is a little more, stuttery?, then he was when we first played with him. I notice in your code you used a constant of 1500 for both the LR and UD values, but the constants in the sample code actually show a 1550 for LR.  I'm not sure which is correct, but I'll play with it.

Thanks for all the help! The above two details are trivial and not even something that my kids would notice.  Plus I'm almost certain to break the thing in a more spectacular way very soon. :)


Definitely using NiMh batteries, I did my reading before hand and didn't want to screw it up :)

The CD I received came with a manual for the Adventure Robot, and an arduino-0018.zip file.  But inside the Zip there's a whole bunch of lower level examples and libraries, but nothing like the Adventure_Robot.pde file (and associated headers) that I was able to download.  So, I've been using that.

Upon further investigation I think that the "down and to the right" problem might indeed be a valid response where the bot gets stuck chasing its tail, only in this case it's trying to get away from itself.  It seems its own sensor light as an object and then tries to back up away from it, but of course the light follows it and it looks like an infinite loop.  That's just a guess based on what I'm seeing.  I noticed that when I moved the bot from my crowded desk (where who knows what might have been triggering the edge sensors) out to the wide open rug, the behavior almost went away (but I can still cause it).

Refresher on current status and what I'm trying to do : Out of the box the robot behaved in what I'd consider to be a very cool way, doing that "turn your head and follow the object in front of you" thing that I'd seen in the demonstration video.  However, after updating for the first time with the downloaded version of the Adventure_Robot.pde (with no changes other than turning off the sound to avoid upsetting my coworkers), it behaved radically differently, failing to follow an object like it used to, and going into these tail chasing spins.  So it seemed to be a case where the downloaded code is different from what was originally on the robot.

Right now I'm tweaking on a bunch of variables to try and get it back to something resembling what it did out of the box, before I go trying to do anything fancy.

This is intended as a gift for my kids, but I want to fully understand what it does and can do, and why it's doing it, before I let them at it.  



I am not sure why it did not come with the code on the CD, I will get that sorted out. In the mean time, your problem is definitely because the servos are turning the wrong way. This means that when it tries to look at something it actually turns away and the more it turns away the more it tries to look at it so the robot effectively tucks it's head and chases it's tail.

Please post some photos of the head / neck so I can check it had been assembled correctly and what type of servos are used.

When you say you downloaded the code, where did you download it from? I need to make sure there is not two versions of the code.

In the I/Opin tab, you can swap the IRleft and IRright pin values. Also swap IRup and IRdown. This will correct for the servos but may cause the body to turn the wrong way.

Once I see a photo of your robot then I can send you correct code.



Hi Oddbot,

I wasn't quite sure what to take pictures of, so I tried to get a few angles.  Let me know if I can provide more detail.  The weirdest thing to me remains the fact that out of the box, before updating code, it seemed to be working fine.  So I am at a loss as to how it now appears to be a case of swapped motors or some other hardware issue, unless when it was assembled somebody modified the code, and by updating the code I blew that away.  But it does give me hope that the solution will be a software one :)  Thanks!

UPDATE - Since it's probably important, and not clear in the pictures, the text on the side of each motor reads:


The code comes directly from the Dagu Homepage: https://sites.google.com/site/daguproducts/home/download-page

I did what you suggested, switching the IRLeft / IRright / IRUp / IRDown pins, and I believe it caused exactly the behavior that you predicted - head tracks an object correctly, but appears to be attempting to move in the wrong direction.  So if I have my hand off to the right of the head, it will turn its head to the right, while trying to spin counter clockwise.

Out of curiosity I flipped leftmotorpin and rightmotorpin, and got an interesting result - it moves *toward* things that are right up in its face, and away from things at a distance.  This is almost the same behavior that it had out of the box, just in reverse.  It did not seem to exhibit the same "turn the wrong way" behavior, but I suspect this is more because it wasn't sensing the need to turn so drastically in this situation and thus I simply did not see evidence of a behavior which was likely still there.

Since I seem to have stumbled on the "go backwards instead of forwards" pin switch, is there a similar set of pins that would produce the "go left instead of right" result?  That could be part of it.

I will send along some pictures, if you still think it will help.  Is there a particular detail you need to see, so I can make sure I capture it?  I think it's worth reiterating that out of the box, before I started uploading code, I feel that the device was doing all the right things, following an object at a same distance and always zeroing in on it, going the proper direction.  I think it unlikely that it's a case of poor assembly.  Whether something's physically changed since I received it, I can't say - but it seems like that would be a different problem. 

EDIT : Changing what I said -- after more experimentation, even in "backing up" mode with the pins switched, it's still clearly exhibiting the "turns the wrong way" behavior.  I kinda figured it must be, and I just wasnt seeing it, but didn't want to confuse the issue.  We've definitely got a "head turns right, body turns counter clockwise" situation going on here.

What batteries are you using? You should only use NiMh batteries with that robot.

Other than that, there are two different servos that can fit in the pan/tilt assembly. They come from different manufacturers and unfortunately the rotate in opposite directions.

So exactly which code are you using? The one that came on CD or downloaded from my website? If your using the CD version the try the version on my download site.


Sorry-made me think of this!