Skip to main content

Thinking About the Challenge - Software

Despite nothing appearing here for awhile I have been thinking about the SRR Challenge. I had a week in Mexico and a week with a cold that kept me from writing. Now I am back to making some progress. I'll summarize some of the thoughts, possible plans, etc. No additional analysis, but there are some things that need to be looked at based on my thoughts.

As I look at hobby robot builders web sites I've concluded that most build a nice piece of hardware that doesn't really accomplish anything real. I've seen some beautiful robots that are the delight of machinists. But there is no mention of any software driving them that makes them meaningful. As I looked at the robots from the 2012 SRR Challenge competition I wonder how many of them spent many hours on the hardware and let the software go until the last minute.

I know from experience in embedded systems development that the hardware is always late. Since there are limits to what can be accomplished in software when you don't have even the preliminary hardware that makes the software late. (And software gets the blame for the project being late!)

I am going to avoid this trap by focusing on the software first. Still, I need some hardware to make progress but that is for the next entry.

I've thinking about the actions the robot needs to accomplish. Some of these are trivial, some need a lot of detail chasing but are straightforward, others are challenging, and still others are possibly beyond my capabilities.

If there are any of the last group I probably cannot enter a credible entry into the challenge. I won't know until I try. A prime example of this is using the vision processing to identify samples at a distance.  Another is maintaining the location of the robot in the search area so (1) all the area is searched and (2) the starting platform can be located so samples can be returned properly.

The trivial items are the basics of controlling the robot:
  • Controlling the motors to drive where needed,
  • Read sensors to determine orientation (gyroscope),
  • Drive servos for positioning the picker or cameras,
  • Etc.
Detail chasing items are:
  • Drive to a potential sample that was located,
  • Etc. (Which means I haven't identified these.)
Challenging items...well, I'm not sure yet. More analysis is needed to identify these. 

Comments

Popular posts from this blog

Sensor - Accelerometer & Magnetics

Just as I was finishing my first look at the accelerometer and magnetic field sensors a couple of threads cropped up on the Android Developer's group:

http://groups.google.com/group/android-developers/browse_frm/thread/1b42c48ce47cb1c9/720c6f4f8a40fc67#720c6f4f8a40fc67

http://groups.google.com/group/android-developers/browse_frm/thread/2e14272d72b7ab4f#

I had the basic code working so dug a little deeper into the rotation routines and the timing. I posted responses on the threads but want here to dig into the details more.

First some observations applicable to my G1:

The sensors report approximetly every 20, 40 and 220 msec for FAST, GAME, and NORMAL.
A sample may be missed for a specific sensor but usually one of them will be generated - but sometimes all can be missed.
The magnetic field sensor is most reliable with only a few drops. The other sensors are dropped considerably more often.

A caveat in all this is the way I setup the sensor handling may make a difference. I have a singl…

Programming Languages Used for SRR

I asked at the SRR Challenge about the languages and vision processing used by each team. Here is what I found:

Team Language                       Vision Processing
Intrepid                         C++ / Matlab                                           Kuukulgur                     C++                                          OpenCV Mystic                           C++                                          RobotRealm SpacePride                    RoboRealm state machine          RoboRealm Survey                           C++, Python                             OpenCV Middleman                     LabView                                   LabView UCSC                           C/C++                                      OpenCV Waterloo                       C++, Python                                             WPI                              C++                                                              Wunderkammer             Python                                      ROS …

Shifting Gears - iRobot Create

I'm shifting gears to robotics. Awhile ago I got an iRobot Create. Its basically a Roomba vacuum cleaner with the guts removed to make a cargo area. In this area is a 25-pin connector that provides power, TTL serial port, digital and analog I/O.

I also got a Command Module (CM) which fits onto the connector. The CM is an Atmega 168 processor that adds some additional I/O. It can be programmed to control the Create. I did so and basically reproduced the wandering behavior of the Create. It move around, bumps into things and turns away from what it hit. I added some additional behaviors such as if it got trapped, i.e. caught in the same place for a period of 10 secs, it would move to extract itself.

I want to do more with robots, such as entering in a RoboMagellan contest. That requires an outdoor capable robot that does a lot more than bump into things. A key component to me is vision. Maybe I could do that with the CM and another processor (like the CMUCam) but I really didn't …