This line tracking malarky got me intrigued so here's my take on things.
I am assuming a 128 pixel sensor reading zero ( "no line" ) or non-zero ( "line present" ) values into 128 bytes of scratchpad. Because I don't have a sensor I simply fake a sensor reading which I poke into scratchpad. There are a choice of fake readings available ( 'Symbol POSITION' ).
The algorithm scans for left and right edges, those being the first two consecutive pixels set from the left or the right and determines the mid point of the line. If the line is partially off the left of the sensor or off the right of the sensor it makes an adjustment to where it thinks the edges are before calculating the mid point.
The program prints where it thinks the left ("LFT"), middle ("MID") and right ("RGT") points of the lines are. These may be negative or greater than 128. It also calculates an offset ("OFF") of how many pixels to the left ("-") or right ("+") of the centre of the sensor the centre of the line is. The offset can exceed -64 to +64 because it can find lines off the sensor.
And as an added bonus it creates a LED display for seven LED's showing roughly whether the line is across the sensor.
The current code scans in from the right first because I thought that would be easier but, with hindsight, from the left would be easier and simpler. I might update that later. There may also be some off-by-one errors when calculating points when off the sensor, and the LED display could possibly be improved.
The program can be simulated and it seems to take about 7ms to execute on a 28X2 running at 64MHz. That could probably be halved using half the number of sensor pixels. Enjoy.
I am assuming a 128 pixel sensor reading zero ( "no line" ) or non-zero ( "line present" ) values into 128 bytes of scratchpad. Because I don't have a sensor I simply fake a sensor reading which I poke into scratchpad. There are a choice of fake readings available ( 'Symbol POSITION' ).
The algorithm scans for left and right edges, those being the first two consecutive pixels set from the left or the right and determines the mid point of the line. If the line is partially off the left of the sensor or off the right of the sensor it makes an adjustment to where it thinks the edges are before calculating the mid point.
The program prints where it thinks the left ("LFT"), middle ("MID") and right ("RGT") points of the lines are. These may be negative or greater than 128. It also calculates an offset ("OFF") of how many pixels to the left ("-") or right ("+") of the centre of the sensor the centre of the line is. The offset can exceed -64 to +64 because it can find lines off the sensor.
And as an added bonus it creates a LED display for seven LED's showing roughly whether the line is across the sensor.
The current code scans in from the right first because I thought that would be easier but, with hindsight, from the left would be easier and simpler. I might update that later. There may also be some off-by-one errors when calculating points when off the sensor, and the LED display could possibly be improved.
The program can be simulated and it seems to take about 7ms to execute on a 28X2 running at 64MHz. That could probably be halved using half the number of sensor pixels. Enjoy.
Attachments
-
5.1 KB Views: 20