Ded reackoning VI on differential drive robot - real time very slow

[Rick James 86]

Hi all,

Still getting my head around Labview I am trying to read off differential steering motor encoders and apply ded reackoning equations to determine updated x y and angle of our NIARC robot.  My first attempt I used pi and full trig functions it worked good on my computer however when working on the real time processor it slowed right down possibly due to the size of the calculations. I then revised my code and changed the values of pi to 4 significant figures aswell as develop a look up table for the trig functions however it seemed to go slow through the lookup values.

See attached Vis is there a way i can speed up the processing time or modify the VIs i have developed???  We are using a 9076 compactRIO with a spare slot.  Can a wireless c series module be plugged in and the calculations done on my laptop?? 

Thanks Heaps in advance

Cheers

Rick

[CMal]

Rick,

If you're just trying to calculate the sine or cosine of a number, you can use the built in trig functions that are included with LabVIEW.  In the Functions palette, go to Mathematics >> Elementary & Special Functions >> Trigonometric Functions.  This will be a lot faster than searching through a lookup table.  I would also suggest avoiding the use of local variables when you can use shift registers instead.

If you have acces to the LabVIEW Robotics module, you may want to take a look at this example that shows how to perform dead reckoning with a differential steering robot:

https://decibel.ni.com/content/docs/DOC-17273

Chris M

[Rick James 86]

Thanks Chris,

I can replace the sine and cosine VIs I developed with the sine and cosine math functions.  I initially had the trig functions on it but still had the local variables there I will replace these with shift registers and give it a try. 

Having said that would the local variables be the cause of the slow processing???

Thanks again,

Rick

[CMal]

Hi Rick,

Removing local variables should not have any noticeable effect on the performance of your VI, but it is considered good programming practice to only use them when absolutely necessary.  I took a closer look at your VIs, and I have some thoughs:

• "Cosine Lookup Table.vi" has a while loop with a false constant wired to the stop condition.  This means that this sub VI should run forever without giving the rest of your code a chance to continue execution.  Is this the behavior you are seeing?
• Changing the number of significant figures in the numeric constants will have zero effect on runtime performance, since this does not change the precision of the data.  Even if you were to change the precision, it would not make a significant difference.
• Your zip file is missing "Search 2D array (numeric).vi", so I'm not sure how much it is impacting performance.  In any case, using the built in sine and cosine primitives should be much faster (and more accurate) than using a lookup table.
• Exactly how much of a slowdown are you seeing?  How are you benchmarking the performance?

Chris M

[Rick James 86]

Hi I have modified the original VI and it is now working on real time next problem is this

The dead reackoning formula is as follows

Ran the VI in the highlight execution mode.  and did the following
move one encoder position away from zero in this case it is 38776 counts
let it calculate and found the following change in y was -185, x was -361.
on the next iteration I moved the encoder count back to zero this simulated the robot moving to position A and then back to home position in one count so it could not have travelled anywhere else.
when calculated again it should have done the exact opposite however it kept the change in Y2 as -185.97 and the change in X was as expected 361.85 (the exact opposite)
My VI now thinks the robot has moved back to its origin on the x axis however advanced another -185.97 units in the y direction however this is not the case.

See screenshots of encoder count advance and encoder count withdraw. note reasult of change in Y2 values same in both cases however change in x values are direct opposite as it should be.

The change in angle is also reversed

Any idea whats going on I think it has to do with the trig values in their respective quadrants i.e.
 Sin    |  All   
Tan    |  Cos

I think i need to set some conditions in the calculating of the trig

Thanks Again