the stair climber - University of Washington



the stair climber - University of Washington
The goal of our project was to design a
robot that would climb stairs in a skillful,
calculated and efficient manner.
Climbing a set of stairs is not a new
challenge for robots, in fact it is often a
common obstacle used by designers to
showcase the robot’s skills. Another
aspect of our challenge was to use two
LEGO NXT robots (the brick/brain) in
cooperation with each other.
Biped robots are most often the ones
equipped to climb stairs. Their function
is modeled after human movement. We
also researched all-terrain robots that
are designed to plow over various
obstacles with brute force. The smaller
scaled robots, such as ours, usually use
the brute force method and are not able
to skillfully climb stairs. With the specifications of the LEGO NXT kits we decided
a biped robot would exceed their ability.
The motivation for this project was the
sheer physical challenge presented by
the specifications of the NXT kits. The
design stems from a crab-like motion
with two independent legs that lift a
center body up the stairs. We were
interested in using Bluetooth technology
to communicate between both bricks.
University of Washington
Exploration in Designing Behaviors
Winter 2007
Lauren Miles is a Visual Communication
Design Senior with no previous programming experience. An interest in
interaction design and technology lead
her to join the class. So much of design
is intuitive, the chance to work on a
project that gives the satisfaction and
problem solving of a right answer was
Andrew Gawronski is a Computer
Science Senior with experience teaching
programming to computer science
introductory level students. His interest
in visual languages for education motivated him to try this experimental course
and explore working with students of
other disciplines.
Chris Schlechty is a Computer Science
Senior. He likes robots; he hates stairs.
He thinks robots that could climb stairs
would be cool. Chris is interested in
human-computer interaction and
2 x NXT Controller Brick
6 x NXT Servo Motors
1 x NXT Touch Sensor
We have created a robot that works in
complete cooperation with another robot
to climb a set of stairs. The design is
modeled with a crab-like body and uses
the communication method similar to a
common fire truck.
The Stair Climber consists of two legs
that connect to a central body composed
of the NXT bricks. We engineered a
system that consists of two LEGO NXT
bricks that control different parts of the
Stair Climber. One brick controls the
front legs and the other controls the
back. In a prone position, the robot
drives with both legs extended parallel to
the base of the body until it encounters a
step with its touch sensor mounted on
the front leg.
Various LEGO Pieces
The Stair Climber’s two drive arms allow
the robot to evenly lift and lower its large
The Stair Climber starts in a still
position. It drives forward until it hits
a step with the touch sensor. Then it
backs up and raises the front arm.
With the front arm raised the Stair
Climber drives forward until the front
wheels are on the step.
With the top wheel on the step, the
motors near the body push down and
therefore lift the body to a designated
Once at the desired height the drive
motors (attached to the wheels) drive
forward pulling the back of the body
onto the stair.
and heavy body from both sides. On each
side, there are two motors which lift the
drive arm; at the end of the drive arm is
a third wheel that moves the robot
forward. When the robot encounters a
stair, with its touch sensor, the robot
raises its front arm and places it at the
top of the step. Once the front wheels are
at the top of the step, the robot begins to
push down, applying pressure on the
stair and lifting the body. Simultaneously,
the back arm and wheels drive forward
and lift up the back half of the robot.
After the center of the robot is partially
lifted, the robot drives forward to align
its body over the next step. Once on the
step it raises the back arm and proceeds
onward. The program loops to look for
another step to repeat this process.
functions; one controls the back half and
the other the front. In order to achieve
synchronous execution of tasks, we must
communicate constantly via Bluetooth
technology to let the other logic brick
know at what point in the process it is. It
works much like a fire truck in that the
front and back drivers communicate with
each other to navigate the truck. Due to
the sheer size of the NXT bricks the
programming of this robot requires quite
a bit of coordination to manage the
difficult angles each motor needs to
move. In order to achieve synchronous
execution of tasks, we send messages
between the two logic bricks and they
cannot move on in the program until they
have been received. This ensures that
both logic bricks are at the same point in
the program.
As mentioned above, the two logic bricks
of the Stair Climber control different
Once the body is safely on the step,
the back arm lifts to clear the step,
while the front wheels drive forward.
The end position is with the Stair
Climber completely horizontal on the
next step. The program loops and
starts looking for another stair.
The following programs, created in Mindstorms, controls each end of the
robot. The first diagrams show the actual programs created to control the
robots. The next diagram shows the links of communication between the 2
logic bricks. All communication was done with Bluetooth to let the different
bricks know at what point in the program they were.
Initialize all motors.
Send message to
SLAVE to go.
Receive message
from MASTER to go
then drive forward
Receive message
from MASTER, then
drive in reverse
Drive forward until
touch sensor pressed.
Send message to
slave to back up.
Back up and lift
front arm.
Send message to
SLAVE to drive
Receive message to
move arm down
Move arm down
Send message to
SLAVE to lift up
Continue to lift
Receive message
from the SLAVE
that back is up
Receive message
from MASTER to
drive forward
Drive forward
Send message to
MASTER to move
arm down
Receive message
from MASTER lift
back end
Lift back end and
drive forward
Wait and then lift
back arm up off the
Send message to
MASTER to drive
Receive message to
stop all motors
Stop all motors
Drive forward and
send message that
program is over
angles than their respective motors have
the power to turn against. It was a series
of small changes to perfect the timing
and Bluetooth communication between
the two bricks.
We had a fairly smooth process with
dramatic progress in the beginning and a
slower refinement period to complete the
project. When the concept was developed,
Lauren’s original idea was to have a
“reverse slinky” style robot that could flip
its body to make it up the stairs. The
original project concept was to include a
second that could carry a ball and have
the two robots work together to make it
up the stairs with the ball. We realized
that physics simply would not let a robot
somersault up stairs, and that was when
the crab-like design was created for the
Stair Climber.
The design required the use of six LEGO
motors for the different joints and for
pure strength. Since each LEGO brick
can only control three motors (without
access to a motoplexor) it was determined that we would need to use two
Mindstorms bricks. The two different
bricks would act as the cooperation
element required for the project.
We decided the most important part of
the task was creating the Stair Climber
and after that was done we would look at
the other robot and the ball situation.
Construction of the Stair Climber went
quickly. There was a strong physical
concept to start with and small modifications were made to help balance and
leverage as we began programming and
saw the actual behavior of the Stair
It took a little while to adapt to using the
Mindstorms program and underestanding the Bluetooth functionality. After that,
the next step was to make sure that the
motors would have enough torque to lift
the heavy bricks into the air. We did
some simple programming tests to make
the robot lift its middle section .
The programming process after that was
a tedious effort to balance the weight
between the front and the back of the
Stair Climber. It was difficult to lift the
front and the back simultaniously
without causing the angle of one leg to
increase to the point where it was too
drastic for the other motors to lift the
body. For example, when the front leg
rests on the stair and is ready to start
the lift, if the back leg is not slightly
elevating the middle section, both joints
located next to body are at greater
Eventually the Stair Climber made it up
one stair. However, this is a “Stair
Climber” robot, not a “Curb Climber”
robot so the next step was to loop the
program so that the robot could go up
multiple stairs. The challenge we
encountered was that the program we
had written did not allow the robot to
reset itself after one step; when it would
loop to go up the next step because it
wasn’t in the exact start position as
before the timing and calculations would
fail to work. We resolved this problem by
adding a few commands at the end of the
program, to kill all the motors and put
both the front and the back legs in their
natural state before looping.
The only other thing that we encountered
was that the Stair Climber for some
reason could not climb three stairs in a
row. At first we thought it was an issue
with the stairs we built, that maybe the
top step was off in measurement, but if
we started the Stair Climber on the
second step it would go up the top step
no problem. We determined that the
motors for some reason could not pull
enough energy from the battery to repeat
the process more than twice. But if we
restarted the program it could repeat the
first two steps again without recharging.
We felt very successful in the completion
of this project. The communication
between the two robots was such a
strong level of cooperation, we were
completely satisfied with how the
concept changed from the original idea.
It was interesting to collaborate with
other people from different majors and
see how differently designers and
computer science majors think. For
example, Lauren would think up different
ways to build the robot with out really
knowing the physics behind it would
work; and Andrew and Chris would push
to complete the path we were on before
veering off to new ideas. It seemed that
while the computer science majors were
confident in making our robot work, the
designer was constantly asking if this
was the best way to make it work. In the
end, it made sense to stick with our
original design; had we veered off to try
different physical designs we would have
had a nice variety of design directions,
but an unlikely chance of having the time
to make any of them complete the task at
hand. Had this been completely a design
exploration project that would have been
a valid process, but being that this
project was also to introduce a behavior
through programming it was important
that we got to that stage. It was a positive
experience for all three group members
each gaining interest and experience in
an unfamiliar area.
If this project were to continue there
would be two directions to take. One
would be to incorporate the second ballcarrying robot, from our original concept,
with the current build; and the other
direction would be to explore further
more efficient ways for the Stair Climber
to work. The final design of our Stair
Climber had to have a specific size of
stair to work, it would be nice to expand
this project to develop a structural model
that could ascend a variety of stair

Similar documents