By next competition, we hope to have a more accurate way of measuring the distance that Monty has traveled. This past competition, the only distance measurements we relied upon were those made by GPS; Although the calculations proved reliable to a certain extent, there is a lot of room for improvement. In order to increase both our accuracy and precision in determining where we are, we will be using a weighted average of GPS data and data from an encoder. Our weighted average algorithm is devilishly simple, but we needed to find the standard deviation of our GPS. On Sunday we sat Monty down and took 1,000 GPS points of the same spot, imported those points into Microsoft Excel, and took a look at the data.

Our findings were, to be honest, quite cool! First off, the standard deviation of both our latitude and longitude was .0579 meters, which means 95% of all of our GPS readings falls in a circle with a diameter of 11.5894964. That is insanely accurate! Of course, we had outliers on both ends of the data set and our range turned out to be 6.4 meters, but the incredible accuracy was pretty true to form for GPS.

Additionally, we took a look at the data in graphical form. The first graph we saw was a simple graph of Latitude vs Longitude. We predicted that this graph would have a bunch of data in roughly a circle in the center, with a few sporadic outliers dotted around the page. Much to our surprise, the bizarre output of Lat Vs Lon was very un-circle like, and had no mathematical shape that we know of (although it does produce a striking image of a roosted eagle).

 

The second two graphs we made helped us understand the output of the first graph a little better. We separately graphed Latitude and Longitude vs Time and once again our predictions were wrong. We expected another random dispersion of points along a best fit line, but instead we were greeted with two graphs that showed random downward and upward trends of points. We inferred that the rise and fall of the Latitude and Longitude were due to Satellite error or movement because the trends continue for a good time before switching direction. The line graph showed that the GPS doesn’t produce random points, but instead produces points that continue to increase (or decrease) in error IN THE SAME DIRECTION for a brief period of time.

 

Yesterday’s post-competition “death run”…

 

 

MontyRoboMagellan is scored by how long it takes a robot to get from the start to the final target cone, the faster the better. Times can be reduced by touching bonus cones, so the key decision is getting the best balance between the extra time it takes to get to bonus cones versus the reduction in time getting to those cones gives you.

Having had our first run end when Monty decided to drive into a trash can looking for a bonus cone, we decided our second run would be a straight shot at the goal. Everything went perfectly and we came in at 1 minute and 27 seconds: enough to comfortably take second place.

How comfortably? Third place came in at 14 minutes dead, and no other team completed the course in any of their three attempts. The winning team hit two bonus cones and came in with an adjusted time on 15 seconds. Very impressive: but these guys were professionals from a robotics company! Monty and the PVIT team beat out the rest of the field handily. Not bad for the only high school team in the competition. Not bad for a team whose robot couldn’t move an inch on the course eighteen hours earlier!

Epilog: after the official rounds we decided to go for a flat-out, max speed, pedal-to-the-metal, potentially self-destructive “death run”. Monty performed perfectly despite nearly flipping over his front wheels under severe braking, turning in an unofficial time of 41 seconds. And, amazingly, no damage.

 

The saga continues…

Midnight test runs at Taco Bell (because Taco Bell has grass outside, of course), re-writing motor controller code over breakfast, setting up base camp at the Event Center… and Monty lives!

Better still, Monty works, running smoothly through the meadow that passes for lawn. And we only used about 22 inches of duct tape. Win.

 

After many successful runs back at base, we’re here in San Mateo at Robogames. So of course Monty isn’t working. Well he is: on tarmac. The course however seems to be on grass that hasn’t seen a mower in weeks. The motors stall trying to push through the grass and the motor controllers are shutting off to avoid burning out.

Basically we can’t move at all. In engineering circles this is called a problem. We can’t start on grass. We can’t start on tarmac and drive onto the grass. Both approaches just stop the motors dead.

So, while we expected to spend a Saturday night sampling the delights of downtown San Mateo, we’re holed up in a motel room, replacing the motors, drive gearing, and motor controller software. Only tomorrow will tell how well this will work, but we’re not done yet.

 

…and we have video evidence to prove it!

 

In Robomagellan, we joke that our successes and failures are defined by Freddie Mercury moments or Picard face palm moments. A Picard moment would be like saying “Why aren’t we getting camera data?” and then 5 minutes later realizing the camera is unplugged. A rare Freddie moment occurs after a moment of monumental success, such as Monty (Our robot) making about 8 run-throughs of a simple GPS course in almost exactly the same way. Today was definitely a Freddie Mercury filled day, with many breakthroughs and many successful moments. The Robomagellan team met for 6 hours, and although we are very close to the competition date and are working under pressure we still have time to enjoy what we are doing! A good mix of Picard moments and Freddie moments really makes finishing a project an feel like a true accomplishment.

 

 

 

 

 

 

Today we spent the majority of our time either outside on the blacktop running Monty or working through the steering algorithms.

At first, Monty seemed to sporadically turn with no direction in mind. After searching through the code we found that our calculations of the steering angle was off by a few thousand degrees… Using a crazy little thing called

bug testing, we fixed our calculations (after a few face palm moments) and sent our death on four wheels off on a GPS adventure. Monty’s steering behavior improved, but he was still not breaking free and finding any GPS points. Monty was turning too much and made it impossible to controllably steer towards a point. To fix this, we divided the steering angle by five, thus reducing the sharpness of the turns. The subsequent run was full of slow turns and giant circles but Monty found a GPS point!

Monty started slowing down at this point and although he seemed to scream “Don’t stop me now” we replaced his batteries, upped the speed and then retried the course. It was at this point that we realized full batteries make a robots world go fast; Monty completed the fastest run yet at 1:02 seconds, but made a few harrowing turns at high speeds.

This definitely was an incredibly productive day (and we felt that another challenge bit the dust) but we still have a lot ahead of us. Monty still is flying blind with no sonar or camera code tested yet and his bohemian affinity for poles and other dangerous objects (such as buildings, walls, people, bicycle races, etc) poses a threat to long term survivability. Tomorrow we plan on working on the camera, sonars, obstacle avoidance, and general usability; Currently it takes us a few minutes to set up Monty and get him started, but we need to be able to be able to start in a few seconds to maximize run time come competition. In the event that we cannot overcome our difficulties, some dynamite with laser beams will be enough to defeat our competition.

 

The West Basin Logo Design on Canoe

The long months have gone by without much visible progress; however, rapid headway is undergoing. During the important WASC weekend, PVIT and some members of the Team applied Epoxy onto the canoe, despite the heavy hurricane-like storm. The new paint job and the colors on the boat shine brightly. The PSA (Public Service Announcement) was filmed on the rocky PV beaches (near the cliffs). The West Basin Municipal Water District Logo on the side of the canoe clearly depict the water-themed project,  but furthermore, the rising sun shows the importance of solar energy in today’s society. The Solar Cup encompases the major environmental topics of water conservation and renewable energy, for example solar energy. More importantly, the half ocean, half sun details in the caliber of both. The world cannot get better without the combined efforts of conserving water and utilizing solar energy.

 

As May gets closer, the Team works harder to make the empty hull into a solar-infused masterpiece. The Public Service Announcement (PSA) script, which has been submitted, went for evaluation came back with some critical feedback by the water district. Due April 10th, only a few more weeks away, the PSA still needs to undergo filming and production, which can be accomplished by using Live From 205’s equipment. Current PSA leader, Patrick Glenwright wrote the script and is preparing to start filming. The PSA represents a large portion of our grade of the overall project. Also, about 2800 dollars was spent in buying the different components necessary for the boat. This leaves the Team 1200 dollars that can be used universally such as for this or next year’s Solar Cup competition. The left over of the cash can be beneficial in both situations. There is much work to be done, but the Sea King painted on the side of the boat guarantees success.

 

This year we decided to do most of our RoboMagellan programming in Python on the grounds that programmer productivity is a bigger issue than program performance given what we’re doing.
An interesting side effect of this, and one we didn’t really anticipate, is that doing things this way has made our robot construction better. Last year we used Arduinos exclusively which meant that we needed the robot to test the software during development. This lead to temporary construction decisions (“let’s just zip-tie the board here for now so we can test”) becoming more or less permanent (“let’s leave it, we know it works”).
With Python it’s much easier to develop and test the code without going near the physical device. This has given us the time to pay more attention to the quality of the hardware build. That build is nearly done. The software is nearly done. It will come together in the next couple of weeks and we’ll be moving into the test phase.

© 2012 Palos Verdes Institute of Technology Suffusion theme by Sayontan Sinha