Older blog entries for RoboDo (starting at number 8)
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
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
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
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
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
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
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.
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
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.
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
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
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
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
The most basic levels of awareness will operate
automatically, no matter what the control mode. These
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
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
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
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.
18 Mar 2008
(updated 18 Mar 2008 at 14:58 UTC) »
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
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
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
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
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
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
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.