SAGAR System Overview, Part 1

Posted in Projects, Tutorials by Bill
20 Apr 2010

My SAGAR project has gotten to a point where I would like to document the system design through a series of detailed posts.

First I’ll show the new interface, and talk about how it communicates with SAGAR.

Here is a video of the new interface, with an inset of SAGAR as it runs the mission.

NMCI friendly:
[flv]http://www.billporter.info/wp-content/uploads//2010/04/SAGAR.mp4[/flv]

YouTube:

During the run we recorded, there was a glitch half way through. It appears Labview started to slow down and the gap between live events and what was being displayed grew, until the Labview buffer overflowed and sentences where lost. I have yet to look into that problem, as it is the first time we have observed it.

When my girlfriend came to me for ideas for her LabView class, I suggested she write an interface for my robot. I knew I would have to develop a communication protocol that I could hand to her from the start. I took a look at the structure of the ArduPilot communications, and it seemed odd to me. Is the structure a known protocol? I’m sure one of the developers will tell me.

I decided to stick to something I knew, the NMEA protocol. For those who are not aware, GPS systems communicate via the NMEA protocol, as do many other robotics systems. The structure of a NMEA sentences starts with a header that identifies the sentence, then comma delimited fields that contain the data to be passed. The sentence is usually followed by a checksum, to validate the integrity of the data. I came up with my own header, and added the fields of sensor data I wanted to have displayed on the interface. Here is an example of my structure.

$SAGAR,heading,pitch,roll,wheelspeed(Commanded l+r, actual l+r),

distance_trav,GPS_Fix,GPS_Lat,GPA_lon,GPS_speed,GPS_COG,

Battery_V,Battery_I,processor_load*CS

This is one of two sentences SAGAR will send to the interface. The other sentence contains mission statistics like current waypoint number, distance to waypoint, etc. There are also 4 sentences that the interface sends to SAGAR, each representing a different mode for SAGAR to enter, and commands to follow. There is a fail-safe in place, if SAGAR doesn’t receive a command sentence in 500ms, it halts and enters stand-by.

SAGAR started as a bag of parts nearly a year ago, and grew from there. (Almost) everything is from scratch, down to DIY battery packs.

Not too shabby? Forgive and spelling/grammar, I am definitely bad at both.

Coming up next: The importance of a good chassis, and building my own closed loop motor controller.

Share