This past week I have started the work to untether my car from the workbench (power supply and breadboards). I started by moving the motor and servo controllers to perfboards and soldering them in place, taking them off the breadboard. I also started implementing the GPS localization algorithms and experimented with KML and generating maps.
Perfboard
The perfboard allows me to seperate the inputs from the outputs and maybe even use ribbon cable to link the various pins on the Beaglebone rather than have a rats nest of individual hookup wires going from pin to pin.
I tried this a few weeks ago but unfortunately I purchased perfboards without copper cladding. It turns out that these boards are designed for wirewrapping techniques and other circuit designs. Since most of the main components that I am using are integrated circuits (IC’s) and sensors, I needed the copper clad boards. The copper wells allow the solder to firmly attach the board and the components together and establish a solid electrical connection. Connections between leads are made by bridging gaps with copious amounts of solder.
Since the perfboard I was using didn’t have power strips built in, I had to make strips to deliver power to the components. I have more than one part that needs power so I couldn’t just wire the power and ground pins point to point. Instead, I stripped a short section of wire and used it to connect a trail for 5v, GND and 3v3 of 4 wells each. This allows the power to be delivered to multiple users and still have reasonable wire management.
GPS ROS Node
To start testing the GPS functionality of my robot, and to see the readings more tangibly, I started recording locations in KML format and opening them in Google Earth. My ROS node simply recorded the average of a certain number of readings as well as the individual readings themselves and saved them in a KML file that Google Earth could read.
Prior to this I hadn’t actually used my GPS in a while and after hunting around
online and in my notes for a couple hours I finally got it working again with
my Beaglebone running Ubuntu 13.04. I think there should be a better way to do
it but for now I have to export the UART pin I plan on using to the cape
manager’s slots file before starting the GPS.
Normally the UART pins should register as /dev/ttyO1 through /dev/ttyO5. For
me, I didn’t have anything except /dev/ttyO0. Thankfully I found a post
on the BeagleBoard Google Groups page that pointed out how to enable UART.
(For me it was BB-UART1 since those are the pins I’m using).
echo BB-UART2 > /sys/devices/bone_capemgr.????/slots
To handle the nitty-gritty details of UART communication and NMEA parsing, I
used the ROS Node nmea_navsat_driver. I had previously
setup my system with the intention of using gpsd to parse the data but that
didn’t work well with ROS. The nmea_navsat_driver works very similarly to gpsd,
reading and parsing NMEA sentences from a serial port, but instead publishes
the parsed readings to ROS topics.
Currently I am starting the node with
rosrun nmea_navsat_driver nmea_serial_driver _port:=/dev/ttyO1 _baud:=9600
but I plan on integrating this in a more automated way later…
My gps-average node subscribed to the topic (fix) and used simplekml to write the KML files.
I plan on using the simplekml library in the future to log the percieved location of the car and also debug any autonomous navigation and driving code I test. Being able to see the GPS coordinates on a satellite map is extremely helpful and useful in visualizing the data and seeing any noise or bias in the GPS readings.
Big thanks to Jim Allard for giving me pointers on the navigation and localization portion of my project