Home
Welcome to the GPS-Guided-Rover wiki!
The following is the contents of my notebook kept diligently throughout the project.
<title>Rover Engineering Notebook: Andrew Milich</title><style type="text/css">ol{margin:0;padding:0}.c5{max-width:468pt;background-color:#ffffff;padding:72pt 72pt 72pt 72pt}.c2{color:#1155cc;text-decoration:underline}.c0{height:11pt;direction:ltr}.c3{color:inherit;text-decoration:inherit}.c4{text-decoration:underline}.c1{direction:ltr}.title{padding-top:24pt;line-height:1.15;text-align:left;color:#000000;font-size:36pt;font-family:"Arial";font-weight:bold;padding-bottom:6pt}.subtitle{padding-top:18pt;line-height:1.15;text-align:left;color:#666666;font-style:italic;font-size:24pt;font-family:"Georgia";padding-bottom:4pt}li{color:#000000;font-size:11pt;font-family:"Arial"}p{color:#000000;font-size:11pt;margin:0;font-family:"Arial"}h1{padding-top:24pt;line-height:1.15;text-align:left;color:#000000;font-size:18pt;font-family:"Arial";font-weight:bold;padding-bottom:6pt}h2{padding-top:18pt;line-height:1.15;text-align:left;color:#000000;font-size:14pt;font-family:"Arial";font-weight:bold;padding-bottom:4pt}h3{padding-top:14pt;line-height:1.15;text-align:left;color:#666666;font-size:12pt;font-family:"Arial";font-weight:bold;padding-bottom:4pt}h4{padding-top:12pt;line-height:1.15;text-align:left;color:#666666;font-style:italic;font-size:11pt;font-family:"Arial";padding-bottom:2pt}h5{padding-top:11pt;line-height:1.15;text-align:left;color:#666666;font-size:10pt;font-family:"Arial";font-weight:bold;padding-bottom:2pt}h6{padding-top:10pt;line-height:1.15;text-align:left;color:#666666;font-style:italic;font-size:10pt;font-family:"Arial";padding-bottom:2pt}</style>Andrew M.
July 2012
Project Description:
A small rover is designed to drive directly to a GPS waypoint. Critical to the project, a small GPS unit is mounted on the rover’s surface. Location data is converted to a usable form and a path calculated. The car makes an estimate of how far to turn, then re-calibrates its location. This process continues until the car has reached its destination.
The project utilizes the haversine formula to calculate the distance between two latitude and longitude points. Using the heading determined by the GPS proved highly inaccurate; I chose to mount a compass module to the car, reducing the need to constantly re-calibrate to correctly estimate the car’s heading.
Motors and Driver:
Motors: http://www.pololu.com/catalog/product/1103
Two 37D metal gear motors were used in the project. The motor driver can easily power the motors despite the motors’ high stall current. The motors were purchased without encoders as they are unnecessary for the project; all location and distance data is supplied by the GPS.
Driver: http://www.pololu.com/catalog/product/2503
Pololu suggests soldering a jumper to the board to supply power to the arduino and motor controller from the same sources; instead, I connected a single wire from the VIN screw terminal to the VIN pin on the shield. This allows the arduino to regulate power and retains the voltage protection circuits on the shield.
Compass module: http://www.sparkfun.com/products/7915
Notes:
July 15th, 2012:
Achievements: An arduino program to successfully generate a path from one latitude and longitude to another has been completed. It interprets the incoming serial data and calculates the distance using the Haversine formula (http://www.movable-type.co.uk/scripts/latlong.html). Using the vertical (latitude) and horizontal (longitude) distances, the arduino essentially constructs a right triangle. The ratio of latitude to longitude is the tangent of the necessary angle, allowing the device to calculate a precise heading to turn to.
July 18th, 2012:
Achievements: The preliminary programming has been completed for both the rover and processing sketches. The processing sketch utilizes two the library modestmaps to display google maps data; the guicomponents library is also extensively used.
Issues: Proper interpretation of the serial data was a particular challenge. The arduino programming environment does not contain a simple way to split strings. Furthermore, decimal points proved another hurdle for the arduino to interpret.
Fixes: The microcontroller searches for parentheses and spaces, automatically ignoring them. As new characters of serial data are sent, they are added to a string (latitude). If one of these characters is a comma or indicates a newline, it moves to another string (longitude).
July 19th, 2012:
Achievements: The GPS unit was successfully tested, and its data is now converted from DMS (degrees, minutes, seconds) into the more usable decimal format.
Issues: Converting the GPS data seemed a simple task using this formula (http://andrew.hedges.name/experiments/convert_lat_long/). Problems arose concerning the data types the arduino uses and, after completing a fairly math heavy, complicated formula to convert data, I posted my situation on the adafruit forum and was given assistance (http://forums.adafruit.com/viewtopic.php?f=25&t=30776).
Fixes: The new program does not differentiate between minutes, seconds, and milliseconds: instead, it uses minutes, tenths, and hundredths of a minute in a single multiplication.
July 20th, 2012:
Achievements: The polycarbonate sheet was prepared to use with the motors and arduino. The arduino, GPS, and motor mounts were successfully screwed onto the surface.
Issues: Accuracy is paramount when creating any hole in the polycarb; careful planning was necessary. Another principal problem arose upon my discovery that screws were not included with many of the necessary parts. Luckily, I found appropriate screws and nuts.
Fixes: The battery was ultimately mounted on the underside of the polycarb.
July 21-22nd, 2012:
Achievements: Hours of testing were completed, the driving and GPS programs were wholly redone.
Issues: The GPS often supplies inaccurate heading data. Although the rover frequently reached the target, it rarely navigated the most direct path. The front wheels also demonstrated difficulties when turning.
Fixes: A magnetometer may be necessary to provide accurate direction data. I am also considering using a ball caster wheel to provide smoother turns.
July 23rd, 2012:
Achievements: An omni wheel was mounted on the front of the robot, making turns far easier.
Issues: After experiencing numerous issues when uploading programs, I discovered that a screw mounting the arduino to the acrylic sheet was causing problems. The TX and RX lights no longer flash but programs still upload.
Fixes: I removed the damaging screw from the board. The wheel hubs would fall off continually as the small black screws inside them would break. To combat this, I used full size screws to mount them to the motors.
July 24th, 2012:
Accomplishments: More acrylic was mounted between the forward and rear portions of the rover, strengthening the connection between the front omni-wheel and the rear. A sketchup file was created with three boxes to contain the various parts of the project; the boxes will be 3d printed.
Issues: The battery cord would not stay attached to the bottom of the rover; the battery itself was not strongly attached to the vehicle.
FIxes: The battery mount required further screws, and a small acrylic rectangle was mounted to the bottom of the rover to secure the battery cord.