Crashing into a cone:
This video demonstrates the robot tracking an orange cone using a video camera. This is accomplished using roborealm to process the video, and having roborealm communicate with python through an API server. The robot will attempt to crash its right wheel into the cone, and stop once it arrives. The code is in the infant stages, but it will consistently hit the cone, even if it doesn't turn the motors off after it does it.
-B
Friday, February 25, 2011
Thursday, February 24, 2011
Success!!!
Today we finished getting the new suspension attached to the chassis and got the steering aligned. It goes perfectly straight for about 20 meters and then starts to drift a little, but besides a full steering system overhaul, there's not much we can do about it. Tweaking the alignment simply involves adjusting the length of tie rods from the servo to the steering column. I found that one full turn of the adjustment results in roughly 1 degree of change on the wheels alignment
The newly installed suspension works great! The old shocks are still going to need pre-compression, however. We can continue to do it with zip-ties or buy some real clips.
On a different note, I rewrote the gps program to do the mapping with just the encoders and compass. As long as the encoders work as Mitch intended, it should be a very accurate way of keeping track of position. The robot_pos coordinates are no longer in pixels but in meters. This should make things easier in the future. Also, the robot coordinates don't rely on any image updating or processing. The program starts by waiting for a mouseclick on the map and then sets the initial robot position to that spot (This will be replaced by GPS coordinates later). It then requests an input distance and heading, and generates a destination coordinate based on these inputs. It should be a cinch to add on motor controls at this point.
The newly installed suspension works great! The old shocks are still going to need pre-compression, however. We can continue to do it with zip-ties or buy some real clips.
On a different note, I rewrote the gps program to do the mapping with just the encoders and compass. As long as the encoders work as Mitch intended, it should be a very accurate way of keeping track of position. The robot_pos coordinates are no longer in pixels but in meters. This should make things easier in the future. Also, the robot coordinates don't rely on any image updating or processing. The program starts by waiting for a mouseclick on the map and then sets the initial robot position to that spot (This will be replaced by GPS coordinates later). It then requests an input distance and heading, and generates a destination coordinate based on these inputs. It should be a cinch to add on motor controls at this point.
Tuesday, February 22, 2011
Battery life: stress test
The above graph represents the voltage of the motor battery vs. time.
Conditions:
chassis suspended so the wheels do not touch the ground
motor power set to 150 units greater than stop condition
allowed to run without external torque on wheels
A natural exponent function very nearly represents the data, and establishes a horizontal asymptote at 11.26 volts.
It is reasonable to assume that the battery should never be allowed to approach that voltage, as it may refuse to take a charge afterward.
20 minutes of navigation seems to be the limit for safe operation.
-B
Project Meeting - Feb 17th
On Thursday the 17th of February there was a project meeting to discuss remaining tasks.
The result is the following task list.
-Test the run time for a fully charged battery
-Develop graphs and charts to explain the scientific content of the platform
-Test the efficiency of of numerous way points vs. sparse way points
-Test the accuracy and efficiency of traveling via a heading and distance scheme vs. a GPS and pixel scale scheme
-Check the behavior of the platform with constant compass update vs. periodic compass update.
Each of these tasks can be approached scientifically, so the next few weeks will involve gathering this data.
-Brian
The result is the following task list.
-Test the run time for a fully charged battery
-Develop graphs and charts to explain the scientific content of the platform
-Test the efficiency of of numerous way points vs. sparse way points
-Test the accuracy and efficiency of traveling via a heading and distance scheme vs. a GPS and pixel scale scheme
-Check the behavior of the platform with constant compass update vs. periodic compass update.
Each of these tasks can be approached scientifically, so the next few weeks will involve gathering this data.
-Brian
Wednesday, February 9, 2011
Monday, February 7, 2011
Front Encoders Mounted and Tested
Today I completed the fourth encoder and mounted encoders 2-4 on the front wheels. Next I created a power rail for the encoders and connected them to the Arduino. After testing each encoder to ensure it was working properly, I tested the accuracy of encoders under motion. I noticed some variation between encoders, but even after 20+ meters the difference was minimal unless one of the encoders stopped on the borderline of a segment then it would trigger on/off repeatedly until moved again. I believe this error is due to the relative size of the segments in comparison to the actual encoders and I feel that a form of averaging could be utilized to compensate for the error programmatically.
TO DO
Now that these encoders are done, I will focus on establishing more robust code to handle both front and rear encoders. While I am waiting for the new encoders to arrive, I will split my focus between refactoring my code and setting up the Sharp Long Range IR Sensors.
Video
Up periscope
Here is the new look for the robomagellan platform:
The shell has had a couple of modifications: First, the magnet sensor has been moved up several inches. Andy claims that the proximity to the laptop caused magnetic interferance, so he attached a board to the sensor and gave the platform a central periscope. I felt that the sensor was too exposed, and returned it to its project box, but utilized the wooden board to raise the whole box up into the air.
The kill switch has been giving us trouble... read Andy's previous post for more info on that. So I thought the best solution was to extend the receiving antenna with some extra wire. I wrapped a double wire around the exterior of a carbon composite tube to create a helical antenna.
The range on the kill switch appears to be greater, but we will have to test it in the field to be sure.
The shell has had a couple of modifications: First, the magnet sensor has been moved up several inches. Andy claims that the proximity to the laptop caused magnetic interferance, so he attached a board to the sensor and gave the platform a central periscope. I felt that the sensor was too exposed, and returned it to its project box, but utilized the wooden board to raise the whole box up into the air.
The kill switch has been giving us trouble... read Andy's previous post for more info on that. So I thought the best solution was to extend the receiving antenna with some extra wire. I wrapped a double wire around the exterior of a carbon composite tube to create a helical antenna.The range on the kill switch appears to be greater, but we will have to test it in the field to be sure.
Subscribe to:
Posts (Atom)