Hey guys,

I have been wanting to fully document my SAGAR (Semi Autonomous GPS Assisted Rover) for some time now, and the 'ardupilot goes into the water' series has been so entertaining, it gave me the motivation to finally start. The first post was simply a demonstration of the LabView ground station, which has been redesigned one last time before my girlfriend is turning in the project. First I'll show the new interface, and talk about how it communicates with SAGAR, and give some background on why I built SAGAR.

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




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.


To finish off this oddly ordered intro, I 'll give my motivation for building SAGAR to begin with, starting with a quick life story.


To most of the locals around here, I am a young gun. This time last year, I was nearing the end of my college career. All my life I knew I wanted to be an electrical engineer, but I never really knew what branch I wanted to specialize in. The family business was generators, so I took as many power classes I could sign up for. It was ok, but I wasn't a fan of all the extra math involved as opposed to other fields of EE. My last year of school, I had to build a senior design robot as defined by the IEEE 2009 SouthEastCon Hardware Competition. I had a blast. I instantly realized the field I wanted to be in was robotics. The robot my group built did so well, if it had gone to the competition (long story of why it didn't) it would have crushed the competition as during every test run it easily doubles the score of the robot that did win. Here it is:





I am very proud of how well it works. After graduation, A division of the U.S. Navy that specializes in unmanned robotics got a hold of this video and asked for my resume. Now I work with million dollar underwater, surface and ground drones; ie my dream job. The only problem is I don't have much experience building robots that are not made of Legos, or the only purpose is to pick up recyclables. So the month I started working, I started building SAGAR to gain the experience I wanted of the internals of unmanned drones. 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.

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

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Thanks Harald!

    It was worse, but my girlfriend edited for me! The can-collector could fit anything close to the size of a coke can/bottle.

    It's actually all custom built, except the main MCU and prime movers are the guts of an IRobot Create. I even built my own battery packs out of a box of Li-ion cells that where given to me for free. (The same packs are in SAGAR now).
  • congrats Bill, very nice Job!
    keep on posting,!

    I love this can-collecting robot that looks like the intestines of a mutated and skinned laser printer :-)

    Do you think it also can collect beer cans?
    There would be a great market in the couch-potato scene!

    Dont worry about your spelling or grammar. Most engineers are bad writers and most writers are bad engineers.
    The guys that can do both are very rare on this planet and i think you are one of them.
  • Admin
    cool, hey don't keep us waiting for next installment :))
This reply was deleted.