XRB3 is powered by an AVR ATMEGA324P micro controller on a custom board that I made. Although he is fully autonomous, he is using an XBEE module to communicate with my PC for debugging (and eventually with other robots). Onboard sensory includes: 3 Sharp IR sensors (for wall following and obstacle detection), an SRF-05 sonar sensor and AVRcam. The sonar, a gp2d12, and the camera are mounted in a 2-axis head. He also has quadrature encoders on each wheel, I currently have code implemented for closed loop turns and rolling forward a set distance, but have yet to do continuous speed control.
This is intended to be my map-making test platform. He currently does have an onboard planner that, when given an a priori topological map of an area, can navigate the area. I'm still working out the bugs in his ability to actually build the topological map of an area.
Good to see a design that starts out with a clear idea of the concept: topological mapping (rather than geographical mapping). I like that. Also cool design to look at!
The AVRcam is probably the hardest sensor to use out there. It uses a well-defined serial interface, so it isn’t terribly hard to get that working, however, it gives off so much data that it has a tendancy to overwhelm the robot’s main processor.
The biggest problem, with any camera - not just the avrcam, is that you have to set your colors for the environment you are in. The brightness of the room affects the way things look to a camera, no camera out there has the same compensation build in as we humans do.
The biggest reason for a topological map was that a) an AVR has limited memory, so a metric map would be pretty small, and b) searching through a topological map for a new area of interest is far easier.The robot’s topological mapping was pretty good, in a limited world.
However, I have been working on an extended model that basically builds a local (6’x6’) metric map of the world. The metric map is updated over time as the robot moves and older data “falls off the face of the earth” as the robot moves away from that area. The metric map is then used to extract more relevant points of interest to add to the topological map. The system also adds a small amount of metric data to the topological map, in the form of the approximate distance between nodes on the map. This limited-metrics is primarily for the problem of loop closure (is this a new node, or have I been here before?).
I’m also slowly working to get the robot off the grid, as the current method only uses orthagonal maps.
Onboard and offboard So many things put together on this, really incredible! How was Python to develop in, what sort of experience did you have before and during development with it? Really great looking bot!
Python was only used for the system console, which is a small program that allows the PC to connect to the Xbee network and view the output of the robot (and also start or stop particular behaviors/programs). Python is a great language, because it is fairly simple and has many libraries - such as pySerial, which was used to connect to the Xbee over the USB serial port. The python program is only 205 lines of code. Had I written the code in Java, that serial port interface alone would have occupied about 200 lines of code (in fact, an earlier version was coded in Java, and was about 700 lines of code to create even less functionality).
