Line tracking algorithm

[Per Jakobsen]

Hi Pixy-folks

I'm developing a line tracking algorithm for a Robot competition (next week...), and I could use a little guidance.
I've poured through wiki, forum and this group to find info, and with good success! - Thanks all!

Situation:
1) I have managed to compile standard firmware with LPCXpresso, and it seems to work fine on the Pixy (at some boots the LED does not switch off again, and the software does not detect the Pixy, but it's quite seldom, so I'll live with that for now).

2) I have developed an algorithm using raw images from the Pixy, and it seems to work ok (I think):

3) I tried to copy the cccmodule to my own and compile that into Pixymon, but found that cccmodule "stole" all the frames :-) - So now I've started to modify cccmodule instead. I've used printf to see that my code gets called, all ok.

Next:
What I'm aiming for is a "quick'n'dirty" (for now), using the the report-variables for signature 7, as I would like to use the Lego EV3 Pixy-block as is.

I plan to finalize the Pixymon module, and have it report the line-information as a blob, and see the values appear on the screen as if it was a blob (signature 7).

Then on to implement it on the Pixy itself, although I'm a bit in the dark as to how to make the transition from Pixymon-module to Pixy-module.

Any help/hints/guides will be greatly appreciated :-)

~Per

[Rich LeGrand]

Hi Per, 

Sounds like you've made good progress!

Regarding 1, are you sure it's not a hardware issue?  Does the factory firmware not do this?  It's almost as if it's going into firmware upload mode.

Your Algorithm example looks pretty awesome!  Embedding the algorithm in Pixy usually can take one of 2 paths -- one path uses the M0 to grab a frame and the M4 processes it.  The code will look very similar to the module code.  The other path modifies the M0 code to try to do as much pre-processing as possible before handing off to the M4.  This gives you the best performance, but it's a harder road.

Memory is also an issue --- the M4 only has about 30K of heap to work with.  You can also post your code or send it to me (ri...@charmedlabs.com) for some ideas on how to embed.

best,

--rich    

--
You received this message because you are subscribed to the Google Groups "pixy_firmware_sdk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pixy_firmware_...@googlegroups.com.
To post to this group, send email to pixy_fir...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pixy_firmware_sdk/e9e6e2d8-b0cd-4602-95ce-a31255d2a218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Charmed Labs
www.charmedlabs.com

[Per Jakobsen]

Hi Rich,

Thank you very much for your reply.

I have two Pixy's so I can probably test hardware and firmware stability during the weekend.

The algorithm uses knowledge of the expected line width, compensated for distance. This removes quite a bit of noise.
On each scanline it scans for an edge above a certain threshold (across 4 pixels), notes its polarity, and then searches for another edge with opposite polarity within the expected distance further along the scanline.

Yesterday I went to the competition track taking hundred-odd images with the Pixy, so tonight I will run them through the algorithm to see how well/bad it performs at that location.

I'll come back with more when I had a chance to look at the stuff again :)

~Per

[Per Jakobsen]

Hi again,

processing of the images from the track looks very promising, so I think I'm on the right track, so to speak :)

Looking at the algorithm implementation, I was looking at available processing power, and have become confused...
In the wiki it states that there are 24 clocks available per pixel.
Provided that the LPC4330 uses single cycle instructions @ 208MHz, running with 320x200 @25Hz, there should be 130 cycle per pixel.
Or are some of these clocks being used for something else?

~Per

[Rich LeGrand]

Hi Per, I'm not sure where you are getting 130 clocks per pixel.  The numbers on the wiki have to do with how fast the imager clocks out pixels on a given scan line.  There is also horizontal and vertical blanking intervals where no pixels are being clocked out.  These intervals take up much of the frame period --- close to 30%.  At any rate, I think 12 clocks per pixel at 640x400 is a good workable number if you want to write custom M0 code.  That's what Pixy uses when doing it's color connected components. 

--rich

  

To view this discussion on the web visit https://groups.google.com/d/msgid/pixy_firmware_sdk/7ac8712c-1f5b-4fd7-88f5-b81aac70aa43%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Charmed Labs
www.charmedlabs.com

[Per Jakobsen]

Hi Rich,

I simply took 208Mips divided by 320x200 pixels @25Hz (1.6Mpixel/s) = 130 instructions/pixel, but that does not take into account any blanking of course.

Can the camera be set to operate at 320x200 pixels instead? - Plenty for line tracking, and will give 42 cycles per pixel.

~Per

[Per Jakobsen]

Ehh, 48 clocks/pixel...