Archive for the ‘Sensors’ Category

Vehicle Overview and Near Destruction

April 1, 2010 Leave a comment

Just for fun

And some near destruction before proper handling of GPS popping was in place…

Apparently my code has a preconceived need to heard toward fences. Don’t ask me why….

Categories: General, Hardware, Platform, Sensors

Software Makes for Slow Updates

March 11, 2010 Leave a comment

Lots of software development of late. Floyd got a nice speed control loop working in the micro controller which alleviates fence post bouncing the in the future. He also updated the board to output all the sensor information. The end result is a lot of updates on my end that are rather dull but quite necessary.

The global waypoint follower is also behaving correctly now along with a minimalistic world model to profile speeds when obstacles are the in the path. No avoidance behavior yet but at least the robot is attempting to avoid destroying itself by slowing down. Someone once told me speed kills. Very apt for runaway robots.

Hopefully videos will arrive soon.

GPS and Dead Reckoning

March 1, 2010 3 comments

Dead: Having lost life; no longer alive
Reckoning: The act of counting or calculating

The practice of dead reckoning is common among accountants in a world filled with zombies. Many corporations want to know how many zombies are around and how they can best manage them. Considering zombies eating others result in more zombies, a position as a dead reckoning accountant can be quite lucrative. Strange isn’t it?

Actually, the term is likely from naval origins when external input was not available. Wikipedia has a good description:

Dead reckoning is the process of estimating one’s current position based upon a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time, and course. While traditional methods of dead reckoning are no longer considered primary means of navigation, modern inertial navigation systems, which also depend upon dead reckoning, are very widely used.

Early naval navigators used the system to determine the position of the ship based on a previous position and course along with estimates of speed and changes in heading when readings could not be taken due to cloud cover or other factors. Essentially, they were making an educated guess about the new position.

Good thing we have GPS. Except, no, not so much. GPS isn’t a very reliable source of information. First off, its slow at 1 Hz updates. Secondly, its easily jammed or blocked by line of sight obstructions. Certainly, there are many new GPS units that have much faster update rates at 5, 10 or faster update rates. Sadly, many of them are not actually providing new satellite fixes….they are dead reckoning based the previous input. Not all but question those at higher rates, they are often only doing something you can do better locally.

GPS is based on a set of satellites to estimate a position on the ground. Each and every one of them are flying about the earth in a designated pattern with errors in the orbit. A few of them, 3 minimum, give you a fix on the ground to a certain degree of accuracy. Check your data sheets for the Circular Error Probable (CEP). It’s likely 2.5 meters or more.

Now, if you are SparkFun contestant, how wide are the roads around the building? If you are directly positioned in the center of the road with a 2.5 meter estimate and the fix is wrong, are you in the pond or trying to mate with the building? Put an X on the ground near your test site and see how the position changes if you check again in an hour, later in the day, tomorrow, etc. It’ll vary somewhat even throughout the day.

Unfortunately, it gets worse. Today’s GPS receivers are much better at getting fixes from satellites in suboptimal conditions. Like indoors and with marginal line of sight to the satellites. Excellent, right? Yes, and no. It’s great when you are looking for a rough position when you are in the woods and turned around. It is far from precise. When you are lost, a few hundred meters doesn’t matter a great deal.

If you are a robot relying on it to accurately position you in the world, it becomes rather critical. The GPS gives you some notional feedback in the form of the horizontal dilution of precision (HDOP). It can be utilized as an estimate for the accuracy of the position. Once again, the GPS unit is giving its best guess for the current situation.

Can it get worse? Yep. If you are reading in GPS data, grab it on one side of a large building, then run around to the other side. Obviously, the position will change but what else? The satellites in view will. Don’t believe me? Record that GPS sentence. Why is that important? The precision of the fix shifts as you change satellites. Worse, it causes “pops” in the position if you rapidly change from one set of satellites to a different set. With buildings and other occlusions, that happens a lot.

Guess what? The faster you change satellites, the worse that position estimate becomes. If you’ve tested a lot with raw GPS as a sensor, you’ve likely seen it happen. Will it screw you for the contest? Maybe, maybe not. It all depends on the set of satellites of view, which is constantly changing.

How does Dead Reckoning play into the equation? Well, that’s why our vehicles have an encoder to give us an accurate estimate of speed. Couple that with a change of heading based on the steering angle, and the vehicle can predict where it believes it should be. Errors creep into dead reckoning quickly as well.

If we can detect a major pop in position, smart decisions can be made to wait for the position to settle or to rely on the DR solution. Smarter people than me would feed it into a Kalman Filter and run off the results. Lack of precision makes robotics a lot of fun.

Categories: Sensors, Software

Fab Nearly Finished

February 28, 2010 Leave a comment

Everything barring the encoder has been installed on the new vehicle. I’ll get more photos up after the fabrication is completed and after final electronics integration.

Hinged Plate for Electronics

Servo for Panning Ultrasonic

GPS Module in the Rear

Categories: General, Hardware, Sensors

We’re In!

February 26, 2010 Leave a comment

Today, I received the email from SparkFun.   Another team has dropped out so we are officially in!   Too bad for the other guys but I am happy for us.   The added pressure should ramp up the effort over the next few weeks.    So much to do, so little time….

Goodbye RC Control

On that note, work continues on the vehicle.   Today, I gutted the stock RC electronics.   Our current approach bypasses the RC receiver completely so I just removed it from the vehicle.   Traxxas did a pretty nice job of packaging the receiver and servo cable entry for water resistance/proofing.   But it had to go.

Next, an IR sensor was added to the rear of the vehicle mounted on the stock bumper.

Rear IR Sensor

Given the single sense beam, it is unlikely to be of significant help but should allow the motion planner to avoid ramming into something if the vehicle has to back up to get out of a cul de sac.   A little information is better than none at all.

I chopped up a little aluminum plate to fabricate a mount for the GPS sensor near the center of the rear axle.   Having it close to the point of rotation minimizes the need to do additional math to translate the actual position.   Simpler is better when it comes to calculations.    Once the paint is dry, I can get that installed

The encoder from US Digital should arrive on Tuesday.  By far, that will be the most complex to install and mate to the drive gear of the transmission assembly.  An accurate indication of speed is essential to being able to dead reckon between GPS updates or to handle GPS outages.    However, the steering will not have a feedback mechanism.   For now, the software will just have to trust that the set point is being achieved to determine steering angle and radius.    Not foolproof but should be sufficient.

Due to the battery compartment being only accessible from the inside of the vehicle, it makes mounting electronics difficult.  I’ll have to fab up something to allow access to the battery while still allowing the new electronics to be mounted and stable.    I should have dimensions from Floyd tomorrow when he returns from a trip so I can get that done.

In the interim, I’ll be continuing software development on our original prototype vehicle.

Prototype One

Prototype One

Floyd has already done the hard work on this vehicle but it lacks the new board plus the bulk of the sensors.   As you can see, we’re using XBee modules for remote telemetry and debugging.   Eventually, that communication will be quashed down to only a few control messages for mission execution and a remote stop signal.

Categories: General, Platform, Sensors

So what’s this all about?

February 25, 2010 Leave a comment

Team HellHound has entered the SparkFun Autonomous Vehicle Competition. Actually, we’re not officially in the contest. We’re on the alternate list and hoping some other teams will drop out or be eliminated when the video is due by April 1st.

The team is Floyd H. and me, Mark H. Combine the H’s, find a word that fits and you end up with HellHound. Worked for us. Floyd is an electronics and software guy. He already laid out a custom board for control of the vehicle and sensors interfaces. I’m primarily a software guy but am also working to get items physically mounted since I have a few more tools at my disposal. Beyond the competition, we work together and have been involved in numerous autonomous vehicle programs over the last decade. Yeah, we get paid to do it but this one is all for fun, fame, and just to hang out with the cool folks at SparkFun.

For the contest, we’re entering the ground vehicle portion of the competition. We have a couple of vehicles already computer controlled but made the decision to get one that is more capable than the ones Floyd had on hand. So I purchased a barely used Traxxas Slash. I picked it up on the 17th. Work has begun to get it equipped but I’m awaiting various parts.

Before major mods

Here’s the vehicle before invasive modifications commenced. Beyond the stock vehicle, the only thing added is the front IR sensor mount. As parts begin to arrive this week and next, changes will be pretty rapid. Currently, we’ll continue to use the stock speed controller but that may shift if speed control doesn’t have quite the fidelity we need. It might mean a brushless motor upgrade but hopefully we can avoid doing so but Floyd’s board is ready to handle it if necessary.

Front IR Sensors

Obviously, we’re adding sensing to the vehicle in addition to GPS. Considering the vehicle is going to be driving itself, knowledge of the environment is critical. The IR’s are the starting point but ultrasonic sensors are also planned. If all goes as planned, we won’t need a depth meter for the pond. Things rarely go as planned so maybe I’ll look into one.

I’ll add updated photos as the modifications progress. Once the next red box arrives from Boulder along with a couple of brown ones from US Digital, A Main Hobbies and L-Com.