The aim of the project is to build an autonomous outdoor robot platform, which can be used as a basis for the robot which can participate at the outdoor robots contests like Robotour.
The project includes:
the hardware part (creating of the skeleton of the robot, which can hold the equipment)
electricity part (the motors, power supply, communication between components …)
software part (the brain of the robot, localisation, odometry, …).
Goals of the Project
We want to participate in the Robotour 2010 contest with the robot as a proof of concept. [Done]
Continue development of the robot, be prepared for Robotem Rovně 2011 (implement missing features, improve stability, maneuvrability and mileage).
Explore possibilities of Brmbot Outdoor in other contests, even indoor just like Eurobot
We have well-working chassis with control software, currently developing pathfinding software.
We have reached place 11/16 at the Robotour 2010 competition on Sep 18 in Bratislava.
We lost big time in RoRo2011, as we had no working pathfinding.
: GPS, path calculation, main programmer
: chassis, webcam pathfinding.
Originally used chassis from Heng Long's KV-1 1:16 battletank, now widened to have approx. square groud-contact area. It has thank threads with approx. 30cm long ground contact area, and is driven by two crappy speed-400 sized motors, one nearly three times as strong as other.
TODO: Get bigger, stronger, higher quality motors with comparable torque.
Chassis is driven by arduino with custom motor driver (two full H-bridges). In addition to driving motors it takes care of emergency stop button (Big red button), optical system to measure number of driving wheel rotations on both sides (odometry), proximity sensors (currently IR sensors that give lots of false positives in sunlight).
Arduino listens on USBserial console, sketch for former V1 driver is available at http://web.natur.cuni.cz/~ax/brm/brmdriver.pde.html. Current sketch uses new protocol. Commands available in V1 driver (left side always goes first):
full stop. Response is OK, ON FIRE when big red button has been pressed or HALTED when we were standing due to obstacle anyway.
read odometry. Response is int,int which is number of odometer pulses, left side first. Negative when driving backwards.
Limits next drive command to xxxx odometer pulses. 100 pulses is about 80 cm.
Like Fxxxx, but doesnt stop when sensors say. Use with caution.
Drive forward/rearward with speed 0..9 (0 is stop), left track first. For example DF9F9 will go full speed forward, DF9R9 will make superspin and DF0F0 is equvalent for S. Response is OK, ON FIRE when big red button has been pressed or HALTED when we are currently still due to obstacle.
Clear the big red button status.
Read proximity sensors. Returns int,int where values over 300 mean “we are very close to obstacle”.
retun state of many internal values (pwm values, odometry, sensors, uptime and so on)
When driving straight, chassis will check its odometry and will try to compensate for uneven terrain resistance on tracks so DF9F9 isnt full speed on both tracks but full speed straight forward.
Chassis will slow down when it detects nearly obstacle (around 20 cm). After it detects close obstacle it stops and reports “Proximity: int, int” to the console (when one of IR sensors reads value over 350).
Mechanical sensors cannot be used, because contact with any obstacle is fatal.
Selected sensor status (by September 7, 2010)
GPS - basic functionality
camera - (assembled) calibration
odometry - functional sensors
obstacle detection - done but there is lots of room for improvement.
Big Red Button - done.
Software and GPS
Get current version from:
loads OSM data (stream parser - SAX API
visualises loaded area with correct lat:lon aspect ratio (calculates local aspect ratio after loading map)
provides screen to map translation and vice versa
finds nearest way and segment and point on segment for given point using correct scale
determining optimal path between two points - nodes, distances, azimuths
uses real metric distances as edge cost
displaying detailed path plan
reading GPS data from receiver
adjusting the path during movement
Camera part consists od Logitech Webcam C200 and kitchen ladle, which functions as panoramatic mirror, currently on heavy wooden frame.
Geometry calibration surface
One of geometry calibration images
Resulting calibration function (if the picture is transformed to 480*480 or the formula is transformed)
Testing…needs to be tweaked (see below map 8.6×8.6m).
Version 1.0 - not perferct, but much better (area 4x4m):
Frames form the real robot configuration from the test ride (robot goes to the left):
A very naive image processing using this camera (mounted on a smaller robot) is described: http://log.or.cz/?p=133