Cocoabot

Posted on 01/04/2013 by ressy
Modified on: 13/09/2018
Project
Press to mark as completed
Introduction
This is an automatic import from our previous community platform. Some things can look imperfect.

If you are the original author, please access your User Control Panel and update it.

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 ...


Cocoabot

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
LikedLike this to see more

Spread the word

Flag this post

Thanks for helping to keep our community civil!


Notify staff privately
It's Spam
This post is an advertisement, or vandalism. It is not useful or relevant to the current topic.

You flagged this as spam. Undo flag.Flag Post