![]() |
Swerve VI based on the 2011 paper & excel by Ether
5 Attachment(s)
So I wanted to do the math in this paper/spreadsheet: http://www.chiefdelphi.com/media/papers/2426 in LabVIEW but some of the output values don't match up to the spreadsheet, and only when I try to add in a non-zero clockwise rotation input. I based the calculations on the paper: http://www.chiefdelphi.com/media/papers/download/3028.
|
Re: Swerve VI based on the 2011 paper & excel by Ether
Quote:
Clipping the wheel speeds makes them no longer kinematically correct. See the discussion of normalization on page 2 of this doc. |
Re: Swerve VI based on the 2011 paper & excel by Ether
You are running a lot of calculations in parallel. Some rely on others. You may want to double check that.
|
Re: Swerve VI based on the 2011 paper & excel by Ether
2 Attachment(s)
Quote:
|
Re: Swerve VI based on the 2011 paper & excel by Ether
1 Attachment(s)
Thank you Ether. I updated it as shown. It's outputs are concurrent with those of the spreadsheet. However now adding a gyro angle seems to produce incorrect values. I would expect gyro angle 180 and FWD +1 (STR and RCW are 0) to produce a wheel angle of 180 not 126.76. I would also expect gyro angle of 179 to produce something close to that instead of -175.94 for wheel angles if this LabVIEW implementation were correct.
Also the values are computed in order, that is to say that if D is equal to C*Pi and C = A*B it will wait to get A & B compute C, compute C*Pi then give D. Nothing happens with D until everything it is dependant on happens. Or that's what I observed at least. |
Re: Swerve VI based on the 2011 paper & excel by Ether
Ether's worry about clipping vs. normalization is valid, and you do need to correct your code to handle it properly, but I don't think the input values you're testing would cause an issue in this particular case.
Quote:
Your first task in correcting the VI is to eliminate all local variables. Let LabVIEW do what it does best. Instead of storing a value in "A" somewhere and reading "A" elsewhere, just run a wire from the source to the destination. You can -- and should -- wire a single source to multiple destinations. Then you can implement the necessary normalization. It's a lot easier than you're making it look, and it's even easier in LabVIEW than the C code implies. Finally, you can do some serious optimization of the math. There's no need to have four copies each of "180" and "π" when converting from radians to degrees. You can just do the 180/π division once and multiply each angle by that result. |
Re: Swerve VI based on the 2011 paper & excel by Ether
From my knowledge of LabVIEW, I think it's pretty much impossible to be sure of the order of the calculations will happen.
You should try to do it without the variables. |
Re: Swerve VI based on the 2011 paper & excel by Ether
I admit the locals were mainly to help me understand it better while I was writing it the first time and are clearly slower than wiring it. I also think it looked a tad cleaner. As for the execution, I get the same values either way. That said I thought things waited for their dependencies after watching it run while "Highlight Execution" was on and all the values looked like they updated after their dependencies did. Though I shouldn't have assumed.
|
Re: Swerve VI based on the 2011 paper & excel by Ether
Quote:
|
Re: Swerve VI based on the 2011 paper & excel by Ether
Just a quick comment on the difference between variables and wires.
A wire transfers a data value with sequencing. Variables transfer a data value without sequencing. Another way to think of this is that wires do not have a value until they are written to. Once written to, the wire will propagate the value to all consumers, retaining it as long as necessary for the consumer to begin execution -- at which point it no longer has a value. Variables, global and local alike, have a value at all times. Before being written to, they have a default value. There is no waiting or sequencing. They always return their current value. Another difference is that a wire can have only one writer and all other connections must be readers. Variables may have many writers, many readers. Multiple writers and lack of expected sequencing are the cause of race conditions in parallel programming. Wires have neither of these issues. As for determining the order of execution of code such as this. Since these are simple expressions, the LV clumping algorithm will turn each section of code into a series of instructions, there is no need for data flow scheduling for simple operations. Likewise, there are no loops, no asynchronous operations that would benefit from multiple cores. So the compiler will arbitrarily determine an order and the end result will be the same each time ... until the code is regenerated. Since you didn't specify any preference, the compiler is free to reorder the code according to memory optimizations, cache alignment, order that the code was written in, or phase of the moon. Hope this helps. Greg McKaskle |
Re: Swerve VI based on the 2011 paper & excel by Ether
Quote:
If so, here are the intermediate values you should be getting. This may help you track down where the error is: Code:
L=24 W=24Quote:
Code:
L=24 W=24* note the last paragraph in the paper where reversing wheel speeds is discussed |
Re: Swerve VI based on the 2011 paper & excel by Ether
If you posted your code as VIs or VI Snippets, it would be much easier for people to help. Code (of any type) is hard to debug visually.
|
Re: Swerve VI based on the 2011 paper & excel by Ether
Quote:
VIs: No. Cannot view them without LabVIEW installed. |
Re: Swerve VI based on the 2011 paper & excel by Ether
Quote:
Also do formula nodes execute faster than the equivalent code on the block diagram? |
Re: Swerve VI based on the 2011 paper & excel by Ether
When you get this working the next step is to determine the shortest path to turn including a change of drive rotation. You will need a working prototype to Do the steering pids. We have so far not closed the loop for drive velocity.
|
| All times are GMT -5. The time now is 02:50. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi