Joe Grand's Laser Range Finder--Speed Up

John Abshier · 2011-09-29 11:07

I was disappointed that the time to take a measurement was 1.2 seconds. I started looking at the code. Here is a possible speed up. Tested on a demo board, not the range finder. The code does some byte swapping

repeat index from 0 to (5119)          ' For each long in the buffer...    263 milliseconds
    val := LONG[fbPtr][index]                         ' Read value from memory
    tmp.BYTE[0] := val.BYTE[3]                        ' move Y0 into array location 0
    tmp.BYTE[2] := val.BYTE[1]                        ' move Y1 into array location 2
    LONG[fbPtr][index] := tmp                         ' write long back into main memory

I replaced that with this code

repeat index from 0 to (5119)          ' For each long in the buffer...  
    long[fbPtr][index] <-= 8

Original is 264 milliseconds. Rotate version is 117 milliseconds. Savings of 147 milliseconds.

Attached is an archive of my test code.

John Abshier

Joe Grand · 2011-09-29 11:21

Hi John-

Very cool - I'll add this to my list of optimizations. I'm open to any other suggestions people may find, as well. The beauty of an open-source design is allowing lots of sets of eyes (and brains) to examine the inner workings.

I do have a few ideas on how to increase the camera frame rate (currently at a 2MHz pixel clock), which would decrease the time-per-measurement. The current 1Hz sample rate is OK for certain applications, but the faster the rate, the more potential uses there are!

Take care,

Joe

John Abshier · 2011-09-30 14:15

The attached archive eliminates almost 400 milliseconds from LRFBlobDetection. It eliminates the need to swap the data and partially unrolls the loop to find blobs. A couple of minor speeds ups: replace * 2 and * 4 with << 1 and << 2. In repeat loops replace (g#someConstant -1) with constant(g#someConstant -1). Some time may be saved in the calculation of centroids. Suggested code is between {** and **}.

repeat iy from 0 to (blob[ix * 4 + g#BLOB_RIGHT] - blob[ix * 4 + g#BLOB_LEFT])     ' for each column X within the blob
        {** repeat iy from blob[ix * 4 + g#BLOB_LEFT] to blob[ix * 4 + g#BLOB_RIGHT]  **}
        {** val := roi[iy]  **}
        {**  blob[ix * 4 + g#BLOB_MASS] += val **}
        {**  tmp += iy * val **}
        {**  blob[ix * 4 + g#BLOB_CENTROID] := (tmp / blob[ix * 4 + g#BLOB_MASS]) ** }
        val := roi[(blob[ix * 4 + g#BLOB_LEFT]) + iy]   ' get the current column's sum
        blob[ix * 4 + g#BLOB_MASS] += val               ' add column sum to the total mass of the blob
        tmp += (iy + 1) * val                           ' weighted sum of all positive pixels in the blob

      blob[ix * 4 + g#BLOB_CENTROID] := (tmp / blob[ix * 4 + g#BLOB_MASS]) + blob[ix * 4 + g#BLOB_LEFT] - 1                             ' calculate the true centroid (e.g., where in the blob the weight is centered)

John Abshier

ratronic · 2011-09-30 15:09

@John have you incorporated this in to your range finder, do you really save a third of a second?

John Abshier · 2011-09-30 15:23

No, what I have done is run code snippets, recorded the clock ticks they took and then divided by the clock frequency of the laser range finder. Before I change the default code, I would need to mount the range finder and have some targets at measured distances. I bought it to possibly replace Sharp IR rangefinders for a Dallas Personal Robotics Group contest. Even with the changes I have identified, it is an order of magnitude slower than the Sharps. I should have been working on my robot instead of the range finder, but I was curious.

John Abshier

ratronic · 2011-09-30 15:51

Ok thanks John

Joe Grand · 2011-10-03 09:34

John Abshier wrote: »

The attached archive eliminates almost 400 milliseconds from LRFBlobDetection.

Great! I'll take a look into this. I've also added it to my optimization list and will do some testing (when time permits) on the speed increases. I think these, coupled with some frame grab optimizations, will be a very nice improvement.

Joe

wshust · 2013-08-20 15:11

Any new developments in trying to speed this device up? Alternatively, does anyone know how to get in touch with Aculux sensors of Bellevue, WA? Their website seems inactive. Thanks much, Bill Shust, Nap. IL

Publison · 2013-08-20 15:45

They seem to be in direct competition to the Parallax Range Finder.

Can't help there.

Joe Grand · 2013-08-20 16:12

I may have posted about this a while ago in another thread, but Roy Eltham has modified some of the LRF code to provide a 4x increase in speed (taking the suggestions in this thread and based on his own optimization). We're both trying to find a good time to work on the firmware a little more to verify and validate the changes before pushing something out to the public. It's on our list, but I don't have any particular release date at this point.

Thanks!

Joe

Publison · 2013-08-20 16:25

Publison wrote: »

They seem to be in direct competition to the Parallax Range Finder.

Can't help there.

Just to be correct, I was responding to the Aculux sensors portion of the post, not the speed of the current Parallax product.

BTW, this link works for me:

http://www.aculux.com/Products.htm

Joe Grand's Laser Range Finder--Speed Up

Comments