Skip to main content

Create - Initialization Processing

Developing software is as much a research project as an engineering process. In part this is because a developer is not usually a domain knowledge expert, say, an accountant. The developer thus has to learn a fair amount about the domain in order to proceed. Still, some of the learning occurs as the project proceeds. You have to learn what you don't know.

First lesson is that the Create doesn't provide unswitched power that is sufficient to run the Fit PC Slim. If the Create is turned on there is sufficient power. This means the Slim can't turn the Create power off because the Slim loses power, also.

Ideally the Create can stay on all the time. It has a docking stations - its home base - for recharging. The built in processing can find the base and run onto it to charge, or my software could replicate that processing.

First minor glitch is that the Create stops responding to the Slim commands when it docks. It turns out there is an undocumented soft reset command (a '7') that puts it back into a mode where it will accept commands. Once back into this mode the Slim can monitor the charging process and determine when it is safe to leave the dock.

When the Create is charging is a good time for doing work on the interface board or the Slim. What happens when you reconnect everything onto a charging Create?

The (re)learned lesson is that startup and shutdown processing are often the most challenging parts of a software project. Once everything is up and running a software process is usually straightforward, albeit with a lot of details to chase. You just nibble away at them one at a time until they are all resolved. Then the process is just doing the same thing over and over again.

Startup is a big discontinuity. What was the robot doing before it shutdown? What has changed since then? What is the current state now?

This all was triggered when I realized the robot had to determine whether it was charging or in the wild when it started up. It takes different actions depending on where it is. If docked it continues until charged, backs off the dock, and switches to "wild" mode of operation.

Okay, who said, "Rud, as an experienced developer you should have dealt with this already." Guilty as charged but this has been a casual, hobby project up until now. This was my wakeup to start applying a more formal approach and thinking through some of these issues. I'm still not going to go fully formal since I'm more interested in having fun. So don't expect a 6 week hiatus while I produce a formal analysis and design. I am going to do some of my thinking in blog posts, using it for my documentation.

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 …