RoboDo - Distractions

BrainBoy and the Slug: BrainBoy was an NXT bot which navigated with the sonic sensor, while the Slug had no sensors. The 2 were in communication via bluetooth, with BrainBoy recording its movements, introducing a 3 move lag, then transmitting moves to the slug, who just followed along. I was exploring an idea for the robotic transportation of military goods where a manned truck would be followed by an unlimited number of unmanned robot trucks carrying supplies.

The Chariot: The Chariot was another experimental bot which featured a front powered section (without sensors) which pulled a trailer containing a sensor array. Having the sensors in an unpowered trailer allowed me to build a sensor array that was capable of continuous 360 degree rotation.

Just for the record... this intensive electromechanical research and development phase, involving numerous iterations, each exploring different design possibilities while keeping within the physical constraints of the available robotic prototyping system should never be confused with "playing with Legos." Someone needs to explain this to my girlfriend.

Ok, maybe the robo-forklift was just for fun.

RoboDo - Toddler

RoboDo will eventually be a biped humanoid, but that is a long way off. For the moment, I will concern myself with laying the foundations. The RoboDo series of bots is building towards the main project goal.

The latest incarnation in the series is RoboDo Toddler, based on the Lego NXT system. RoboDo Toddler is actually like 2 robots in one.

The top section contains an NXT controller, an ultrasonic sensor with 180 degrees of motion (right-left), and 2 sound sensors. The top section will handle the decision making processes.

The bottom section features an NXT controller, 2 touch sensors, and 2 light sensors.

The top part looks around and maps out where the bot can and can't go from it's current position. It then decides what to do, sets the numerical variable "order" to a number representing its choice, then sends the value to the bottom section via bluetooth.

The bottom section sits and waits for a message. When one is received, it executes the order if possible. It then returns a status message to the top section and waits for further orders.

The bottom section usually just follows the instructions passed to it from the top section, but there are times when it can't follow these instructions. For example, if the bottom section gets an order to move forward when the front bumper sensor shows that way to be blocked, this condition is recognized and the bottom section instead follows instructions specific to this condition.

In any case, the bottom section generates a status message which it sends to the top unit, again via bluetooth. This status message not only lets the top know what's going on in the other unit, it also serves as a timing signal; the top will sit and wait for this message before thinking about its next move.

The NXT-G language seems rather limited, but the custom blocks allow the creation of simple behavior "chunks" which can then be assembled into much more complex behaviors. The graphical interface allows one to make visual sense of the interactions, which makes development go much faster. Yes, I will be going to a more powerful language one day, but NXT-G is perfect for this stage of my project.

Adopting coding standards, even at this early stage, is crucial. Top and Bottom sections may run different code, but they both use the same variables for the same functions. Custom blocks used only by the top section all start with the letter "T" and those used by the bottom start with "B". The icons used also display a consistent pattern. These "small" details will pay big dividends as the project gets more complicated.

The control scheme, based on "orders" and "reports" is simple and effective, and allows co-operation between the sections. The top section decides what to do, but the bottom section is allowed some flexibility in how to carry out the orders. I am starting with a very simple set of possible actions, but once I get the system itself working properly, I expect to develop much more complex responses. I think the basic control scheme will scale up well.

More soon...

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...