The project also called for four VXB ball bearings, 16 steel dowel pins (M1, M2, M3), 30 machine screws (M1.5, M2), and one square steel rod.
The whole machininng and casting process is explained in painstaking detail in my guerrilla CNC manufacturing guide, and also illustrated on this Flickr page (an earlier project of mine).
Rear wheels of the robot are joined together with a steel rod, mounted in two low-profile ball bearings (8 x 12 x 3.5 mm), and connected to a 130:1 gearbox that delivers about 40 RPM and 3,000 g/cm of torque, allowing the robot to effortlessly mount most obstacles. Closeup of the rear assembly:
Front wheels have integral ball bearings and rotate freely; a reflective optointerrupter, TLP841, is used to provide traction feedback for the motor, detecting a small white target on the inside of the wheel.
A second motor and a 490:1 gearbox can be found in the front; instead of the usual (and crappy) differential drive system, an oversized gear-based transmission is used to synchronize the turning of front wheels, each of them individually mounted on 3 mm dowel pins. Turn range is +/- 30°. A small slot optointerrupter, OPB609, is used to sense 0°, +/- 15°, and +/- 30° positions marked on the gears:
Gear tooth size is about 0.5 mm, pressure angle is about 18° for initial stages, and 25° for the final stage in the steering assembly. Gearwheel thickness is 1 and 1.75 mm, respectively (see the aforementioned CNC machining guide for a good primer on gear geometry).
Rendered image of the entire body, with the main PCB and the battery installed:
Positive molds machined in RenShape 460 based on CAD models:
Early stages of assembly:
Several hours of work later - all sensors installed, electronics on a breadboard, distance sensor readings displayed:
Completed, turned on, and crying "put me down":
Other images of interest: initial prototype two months ago; and the immediate predecessor to this version (note a different orientation of the motors). If you count these iterations, the project took about 25 hours of work to get to the current stage.
The battery has a nominal voltage of 7.4V (the actual range is 5.6 - 8.5V); this needs to be translated to stable 5V for the motors, sensors, and the microcontroller. To do this, I used Murata OKR-T-3-W12-C, a high efficiency 3A switched regulator. The voltage is set with a 270 Ω resistor; the value needs to be set accurately, so a 500 Ω trim pot may be more practical than shopping for a 1% resistor of this exact value.
An extra 10 µF capacitor across terminals is employed to counter motor inrush currents and the crowbarring tendencies of the H-bridge drivers used, so that the risk of resetting the MCU is minimized.
To avoid damaging Li-poly batteries, care must be taken not to discharge them below about 2.8V per cell (5.6V total). To prevent this, I rely on a MAX8212 voltage monitor, coupled with a medium power p-channel MOSFET transistor (STP12PF06 in this case, but any other rated for at least 3A will do). This serves as an input stage for the regulator; the threshold voltage is adjusted with a 250k resistor. This value also needs to be matched accurately, so a 220k resistor and a 50k trim pot may be a simpler choice.
The complete voltage control circuit looks as follows:
The remainder of the circuit consists of ATmega1284P interfaced to several peripherals:
Not shown on the schematic, the AVR ISP connector is also attached to pins 6-11 of the MCU to allow for easy programming.
The above video shows Tinybot executing a test program; sensor feedback is used to execute movements very precisely.After a couple of functional tests, I proceeded with more useful routines to explore and map out the environment - but ultimately decided that traditional steering limits the ability of the robot to efficiently explore indoor environments without resorting to uninspiring Roomba-like motion patterns. The problem is compounded by the use of EZ4 ultrasonic sensors, which in hindsight have an overly narrow detection pattern; EZ2 sensors appear to be a better fit.
This could be remedied by upgrading the MCU and equipping the platform with a video camera or a larger array of better-suited distance sensors - but ultimately, I decided to move on to a completely different, more agile design - dubbed Omnibot.
Your lucky number: 16201722