Let's Make Robots!

Cocoabot

remote-control surveillance with a mobile webcam

When I first got myself a Raspberry Pi, I thought I was being very original trying to put together a remote-controlled surveillance bot, and over a few months I got to the point of having the parts gathered up and a clunky-but-working web interface going.  Only then did I actually google around and discover that I'm about the millionth person to have the same sort of idea. But as kariloy said about Jon, for example, it's about making it ourselves, anyway.  My grand plan is to just go for it my own way and probably screw up all over the place, but hopefully learn as I go :)

I'm aiming to have a compact little bot with forward/reverse/left/right controls and a USB camera, with a battery pack and wireless connection for mobility.  The software I'm using has some interesting features for motion detection and recording, so I think it'd be neat to activate some of that stuff and have a power multiplexer circuit to let it run from wall power while standing guard... but we'll see.

Oh, and it's named after our cockatiel Cocoa, who it was originally intended to watch over while we're away :)

Methods:

(I'm trying to list all of the details here, so feel free to point it out if anything's missing). I have the RPi running Motion, passing video to Apache via mj-prox.  Some ugly custom JavaScript on the page serving the mjpeg camera feed captures keystrokes and sends them back to a CGI Python script, which in turn passes them through a named pipe to the Python script actually managing the motors directly over GPIO (specific parts and software given below).  In terms of wiring all it really has is a L293D with a set of pull-down resistors at each input.

I've tested this whole input/output loop as far as getting movement on the motors from a web browser, but haven't really secured it all together yet since I'm still figuring things out.  (I tried briefly just plopping it all down on top of the Tamiya chassis, and it almost popped a wheelie and then spun around and shook off most of its components. Sadly I didn't catch this action on video, though.)

Parts:

Software:

  • Occidentalis 0.2 Linux distro from Adafruit
  • Motion (package name: motion) configured to not save anything to disk
  • mj-prox (installed manually from web as a CGI program)
  • Apache (package name: apache2)
  • Custom JavaScript on the browser end, Python on the robot end (code on github)

Status, as of April 28th:

Various problems I'm working on:

  • I think I'm trying to pull too much current from that battery pack, even with the 1A connection for the RPi and the 500mA one for the motors.  (When the motors kick in the network goes all choppy and shortly after the Pi crashes, so I think that's what's happening, anyway.)  Now that I'm looking at more battery packs (how about this one Ladvien mentioned?) I'm thinking this one was a bit overpriced anyway, considering the specs...
  • The L293D doesn't want to supply the 3V that's considered safe for the motors (I tried it at 3V, too, and they're not lying-- it really doesn't work) but when I test it out with 5V input it looks like it ends up with around 3V across each motor anyway.  I don't really understand why this is, though.
  • I need to check this more closely, but it looks like not all the GPIO pins are staying at zero when it boots up, which probably explains the death-spiral it did when it first booted up (but before I started the python script).  Not sure how to deal with that yet (or what's even going on).
  • The chassis is really cramped... I might just be trying to cram too much stuff onto that little platform.  Along with the motor and battery troubles there's probably a better solution for this part.

Mock-up with everything perched on the chassis:

All the parts so far:

May 11th:

I thought I was onto something after figuring out the broken pins, but even after wiring it up with known good ones, I had the same result as last time.  Luckily, this time I was prepared for the event and got a short video.  Back to the GPIO drawing board for now.

Comment viewing options

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

Not sure what to tell you.  

Seems like everything checks out but physical pin 13.  I tested your code on my Pi, my 13 pin read 3.28v.  Poor Pin 13--let's have a silent moment.

Thanks for taking the time to try it out on yours.  I guess even without #13 (or 3 and 5, they're stuck too) I should still have plenty.

Well, if I'm careful with the rest, at least!  I wonder if some kind of isolation (like what you mentioned here) would make things safer.

I believe those motors are a standard size.  Look here (under complementary products) for more information on replacing them.

http://www.pololu.com/catalog/product/114

 

Thanks, I see what you mean-- following some links I see references to "130-size" pop up all over the place.  (Can't figure out what the significance of "130" is, but that seems to be the pattern!)

Following another link, I'm amused to see "Frustrated by those cheap, low-voltage motors that require too much current?"  (Yes, apparently I am!)  Sounds easier/cheaper to just use one of those replacement motors than a fancy controller, though (?)

Nice :D At least I know someone actually reads my posts beyond looking at the pictures videos (well at least the intro paragraph :P)

I think Lad covered most things but regarding your current power supply... damn it was expensive. Currently I'm using one similar to Lad's (as I'm sure you know) which was much cheaper and has greater capacity. Regardless, I'm waiting for another one with supposedly even more capacitty (20,000mAh) to arrive in the mail which costed about as much as the solar one w/ 5500mAh (under $20) and although having no solar panel has 2 USB ports that supposedly can output currents 1.1A and 2.1A.

Another note regarding you current setup: Recently I read that the original tamyia motors are very noisy and consume much more current then need be. There seems to be some nice replacements for them that consume much less current. Still one thing that you could do for the time being would be adding buffering capacitors in the motors power lines to try and mitigate some of that wobbliness. Also some filtering capacitors on the motor leads might help remove some electrical noise.

Thanks kariloy, you and Ladvien confirmed what I was suspecting about my battery.  2.1A + 1.1A  (rather than 1A + 0.5A) sounds much more comfortable for the amount of stuff I'm trying to run, too... this gives me a better sense of what's probably a realistic choice.  I can always use this one to recharge my phone, anyway :)

About the tamiya motors, do you think there would be replacements around in the same sort of form-factor?  (It'd be nice to clip them right into that gearbox like the originals, but I'm probably being too hopeful there.)  I'll definitely look at some filtering/buffering capacitors, too.  I'm thinking something big -- what, hundreds of uF range? -- across the supply to the motors, and smaller ones across each motor itself?  I can see the benefit to a totally separate supply for motors, but I'm curious to see what I can finagle with this sort of method-- it'd be nice to stick with a single power source if I can manage it.

Another Pi bot! :)

I wouldn't compare, my friend.  As long as you're happy. Besides, we each add something to the collective knowledge of bot building with every creation.

I think I'm trying to pull too much current from that battery pack, even with the 1A connection for the RPi and the 500mA one for the motors.  (When the motors kick in the network goes all choppy and shortly after the Pi crashes, so I think that's what's happening, anyway.)  Now that I'm looking at more battery packs (how about this one Ladvien mentioned?) I'm thinking this one was a bit overpriced anyway, considering the specs...

I think you're dead on.  And you're right, don't buy that battery.  Mogul posted a link with a similar battery on eBay for half the price.  I can't find it now, but I do know that solar battery on eBay will range from US $9.99 to 17.99.  All you'd need then is the regulator. I did read this fellow's post about PCB design; and basically, as I understand it, you want to use different batteries for your inductive loads (motors) and microcontrollers.  In short, no amount of noise filtering will be better than separate power sources.

The L293D doesn't want to supply the 3V that's considered safe for the motors (I tried it at 3V, too, and they're not lying-- it really doesn't work) but when I test it out with 5V input it looks like it ends up with around 3V across each motor anyway.  I don't really understand why this is, though.

Regarding the L293D having a different output voltage, this is due to the L293D having a voltage drop of around 1.5v.  That means, whatever you supply it with, what it sends to the motors will be 1.5v less.  There is a post about L293D chips written by our benefactor.

I need to check this more closely, but it looks like not all the GPIO pins are staying at zero when it boots up, which probably explains the death-spiral it did when it first booted up (but before I started the python script).  Not sure how to deal with that yet (or what's even going on).

Without knowing which pins your checking, I'd guess this has to due with the pull-up resistors built into the Pi.

The chassis is really cramped... I might just be trying to cram too much stuff onto that little platform.  Along with the motor and battery troubles there's probably a better solution for this part.

That breadboard looks like it eats space--SMD, my friend, SMD. :)

Oh, and video?  Given the golden rule here at LMR.

If the pins are staying at Zero during power up, I would imagine there are pull down resitors. Pull up resistors would be HIGH all the time, unless they were actively pulled low. i2c lines are set up like that. I believe pull down resistors waste less power.

Like Mr. Birdmun said.

:)

And Ladvien, those links are extremely helpful.  (I appreciate your thorough cost-tracking on your PCB writeup, by the way.)  I'll be mulling over these power supply/motor/circuit ideas and see what comes from it.  Every time I even glance at this site I feel my brain straining to take everything in :)

As for the GPIO stuff:  from pages like this one I thought the pins I'm using would be set to inputs by default, and my own resistors at each pin would then pull them to zero, but it doesn't seem to be happening. I just need to review the specs on all this and test it out directly, I think.