Cocoabot

Let's Make Robots Robots
1

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.

remote-control surveillance with a mobile webcam

  • Actuators / output devices: tamiya dual motor gearbox
  • Control method: Wifi connection to Internet
  • CPU: Raspberry Pi Version B
  • Operating system: Occidentalis v.02
  • Power source: 5V USB Battery (3300 mAh)
  • Programming language: Python, javascript
  • Sensors / input devices: generic UVC webcam
  • Target environment: indoor
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/cocoabot
2

Nice :smiley: At least I know

Nice :smiley: 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.

3

Thanks

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 :slight_smile:

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.