As some of you very well know, I am currently constructing a new Critter. Many of you have questions,
most commonly some variant on "When can I drive it?!!?!" To keep everyone informed, I have created this
page and plan to update it as I make progress.
History
This is just a history of the Critter project and past incarnations. If you're not interested, skip to the next section.
Back around the time I started this website, about 14 years ago, I discovered a project on the internet known
as "Khep on the web". It was a tiny tethered robot that lived in a maze, and you could drive it around.
Obviously the tether limited things, but also greatly simplifed things as well. I decided to see if I could
expand upon that idea such that I could have some type of mobile device that could be driven around my home,
completely wirelessly, and with a wireless onboard camera. After a great deal of experimentation and
false assumptions, thus was born the first RC Car.
The first car was extremely limited. It only had enough battery life for 3 hours of operation, and it took a
good 9 hours to recharge the batteries. I had 2 sets of batteries that I would swap out as needed, but
there was clearly only so much time in the day that it could be operational. It also suffered from other
problems as well. The camera would fuzz out everytime the car moved since the motors caused a significant
voltage drop in the batteries, and the transmitter couldn't operate. There were also annoying dead zones
in my house where either the cam or the car's receiver would lose signal, forcing me to rescue it. There was
also little hope of having any autonomous control or onboard sensors since I didn't have the money or
means to install any type of onboard computer. I looked for options to upgrade.
I eventually found salvation with a monster truck RC Car. Once I stripped all of the upper body off of it,
I was left with a flat platform containing the electronics, and a conveinient surface to mount the camera
and battery. Since this vehicle was much larger, it could handle carrying around a much larger battery.
The 5A 12V gel cell I used could now power the car + camera + transmitter for a total of 21 hours before
needing a recharge. This worked a lot better, but I still suffered from the deadzone issue, and occasionally
had a new problem. The transistors used to supply power to the motor would occasionally blow up for no
apparently good reason. Thus, I was replacing them about once a month, until finally (the day that TechTV
visited of all times), the car's circuity completely died and couldn't be repaired.
Over the years between the first RC car and the next opportunity I had to implement the 3rd vehicle,
embedded computers became a lot cheaper and I eventually discovered the TS-7200 as an optimal solution to
an onboard computer system which could handle both the control of the motors AND video transmission using
802.11b for communication in both directions. Since the computer ran linux, all of the software I was
currently using would easily compile there, and what new code I needed to write would be simple since I was
already familiar with the language and operating system. At first I thought about using the body of the
second RC car, since while the circuity constantly had issues, I was going to gut that part completely and
create my own. However I was unable to interface with the servo that controlled steering, so I sought out
a suitable replacement.
To that end, I discovered the tank. I figured this would be ideal since certainly the treads would enable
it to manuver around the house easily, especially over the room thresholds and such. I used the motor
and gearbox that the tank came with but created my own H-bridge circuit to interface them with the computer,
interfaced a small IP cam with the computer via a crossover cable, and everything was good to go. However,
one thing I didn't realize is that tank treads are about the absolute WORST means of locomotion if you actually
plan on turning on any surface that has almost any amount of friction, such as a carpet or even a linolium floor. It makes sense now that I think about it, but it was an unexpected complication at the time. Despite
this shortcoming, it worked pretty well for a while, but the treads had a horrible habit of breaking. I
eventually located a source of replacement treads, but found that replacing them frequently was tedious and
annoying, to say the least.
I eventually came to the unfortunate but reasonable conclusion that I wasn't going to find what I wanted if I
conintued to attempt to modify toys. Toys are designed for a specific purpose, in a specific environment, for
a specific expected lifespan. They aren't made to last forever, and nobody really expects them to. Nor are
they designed to handle a great deal of extra weight over and above what they were designed for. I finally
determined that if I was going to have what I wanted, I was going to have to build it myself.
Thus began the Critter project. I figured, since I was building this from scratch, and I was going to be
investing a signficant amount of time and money on the project, I might as well consider future commercial
possibilities, even if they're somewhat unrealistic. I envisioned perhaps that the shell of the final unit
would resemble a cute mouse-like creature that could be sold as a somewhat expensive toy. As a placeholder
with that purpose in mind, I called it the Critter. I will likely name it something else later, but it has
stuck for now. The goal with this project is to create a robot that can carry a decent amount of weight
(10-15 pounds), manuver over all surfaces in my house (including room thresholds), have sufficient sensors
to prevent and/or manage collisions, and have the capacity to support various degrees of autonomy.
The first stage was intended to be simple and provide a platform to research the other objectives. I
designed it with 4 wheels, two wheels on each side with individual motors. Although it used differential
drive for motion and steering, the same way tank steering operates, I had hoped that the reduced surface
area would avoid much of the friction involved with spinning, and to some degree it did, but the motors
simply didn't have enough power to overcome what friction WAS present. Also, the motors were not powerful enough and the wheels were too small, meaning that when I removed two wheels and replaced them with casters, the
critter wouldn't drive straight and didn't have enough power to clear the thresholds. There were also some
shortcomings with the control circuity as it was possible (especially during startup) to have all of the
transistors active at once, causing a short circuit. The TS-7200 also requires a regulated 5V power supply
and I was using a linear regulator off of the 12V battery so about 60% of my power was wasted.
Stage 2
Stage 2 is what I'm working on now. It still uses the same computer, but has some significant changes
otherwise. I've built the platform using an aluminum frame with plexiglass surfaces, offset by standoffs.
This is SOMEWHAT frail.. the plexiglass has a tendancy to crack easily, but so long as collisions can be
prevented this shouldn't cause any problems. I've gone with a 2 wheel + 1 caster drive system layout. This
time, the motors have significantly higher torque (but move slower), and I've increased the wheel diameter
by 2 inches. This provides more stability and greatly assists climbing over the thresholds (although I still
have a problem with slipping on the smoother surfaces). Spinning is no longer an issue; it works equally
well on all surfaces.
It is almost ready for public use, but a few items remain to be completed before I can release it to everyone.
They are the following:
Whiskers need to be installed across the front surface. These are limit switches that when closed will
command the critter to immediately brake. This will stop the critter from impacting any large objects.
A series of pushbutton contact switches across the front will work in tandem with the whiskers to also
detect a collision and stop the critter.
IR proximity sensors will be installed on all 4 sides of the critter to detect the presence of any objects
within 6 inches of the critter. A sensor will prevent the critter from moving toward a detected object
and will also allow for wall following techniques. To build these sensors, I need to obtain several
IR LEDS and phototransistors.
A rangefinder array mounted on a servo will map out the area with a radius of 4 feet in front and to the sides
of the critter to determine if any objects are in the path and will resist movement within 12 inches of any
obstacles. This will also be intregal for SLAM and other mapping features.
A third level needs to be installed that will prevent damage to the rangefinder array and circuity should
anyone attempt to drive under something. Proximity and contact sensors will also be installed on this level
to further prevent collisions. To do this, I need to obtain another plexiglass sheet and additional
standoffs.
A variety of software needs to be written to utilize the various sensors. In addition, some functions to
monitor trends will need to be implmented. People who involve the critter in a greater than acceptable
number of collisions or other dangerous activity will have their access to the critter denied. The sad
fact of the matter is that in the past a great many people have chosen to intentionally treat the critter
and rc cars in the most abusive way possible. This causes unnecessary damage that results in downtime and
increased cost. When the critter is offline or dead due to damage, it denies others the experience of playing
with it. This will no longer be tolerated.
|
Parallel Port Pinout
|