Harvey

Let's Make Robots Robots
1

Harvey is a Wild Thumper based surveillance robot intended to operate outside. Future plans are to be able to patrol my backyard with wireless video transmitted back to a video recorder/monitor. Ultrasound sensors for forward object detection, GPS for waypoint navigation, accelerometer/gyro/magnetometer (IMU), and of course a small analog camera mounted to the front. Video is transmitted via a 2.4GHz transmitter to the base station (aka my TV).  I also want to have a flashlight/headlights mounted that can come on in low light situations. Or alternatively an infrared camera for night vision.  Well those are the goals, so we'll see how close I can get to making it reality.

One of the small perks of my job is I often find myself with some cast off surveillance equipment.  In this case I've got my hands on a 2.4GHz transmitter and reciever pair, and a small 560TVL mini-dome camera.  The camera mounted oh soo easily to the front of the thumper, and the mounting tabs on the transmitter were the perfect spacing to use the four center posts of the upper plate on the thumper.  It was like destiny. :)  I also have a small infrared camera intended as a backup camera for a car.  Unfortuneately the IR illumintators appear to be nonfunctional.  I'll have to take it apart and see if it is a simple repair, for now I'll go forward with the mini-dome, which will just be blind in the dark.  Both transmitter and camera require 12v power, so I'll have a 3S 2100mAh lipo battery to power them.  The camera draws about 150mA, and the transmitter I don't have any solid numbers on, but it came with a 1A power supply.  Assuming thats the max it will draw I should get just under two hours run time with both.  Real world testing will probably shoot holes in that theory of course.

 

For motor and sensor control I'm currently using a sparkfun pro micro 5v with one of my undershields.  This is temporary, I want to design a new board with the IMU on board, and I'll work in a connection for a gps receiver.  The motor controllers are seperate individual units from Pololu.  They're the high power 18v25 brushed motor drivers, a fet based driver capable of handling the thumpers motors.  Powering the motors and microcontroller will be a 5600mAh 2S lipo pack.  I don't have any real idea how much runtime that will give me yet, too many variables to take into account.  Will just have to test it in the field (aka my backyard) and find out.  My current concern is draining the batteries too low.  I'll have to learn how to monitor thier voltages and respond accordingly.

This is the forward array of sensors I'm testing.  Three Seeedstudio ultra sound modules.  There doesn't seem to be a specific model number, but they seem similar to a Parallax Ping sensor; using a single pin for both transmit and echo.  The NewPing library works pretty well with them, and they seem accurate enough for rough forward object detection.  They are mounted to a peice of hdpe which will mount to the front of the thumper once I have the hardware in hand.

 

That's where it sits right now, this 4th of July.  While I'm waiting on some misc hardware to arrive I'll work on the wiring harness for the three ultrasound sensors.  Early next week I can test it out with just basic object avoidance bouncing around my backyard.  Hopefully I'll have some video as well.

Autonimous surveillance of my backyard, eventually.

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/harvey
2

Nice works…

Interesting, I also start (one year ago :() a similar project to crawl under the house.

I select the same beautify Wild Thumper body, used the Pololu MD03A Motor Driver Carrier (VNH2SP30) , I used the integrated current sensing to avoid overload, and a little Arduino Micro dedicated to control it.

Another arduino is used for the sensor arrays, and finally, the brain is done with a Raspberry Pi.

Do you have a communication with your Harvey (control of movment, zone to control, alarm upon detection, …) except for the video camera?

The electronic part is working, create a little iPad app to remote control it, but I get too much latency compar to the car speed for a manual fine control under the house. I need a faster network protocol or, like you, make it more autonomous. The project is in pause currently, but now, after seeing your project, I want to  resume it ;-)… so much stuff to do, so little time…

3

IR leds

Infrared illumination can be done with infrared leds. It could also work as night worker if it has quiet tasks.

4

Latency

Lag of signal can be relieved by using UDP protocol, ditching duplicate messages and shortening the loop time of the motor controller.

I had a problem of lag with my robot by driving it remotely using an ip camera and using a bluetooth connection to send commands. The camera lag can be greatly reduced by sending an image of lower resolution, and i got it more responsive by having the bot not listening to bluetooth when it was executing a command and adding a command to clear the queue of task, which is sent every time the robot has to do something which is the opposite of what it’s doing.

 

5

I don’t have any remote

I don’t have any remote control or communication with the bot atm.  Still working out what I want to integrate into the board I’m designing for it.  An xbee footprint, or just using bluetooth could both be possible, just haven’t gotten to that point yet. I’m not really looking to control the bot wirelessly, but having to chase the thing down to stop it isn’t exactly ideal. :slight_smile:

6

I never envisage to use UDP,

I never envisage to use UDP, that is an interesting idea… need to do some performance test on it.

I used UDP instead of TCP on big “realtime” industrial control system, but was for the Multicast aspect of UDP, and did some serious code to add a reliable multicast protocol on the top of UDP.
To control a robot, it is overkill, but still, some point may need to be addressed:

- congestion control: it is easy to overload the poor wifi with tons of messages, and for UDP we will need to send all the time the same command, just in case some messages are lost. With UDP I send command only when a change happen (start, stop, turn, …) with some keep-alive messages… just in case the robot is out-of-range…

- out-of-order delivery: my home network topology start to be a little complex, probably will never get out-of-order message, but can be messy if happen… instead of “forwad” “forward” “stop”… it receive  “forward” “stop” “forward”… it may shake the camera a lot (The Wild Thumper get powerfull motors and stop include breaking in my case, and “forward” after a “stop” is progressive to limit current…

and I do not mention Internet access… UDP is not friendly to firewall, but anyway latency in this case is also out-of-control.

anyway, I’m still in proof of concept stage, I reused code for another project:  python, HTTP with one TCP connection by message, messages are text json… Still a lot improvement here before to start to tune the network communication :) 

I see your robot is arduino based… and you did have latency issue… I was also thinking to shortcut the Raspberry Pi for direct control (like you) and connect with bluetooth directly to the Arduino Engin Controller, and get an “autonomous” mode control by the raspberry with WIFI connection for the IP Cam and high level command to the RPI.

Anyway I will look at you code, for bluetooth communication, when I resum this project.

7

Most of the lag was in the

Most of the lag was in the bluetooth controller, UDP for streaming images and TCP-like bluetooth to send commands. For image streaming i used a free app IP camera server and used a modified bluetooth chat example for commands. Bluetooth uses a best effort approach, so messages arrived missing letters, duplicated, not synchronized and corrupted most of the time. So i solved it by sending very short messages (like “a9” instead of “go forward at full speed”) with at least 100ms delay, not listening to messages if already doing an action, action last at most 80ms and autonomous crash protection. Arduino tells back via bluetooth which action is doing only after it has recognized a valid command.

 

8

Any further progress?

I am curious as to any further developments with your Havey.