Archive

Archive for the ‘Software’ Category

Traxxas Now with More Horsepower

April 9, 2010 Leave a comment

Okay, perhaps the title is a bit misleading…more computational horsepower. Today, I finally got around to mounting the TS-7800 from Technologic Systems. It’ll be running all the main processing and communicating with the micro controller via a serial port.

Additionally, we’d failed to include a shiny “GO” switch anywhere in the system so I used the DIO port on the ARM to read in a signal to indicate the mission should execute. If you are looking for sample code for the TS-7800, Eric Robishaw’s example is a good start.

If that’s a little much to parse, here’s my simpler variant. It does far less but is a test bit of code that shows the reading without a lot of extra capability.

I’ll leave you now to get back to porting code over to the board. Here’s the vehicle with its ever growing payload.

Computational Horsepower for Easy Living

Update: Just a word of warning, the distribution of Debian shipped with these board is ANCIENT. Packages are no longer available.

Advertisements

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.

Software Architectures for Robotic Systems

March 5, 2010 Leave a comment

Autonomous robotics is a nascent field of study compared to mathematics, electrical and mechanical engineering or any of the many other disciplines which influence the development of robotics. So many fields of study are transforming robotics today it is nearly impossible to list them all.

Software architectures for robotic systems have been split for for over three decades. Two primary approaches have been researched, implemented, and demonstrated — reactive systems and planning systems.

Reactive systems are also know as behavior based architectures. The reactive approach in a nut shell is awake, sense, process and execute a motion or action but not store any significant knowledge. One of the key researchers in behavoir based robotics is Rodney Brooks who developed the Subsumption Architecture.

The opposing field of study is based on a hierarchy of control decisions that retain knowledge of the world between each update cycle. Essentially, each tier of the software passes a decision to a lower layer. Each of those layers manages a model of the world at the fidelity required to make a decision for execution. James Albus is one among many who have contributed to the hierarchical architecture literature with his development and contributions to the 4D/RCS architecture.

Most architectures are leaning toward the planning model today. Not all. Lightweight, behavior based approaches can be used if the environment is constrained along with the problem. I Robot has sold many (not so functional) Roomba vacuum cleaners based on a purely reactive model.

For heavier problems, the DARPA Grand Challenge I & II and Urban Challenge provide a wealth of information on how teams approached the problems. Most teams in the competitions had and have a good web presence. A little searching will demonstrate most of the successful teams utilized plan based approaches.

Recently, probability has taken a large role in many robotic systems. One of the leaders in the field is Sebastian Thrun who published a text Probabilistic Robotics covering the field.

Which one is right for the 2010 SF competition? Time will tell.

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

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.