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. 

Another NASA Rover

CREDIT: NASA/Ames Research CenterView full size image

Stumbled on this NASA rover in this article on an Lagrange L2 point space station being considered. NASA Ames is using the rover to test teleoperation. A station at the L2 point would be directly behind the moon from the earth. Astronauts could use teleoperated robots to study the backside of the moon.

[Lagrange points are stable locations caused by the gravity fields of an object orbiting another object, in this case the Earth and Moon. An object at a Lagrange point is held in place by the gravity fields. See Wikipedia for more details.]

Anyone have more information on this rover?

DARPA LAGR Project

Today I was looking through some robotics papers applicable to Sample Return that I previously found on the web. One mentioned they were using a DARPA LAGR robot so I looked to see what it was. I found that Carnegie Mellon was involved in producing the standardized robots. The idea was to provide these robots to different researchers, have them develop navigation software, and have them compete on real-word runs to see what went better. The robots only had vision, GPS, and bumper sensors. The outcome of this project seems very applicable to the SRR competition.

One of the researchers at NYU has a long list of papers on navigation.

Sample Return Robot Challenge

The focus of the blog is changing. I mentioned that I rotate through projects. It is time to focus more on robotics, specifically the NASA Sample Return Robot Centennial Challenge.

In June 2012 NASA ran a Centennial Challenge competition at Worcster Polytechnic Institute. This concept for the competition was a robot on the Moon or Mars retrieving samples. Its tasks were:

• Obtain a pre-cached sample
• Search for other interesting samples
• Return all samples to a landing platform

I considered entering but abandoned the effort for personal and technical reasons. I am going to use the competition guidelines in the development of a robot. I believe the challenge will be repeated and am working now to overcome the technical issues. I will be sharing the effort on my web site. I am starting with a high-level analysis and dropping down to more details as that proceeds.

On this blog I will keep some notes on what has been updated on the project and provide some running commentary on the effort. 

Android - Galactic Guardian: Zap GPS Lite Released

I finally released the free, lite version of Zap GPS to the Android market. If it is received at all well, I will do a paid version. If you have tried the Lite version and have ideas on how to improve it or enhance it for a paid version please feel free to comment.

The Lite version omits one capability that the ADC2 version contained: cloaking. I felt that was an interesting capability that would be better in a paid version. Cloaking is implemented by hiding a Sentinel if the GPS (Global Positioning Satellite) signal is lower than a threshold. The player still needs to damage the Sentinel to proceed to the next round but it is more difficult since the Sentinel cannot be seen. When both Cloaking and Command & Control (sequential destruction) are present it can be difficult since a cloaked Sentinel may also drop off the Sentinel list because its signal is weak and then lost. But if may reappear if the signal increases. If it is the lowest sequential number the player has a real challenge.

One additional feature is timing the player. The player would be allowed a period of time to damage the Sentinels in the list. After that time Sentinels would be "repaired" and added to the list. That isn't implemented but would be easy to do.

The big feature to add would be competition among users. That would require setting up a web presence to record scores and show the best players for, say, the day, week, and month. The effort for that would be about the same as developing the game up until now. Not sure I want to expend that much effort for little or no reward.

Any other ideas for Zap GPS? Any ideas for a different Galactic Guardian game?

RoboRealm Vision Processing - Wrappers Classes

I've been working with RoboRealm over the last week. It is a vision processing application. One of its nice features is being able to access it from another program. You can let it do the heavy lifting of extracting information from a web cam image and then your program just gets a few important data points for analysis.

The module I've been working with is Center of Gravity which locates a blob in the image and reports its size and location. In particular, I'm looking for a red circle.

The interface I've used is the RR_API which is a XML over a socket connection. Reading a single variable is straightforward but reading multiple variables with one request is a lot of detail chasing. I hate chasing details over and over again. That is why they originally created subroutines and, more recently, classes. So I wrote some classes to wrap the read variable routines. I haven't need to write information, yet, so that will wait until needed.

The files are in Google Code.

Individual variables are handled through the RoboRealmVar class and its base class RoboRealmVarBase. The base class is needed to provide an interface for reading multiple variables. More on that below.

RoboRealmVar is a template class to allow for handling different data types. One of the details with th RR interface is all data is returned as a char string so it has to be converted to the correct data type. The class handles that automatically. The header file has instances of the template for int, float, and string. Other types could be added but may need a char* to data type conversion routine. See the string instantiation for how that is done.

Variables are declared by:

rrIntVar mCogX;
rrIntVar mCogBoxSize;
rrIntVar mImageWidth;

The examples are all class members, hence the prefix 'm' on their names.

Initialize the variables with the instance of the RR class. In the example mRoboRealm is the instance of RR opened through RR_API:

mCogX("COG_X", mRoboRealm),
mImageWidth("IMAGE_WIDTH", mRoboRealm),
mCogBoxSize("COG_BOX_SIZE", mRoboRealm),

and then read them using an overload of operator():

int cogx = mCogX();

Multiple variables are read using the RoboRealmVars class. Declare it and instantiate it with:

RoboRealmVars mCogVars;
mCogVars(mRoboRealm)

Again, my examples are from inside a class.

Then add the individual variables to the list by:

mCogVars.add(mCogX);
mCogVars.add(mImageWidth);
mCogVars.add(mCogBoxSize);

then read them through:

mCogVars();

You can access their values just as shown above through the individual variables.

Hopefully this will be useful to others.

Create Fun with Grandson

Last weekend two grand kids were here. The girl, Dorian, is a teenager. The boy, Kade, is six. Just before Christmas I was working on the Fit PC Slim to iRobot Create interface when they visited. He had his nose up close asking when it would be done. He asked the same thing in another visit since then. I had to reply it was not done but I was working on it.

So this visit I just had to have something working. I got the basic wander and bump into routines working with the Slim - a reproduction of the Create demo 1 behavior. I figured that would be good for about 2 minutes of interest so needed more.

Since this project will be using a web camera for vision I used some velcro to plunk the camera onto the Create just behind the IR sensor. The velcro raised it enough to see over the top of the sensor. I brought up RoboRealm and setup its built-in web page viewer. This lets you see the camera's images. I pointed the laptop at the web pages to display what the Create was seeing.

That was good for about 20 minutes and we got called for lunch and told to put the robot away. Awwww!!!

Next visit is in a couple weeks - they are visiting here pretty regularly now. The goal is to have the Create follow a "leash" - a red dot mounted on the end of a stick. That means getting the software to talk with RR to get information on the center of gravity (COG) of the red dot and send the drive commands to the Create to center and drive toward the dot. It should stop when it gets a little bit away from the dot, and even back up if the dot gets closer.