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

Sun Jan 21 10:06:59 CST 2007

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
>