June 15, 2003 -- dlg
n01.jpg - This picture shows the robot's main frame. The two shafts which
project from either side of the lower frame are the drive wheel axles. The
wheels mount on the projecting shafts, and on the other end are the pulleys
which connect by belts to the motors mounted higher up. Just below the
motors, the pulleys mounted on the optical encoders are visible. This was
an experiment since these encoders are tied directly to the wheel movement,
and only indirectly to the motors (ie through the gearbox). This is ideal
for odometery, but it was not clear how well it would work for motor control.
So far, there has been no problem running the PID speed controller from this
sensor setup. There are 597 encoder ticks per wheel revolution or just over
41 per inch. The other devices visible as a black rectangle just under the
motors are Sharp IR ranging sensors. The motors are surplus Pittman 19.2v DC
items with attached gearbox (I'm not sure about the gear ratio).
n02.jpg - These are the components which are assembled to make the caster
wheel. The large shaft on the caster assembly fits though the big hole in
the end of the right angle frame and is held my a set screw. Another IR
ranging sensor is mounted dead center on the frame.
n03.jpg - Here are the two pieces from the n02.jpg photo put together and shown
from the top side. The four holes are used to mount the battery and DC-DC
converter, while the slots are used to bolt the whole thing to the main frame.
n04.jpg - This is the battery assembly comprised of three 6-cell 1800mah NiMH
AA packs clamped between polycarbonate end-plates. Due to the angle of the
picture, you can only see two of the four bolts which fit the the holes
mentioned in the n03.jpg picture description.
n05.jpg - This shows the battery and caster assembly bolted to the main frame.
The bot is lying "face down" in this picture, and still has no drive wheels.
n06.jpg - This is the complete bot mechanical assembly shown upright with
drive wheels mounted from a rear, three-quarter angle view. The metal plate
on top of the batteries is where the DC-DC power converter mounts (which I
am working on at this point). The green omniwheel mounted in the top/front
of the frame is because I expect to be falling down a lot when I try to go
into balancing mode. It is very rugged, and will actually allow the bot to
maneuver reasonably well when it is flat on it's face (which will probably
be much of the time in the early going 8)
n07.jpg - This picture shows the motor controller board with four input buttons
on the bottom. The board is mounted to a 1/4 inch thick aluminum plate visible
between the motor controller and input buttons. The MRM332 cpu board mounts
on the other side of this plate. The sides are made from acrylic pieces that
are fastened via bolts screwed into the sides of the same aluminum plate. One
of the aluminum spacer tubes is shown at top. These tubes have a piece of
10x32 allthread through them which is clamped on each end to make a hopefully
n08.jpg - Here is the view from the other side showing the MRM332 board. The
case is mounted to the frame with the cpu board on the inside. Just visible
at the top are the holes which 10x32 allthread passes through on it's way
through the back frame members. At the bottom is a slot instead of a hole
so the case can be swiveled up and out of the way while still being attached
to the frame. Yes, the cpu reset switch is quite hard to reach with this
n09.jpg - This shows the cpu case mounted to the bot frame with a ruler at the
base for scale. The length is about 10 inches; the wheelbase a little less
and the height a little more. The wheels were contributed from a model R/C
truck, and chosen for their suspension rather than for odometry accuracy.
The caster wheel was an R/C model airplane accessory, and is also air-filled.
This is the first bot I have made that doesn't "clunk around" on hard surfaces
and has at least minimal suspension for running over objects or out of doors.
The shaft projecting up out of the caster assembly mounts a gear to allow
tracking the position of the caster wheel (which I currently do not do, but
it has been useful in previous three-wheeled bots).
n10.jpg - A side view of the largely complete bot (still missing power circuit
and some sensors). In balancing mode, the bot will have the caster wheel off
the surface because the balance point involves shifting the battery weight up
and over the drive wheels (ie tilting forward ~20 degrees). This postion
places the omniwheel well in front of the frame, and hopefully at the point of
first contact most of the time. In other words, standing "still" will have
the bot frame tilted at about a 20 degree angle (rather like a T-rex 8) If it
falls either forward or backward, the bot should still be able to maneuver
even if it cannot get back into balancing mode (or so goes the enchantment).
LMD18200pcb.jpg - this is a picture of the LMD18200 motor controller pc board.
LMD18200-built.jpg - this is the motor controller board after construction.
Update: 04 April 04 - dpa
Robot acquires, follows, and matches the speed of another robot. In this case, dpa's robot, nBot, is navigating around a 5 foot square, and Robot is following.
Here are a couple of videos of the behavior in Duane's kitchen.
low res mpeg (3.2Mb)
hi res mpeg (16 Mb)
The robot is using two Sharp infrared proximity detectors to find the edges of the robot
and lock on to its trajectory. nBot manages to lose it twice by "scraping it off" on
nearby bright, hard, reflective surfaces.
Back to dpa's robots