Status on the New Critter

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