Baby's First Words

My little NXT bot, RoboDo Baby, has uttered its first word, which was, "Ooops."

I'm using the sounds to help me figure out what's going on in the program as it runs.

Right now, Baby moves forward until it detects something within 10 inches. Once it detects something in its way, it says "ooops" then calls a custom scan block which returns range data for 90 degrees right and left, 45 degrees right and left, and straight forward. This data is then passed to a primitive mapping block which sets the variables right, front right, front, front left, and left to either "1" (can enter) or "0" (can't enter.)

If the way is clear in only one direction, Baby says "turn" followed by the clear direction. Baby will then turn in that direction and restart the movement routine.

If both right and left are valid options, Baby will randomly pick a direction. When this happens, Baby says, "Mindstorm" before making its choice. Introducing random elements gives me the ability to dynamically weight these decisions at some later time.

Two variables are set whenever Baby turns: "dist-turn" resets the distance Baby has traveled since the last turn, and "last-turn" records the last turn direction.

These variables are used in a special case where Baby has wandered down a corridor where turning is impossible. In this case, Baby says, "ooof" backs up to its last turning point, then turns in the same direction again, which sends it back the way it originally came from.

I'm having problems with the turns. It's hard to get accurate 90 degree turns, so Baby crawls in odd directions. The easiest solution will be to get the compass sensor, and that's what I intend to do.

Baby also hits its back end sometimes when it turns. Since RoboDo will have bluetooth communications between torso and legs, I am considering getting a second NXT kit so I can play with NXT to NXT communications via bluetooth. This would also give me more sensors and servos so I could have the bot navigate more effectively. If I do get another kit, expect RoboDo Baby to be replaced by RoboDo Toddler. :-)

That's all for now.

RoboReality

Ok, so maybe building a 32 DOF biped humanoid Kung-Fu bot isn't the best "first project". Though confident I can mostly handle the mechanical end, the computer end is way beyond me... for now.

I can't afford to spend thousands of dollars on parts all at once, and even if I could, the complexity of getting it all working together would be quite overwhelming.

So I bought a Mindstorms NXT.

I'm a "hands on" kinda guy, so this will give me the chance to get some experience with the sensors and programming... real world interaction.

I built and unbuilt RoboDo Zigote and RoboDo Fetus, learning as I went. I'm pretty happy with the newest incarnation, RoboDo Baby, which has 2 driven front wheels and one unpowered rear wheel. The ultrasonic sensor is mounted on the 3rd servo, and the sound, light, and touch sensors are mounted up front too.

So far, Baby crawls forward until it detects something within 10 inches. It then looks left and right, recording the sensor readings. Baby then turns in the direction offering the most room and starts crawling forward again.

The next evolution will be to use data from the other sensors to build a more sophisticated control scheme. For example, I would like Baby to tend to turn towards the light when blocked forward but right and left are both clear. I want to mess around with weighting sensor reading to influence control decisions, which will all be probabilistic in nature.

Another thing I am going to start developing is a mapping routine. I'll start with a limited 6" grid, perhaps as small as 10X10. I'll preload areas outside the map as "0" or unreachable, start Baby in a known location and orientation, and let Baby fill in the rest of the map as either "1" (reachable) or "0" (unreachable). This will, no doubt, give me all kinds of problems to overcome or work around.

The NXT-G language is interesting, but can seem like trying to build a bridge with dominoes sometimes. I am looking into options here, and am leaning towards switching to NXC soon.

I have not given up on RoboDo. The RoboDo Baby work will lay the foundations for what is to come later. I would expect to use a succession of platforms in this project, and this is but the first.

That's all for now...

RoboDo: Overall Control Ideas, Awareness

RoboDo should be able to amuse, entertain, educate... and fight. In order to do these things, the robot will need a certain awareness.

The most basic levels of awareness will operate automatically, no matter what the control mode. These include...

RoboDo should be aware of its body position, center of gravity, and current and upcoming motions in order to maintain its balance. A 2 axis gyro/3 axis accelerometer combo will be the main sensor in this sub-system, and corrections should be applied in real time, without involving upper level subsystems.

RoboDo should be aware of its environment. Mapping (including sonic mapping) will be a key process, at least in most modes. The head mounted Ping ultrasonic sensor, head mounted sound detectors, and hip mounted Sharp IR sensors will provide the data. This environmental data will automatically limit the robot's actions. For example, the "walk forward" command would be disabled if there was a wall directly ahead.

This lower level data (balance and mapping) would be used by the mid level subsystems...

The localization sub-system would add the "you are here" sticker to our map. This subsystem would use data from the onboard compass, mapping sensors, and vision system to determine the robot's position. (The ceiling, with its uncluttered straight lines and clear intersections might prove useful here)

The tracking subsystem will use the vision system to detect and track moving objects. This will probably involve capturing several frames and comparing them to see what's changed. The camera will have servo control of tilt and pan and automatically track the closest object in certain modes.

Upper level subsystems related to awareness include the actions subsystem, which maintains an array containing all of the actions RoboDo can perform. Mode constraints will eliminate some of these possible actions. For example, the "do a cartwheel right" action isn't available in "Explore and Map" mode. Map constraints further limit the actions, and other subsystems may limit the available actions too.

These subsystems will work together to provide a certain sensory awareness. Through them, RoboDo will be aware of its body position and center of gravity, it will sense its environment and know where it can and can't go... what it can and can't do. It will also recognize and track other moving objects in its environment.

Anyway, that's the general idea as it stands now.

RoboDo Seeds

I'm using my blog as a notebook... to keep track of the ever changing idea that may one day become real. I suspect that what I write is so far below what some here are doing that it seems laughable. Much of it is probably unworkable, too complex, too simple, or just plain wrong. Writing this stuff helps me understand by exposing what I don't understand.

I got sucked into this biped robot thing when I stumbled upon a video from one of the Robo-One competitions. It was rather amusing, actually. The 'bots stood (sometimes) flat-footed, in a normal standing stance, and sometimes flailed away. As often as not, their own exertions caused them to topple. Huge lags between moves showed serious flaws in the control scheme. THIS was the current world standard?

My inner engineer recoiled in horror. A quick look at the bots themselves revealed that most of them were unable to assume a proper fighting stance. What the world needs, thought I, was a robot that can learn Kung Fu.

The new bot, dubbed RoboDo, would need to have an autonomous fighting mode, and this itself presented a problem. Did I really want to create a 2' high terminator?

To win, my bot would have to lock onto a target, close to striking range, then deliver an attack... all under its own command. Clearly, safeguards would have to be devised.

It should be possible to place the fighting routines on a flash card, and only insert the card during actual competitions or when "training" the bot. (Ok, a 2' bot with very limited battery life isn't going to take over the world, but we don't want him mauling the dog.)

So it seems possible.

Mechanically, the bot isn't all that difficult. I have most of the details more or less worked out, and am confident I could build it. I don't have the funds to build it all at once, and frankly, don't have the expertise required to program it.

But I can start somewhere and learn as I go. I have an overall idea of where I want to take this project. I'll probably end up getting one USB servo controller and a few servos and building an arm or leg or something.

Maybe I'm just not smart enough to be intimidated by this.

more later

RoboDo Control: Revised

One of my design goals in the RoboDo project is to establish "levels" of control which mimic, in some small way, the interactions found in nature.

When you wake up in the morning, what do you do?

I open my eyes and look at my environment. My body tells me I am lying down. My mind then determines that I am in bed in my bedroom. I then mentally review my priorities and decide what to do next. This almost always involves getting out of bed.

Note that most of this is done more or less automatically, and that different "systems" are involved. Note also that some of these systems are under the direction of other systems, but that the "lower level" systems don't need detailed instructions in order to perform their routine tasks. When we decide to walk, for example, we don't need to concentrate on moving each muscle... our legs know how to walk. It's exactly this sort of layering I want to explore.

I now see that I will need more processing power and memory than that provided by the typical microcontroller, so I am looking at a single board computer (SBC) instead.

The new scheme includes a SBC with a 500Mhz processor, 1 gig of RAM, 4 USB ports, 4 com ports, a flash card slot, and fast Ethernet. A 16 channel USB servo controller in the hips will control the legs, while another in the torso will control the arms. A 4 channel USB servo controller will handle the torso bend and torso rotate, as well as the head tilt and pan. The torso will also contain a USB I/O board for the sensors.

Of course, all of this is subject to change. :-)

More to follow...

Humanoid Robot Joints - The Hips

The hip joints of today's popular bipedal robots have many limitations. More articulation in this area would allow much greater range of motions.

After playing around a bit, I have come up with a design which I intend to use in my RoboDo project. Here's a rough picture...

The "stride" servos (the topmost ones) are connected to their respective legs with either chain or gears, which allows us to reduce the 180 degree servo motion to 120 degrees. This will produce a modest gain in power while limiting the travel in this joint to 75 degrees forward and 45 degrees backwards.

The main benefit however, is that this allows us to have the leg joint supported by a solid shaft and 2 bearings.

The leg rotate servos are also supported by 2 bearings. I just don't like the idea of hanging the whole leg off of a single, cantilevered support point.

At first glance, the "leg lift" servos (the lowest ones pictured) may seem redundant, but these servos will allow RoboDo to kick higher when the legs are rotated to their normal walking position, and allow freedom of motion in this area when the legs are rotated to other positions.

More soon...