DPRG mailing list archives: [DPRG] progress on Hough transform and small robot

Tue Jan 30 06:12:38 CST 2007

Hello,

Here is a picture of the top and bottom sides of the circuit board for the 
RC toy I am hacking.

http://golem5.org/embedcv/images/rctoy_circuit.jpg

The major functional areas are identified (although there are no details 
for the radio). Ed's datasheet is accurate as it is for this part. But 
this datasheet for a later generation version of the RC toy controller ICs 
has sample application circuits so was also very helpful.

http://www.mobicon.com/image/data/_TX2C%20ATS302TRX2C%20ATS302R%20Datasheet(English%20V1.02).pdf

The backward and forward functions are implemented with an H-bridge using 
three BJTs in parallel for increased current drive. Turbo supplies 
additional current to the M+ motor terminal (forwards direction) using 
another three transistors. As Ed warned, there is no built in safety to 
prevent shoot-through conditions. By design, they just never happen.

Steering is somewhat complicated. It really confused me until I started 
drawing a picture. It is a H-bridge but with some kind of latching around 
it (i.e. limit switches - this is not a servo of course but something more 
primitive). The steering actuator is in a box with a total of seven wires 
coming out of it:

ML  - motor left
MR  - motor right
A   - square pulses from ground to positive
D   - held around 6 volts (RC drops and spikes come with motor movement)
B   - ?
C   - tied to ground
GND - same as power ground

ML, MR, and GND go straight to motor terminals. A, D, B, C go to a small 
PCB which indicate armature position. I am afraid to take this little box 
apart so I don't really know how it works inside.

One interesting thing is that those three big diodes in the lower right 
corner are for dropping battery voltage to the top of the H-bridges. There 
are no flyback voltage diodes that I can see. The "turbo" bypasses these 
diodes for forward driving.

Chris

On Sun, 21 Jan 2007, Ed Paradis wrote:

> Chris,
>
> I sent this to you off-list, but here's the link for everyone to enjoy
> to the datasheet for the RX-2 (and its companion, TX-2) chip.  This
> chip is _very_ common in toy RC cars.  They're neat little chips
> really.
>
> http://www.edparadis.com/txrx2.pdf
>
> The chip handles most the RF and all of the decoding.  As outputs it
> has N output lines that go high to signal each of N functions.  The
> one car I took apart that had proportional steering did so by
> modulation the transmitted signal, so that the receiver circuit was
> the same as if the car only had 'all left, all right' steering.
>
> For robot hacking, I built a little set of logic gates to allow for
> local control or for (human) remote control.  (It has no native way of
> preventing you from turning on both sides of the H-Bridge other than
> that the transmitter doesn't send both those signals at once.)
>
> You could also just rip the chip out and drive the lines from any
> digital output pin.  You could also simply cut the legs off the lines
> you want to control, and solder to the board.
>
> I have to agree with you about off-the-shelf parts regarding chassis.
> I have found it very frustrating to build the same conceptual
> "chassis-wheels-motors" pattern over and over.  I run out of steam
> before getting much further than adding an Hbridge and a single sensor
> to the robot.
>
> I don't know how much the new Roomba platform is going for, but the
> hundred bucks or so Michael dumped into the hacked version we did was
> definitely worth it.  I suspect we'd have gotten much further on that
> bot if we'd not turned our attention towards autonomous sinking
> things.
>
> Ed
>
> On 1/21/07, Chris Jang <cjang at ix.netcom.com> wrote:
>> Hello,
>> 
>> The basic Hough transform code works but is even less reliable than the
>> object recognition of soda and beer cans. It needs work.
>> 
>> http://golem5.org/embedcv/images/hough.jpg
>> 
>> The bright points in the Hough transform image correspond to the detected
>> red lines in the (histogram equalized) edge image.
>> 
>> One thing I've noticed in real world images is that horizontal edges tend
>> to be much stronger than vertical or diagonal orientations. My theory is
>> that this is an optical effect. Horizontal edges tend to remain within the
>> camera's depth of field under even lighting.
>> 
>> I'm also starting to think that thresholding the Hough transform of a
>> Sobel edge image is too difficult. The algorithm is very sensitive to
>> noise and does not reject it very well. Better edge detection than vanilla
>> linear convolution is required.
>> 
>> Another thing I'm going to do is test EmbedCV on a 1/12 scale RC car. Here
>> is a picture of it.
>> 
>> http://golem5.org/embedcv/images/littlebro.jpg
>> 
>> It cost $15 (unsold Christmas product) and has full suspension (not much
>> travel but all four wheels are sprung) and a rear differential. There is
>> no PWM and steering is full deflection bang-bang. The wheels are rubber.
>> It is just wide enough that a PC 104 SBC can fit inside the body. I'm
>> thinking of the Technologic TS-7260 ARM9 board. The battery pack voltage
>> is stable enough that I think everything can run off the same pack without
>> isolation between the motor drive and digital electronics. A notebook
>> webcam attached to the roof provides a camera.
>> 
>> This toy is small enough to fit in a shoebox and so can run on the DPRG
>> warehouse course area. It's big brother is about 10x heavier and barely
>> fits in the trunk of my car. I have not been able to make much progress
>> with it as the logistics of testing are involved. I'm hoping that less is
>> more and this smaller robot allows for accelerated development.
>> 
>> One thing that amazes me is how much faster buying off-the-shelf is. It
>> took months to build a frame, drivetrain, motor control electronics and
>> electronics enclosure for the big robot. If it proves easy to hack the
>> motor control of this toy and all electronics can just be stuffed inside
>> it, then there's easily an order of magnitude improvement in development
>> time. This isn't quite true - cost has been shifted from hardware to
>> software. I've been working on EmbedCV for several months and it is still
>> far from working on a robot. If this works, it may be a better time/money
>> tradeoff for many people who wish to build robots - COTS vehicle platforms
>> with 32 bit embedded computers and more advanced signal processing for
>> sensing the environment.
>> 
>> My theory is that PWM speed control added to the rear drive is enough that
>> bang-bang steering is ok. I think that driving in smooth curves is
>> somewhat difficult. Most robots drive in straight lines. They only turn
>> when pointed in the wrong direction. That's how I'm viewing this robot.
>> When turning, it can just slow down so the vision and control system can
>> keep up with the angular rate of turn. Then once pointed in the right
>> direction, it can increase speed.
>> 
>> Here's a better photograph of the electronics board inside the toy.
>> 
>> http://golem5.org/embedcv/images/img3868.jpg
>> 
>> If anyone has some experience regarding hacking this kind of thing, I
>> would appreciate your advice. I plan on using the DIO lines (appropriately
>> level shifted and buffered) from the ARM9 SBC to tap into the existing RC
>> circuits and control the car. I'd like to leave the radio receiver
>> electronics in place too. Right now, I am thinking absolutely minimal
>> modification.
>> 
>> Some things I recognize. Those three big diodes must be for motor flyback
>> voltage. There's a coil and IC for the radio. Does anyone know what that
>> company insignia is? Where can I find a datasheet? There are a whole bunch
>> of bipolar transistors for motor control. I didn't expect this many. I'll
>> reverse-engineer and diagram the circuit soon.
>> 
>> Chris
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at dprg.org
>> http://list.dprg.org/mailman/listinfo/dprglist
>> 
>