Brmbot Outdoor

Brmbot Outdoor
ASCII
founder: tutchek
depends on:
interested: pasky
czestmyr
joe
TMA
Archimedes
axtheb
software license:
hardware license:
status: design

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

Status

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.

Member subgoals/tasks

  • TMA, Tutchek: ideas fountain
  • Joe: GPS, path calculation, main programmer
  • Archimedes: webcam construction, calibration
  • AxTheB: chassis, webcam pathfinding.

Chassis

Chassis base

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.

Controller

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

Controller software

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

S full stop. Response is OK, ON FIRE when big red button has been pressed or HALTED when we were standing due to obstacle anyway.

O read odometry. Response is int,int which is number of odometer pulses, left side first. Negative when driving backwards.

Fxxxx Limits next drive command to xxxx odometer pulses. 100 pulses is about 80 cm.

Gxxxx Like Fxxxx, but doesnt stop when sensors say. Use with caution.

D[FR][0..9][FR][0..9] Drive forward/rearward with speed 0..9 (0 is stop), left track first. For example DF9F9 will go full speed[1] forward, DF9R9 will make superspin[2] 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.

N Clear the big red button status.

P Read proximity sensors. Returns int,int where values over 300 mean “we are very close to obstacle”.

W retun state of many internal values (pwm values, odometry, sensors, uptime and so on)

R returns “ready”

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

Sensors

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: http://repo.joe.cz/brmbot.

Requirements:

  • ruby1.8
  • libgtk-ruby
  • librexml-ruby
  • gpsd and gpsd-compatible GPS receiver (if you want to use live GPS tracking)

Features:

  •  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
  • reasonable logging
  • reading GPS data from receiver
  • adjusting the path during movement

Missing:

  • reading compass data
  • controlling robot movement
  • extensive logging

Camera

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)

r_pix=141*atan(1.19*r_map)

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

Image processing

We use simple pixel-difference based system, working in c1c2c3/o1o2 colorspace as in http://portal.acm.org/citation.cfm?id=1782951 on part of untransformed image from webcam. Source is available at GitHub.

References

 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki