ceptimus wrote: »
Aren't the 'tires' just O-rings?
I've been reverse engineering the D2-6 (the fancy one with the STC15W201S microcontroller and the Bluetooth interface). The micro runs 8051 code that can be compiled using SDCC which, unlike the Keil compiler, is licence-free. I don't have access to the original code, but once I've worked out exactly what it does, I shall reprogram it for better line-following performance. It's easy to reprogram the chip once you have a hex file: you just use the free stcgal program and a serial interface (FTDI or similar). I'll post links to my source code and resulting hex files if and when I've improved the robot's performance.
With the standard firmware, the line following mode just does full-speed forward on both motors, and then full-speed reverse on one of them when a sensor sees the edge of the line. But the Bluetooth-steered mode uses PWM control of the motors. The PWM runs at a frequency of 427 Hz. The Bluetooth outputs serial to the micro at 9600,N,8,1 The commands are just individual bytes, with a weird encoding format as follows:
Byte Function0 All stop1-19 Ignored20-31 Forward slow->fast32-35 Ignored36-47 Reverse slow->fast48-51 Ignored52-63 Spinning on the spot, to the left slow->fast64-67 Ignored68-79 Spinning on the spot, to the right slow->fast80-83 Ignored84-95 Fast forward turn to the left gentle->hard96-99 Ignored100-111 Fast forward turn to the right gentle->hard112-115 Ignored116-127 Fast reversing turn to the left gentle->hard128-131 Ignored132-143 Fast reversing turn to the right gentle->hard144-255 Ignored
0 All stop
20-31 Forward slow->fast
36-47 Reverse slow->fast
52-63 Spinning on the spot, to the left slow->fast
68-79 Spinning on the spot, to the right slow->fast
84-95 Fast forward turn to the left gentle->hard
100-111 Fast forward turn to the right gentle->hard
116-127 Fast reversing turn to the left gentle->hard
132-143 Fast reversing turn to the right gentle->hard
Line following using PWM control should be much faster than the naiive 'forward or reverse' mode. Time will tell...
Great sleuthing, ceptimus! I also did some work on the D2-6 a while back. Its line following abilities are actually worse than the cheap D2-1 BECAUSE it uses its H-bridge to reverse:
I replaced the processor (vs your clever reprogramming it) and had some fun:
Here's a demo of the stock unit:
I've decided to write my own Android app to send commands to the car in (what I think is) a more sensible format. It will still send single-byte commands. 4-bits of x-axis using the range -7 to +7, and 4-bits of y-axis in the same format. This uses 225 (15x15) patterns from the available 256, leaving 31 bytes for 'special functions'.
When either the x-axis or y-axis is 8 (binary 1000) (which is not used for the range -7 to +7) then the other axis can hold one of 15 codes, plus there is 1 extra code where both the x and y-axis hold the special binary 1000 pattern.
An obvious choice for one of the special codes will be to instruct the robot to perform an erco figure-8 challenge manoeuvre.
I'm not sure how well the robot will be able to do a figure-8 without some encoder feedback from the wheels (or their motors); I suspect not very well. A hardware upgrade would be to add some sensors to optically detect the passing of the four holes that are present in each of the wheel drive gears. The microcontroller has only one spare input, but another I/O could be stolen by deleting one of the two LEDs at the rear of the robot, which are currently only really used to indicate 'operating mode'. The operating mode could be indicated just as well by a single flashing LED: e.g. flash-flash-flash-pause for mode 3.