Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   SRX Motion Profiling Control (http://www.chiefdelphi.com/forums/showthread.php?t=154617)

Ty Tremblay 02-02-2017 12:52

SRX Motion Profiling Control
 
In this example, and in the documentation, we're told that we should run

Code:

_talon.processMotionProfileBuffer();
about twice as fast as the duration of our trajectory points.

I'm just curious why this is implemented this way. If I'm running a trajectory point every 20ms, why do I need to tell the Talon to process its points every 10ms?

I'm not asking about the timing, but more why the talon needs to be notified instead of processing the buffer on its own. I'm sure I'm missing something, but I would have expected to be able to tell the Talon to start processing its buffer, and then check to see if it's done.

notmattlythgoe 02-02-2017 12:54

Re: SRX Motion Profiling Control
 
Quote:

Originally Posted by Ty Tremblay (Post 1639482)
In this example, and in the documentation, we're told that we should run

Code:

_talon.processMotionProfileBuffer();
about twice as fast as the duration of our trajectory points.

I'm just curious why this is implemented this way. If I'm running a trajectory point every 20ms, why do I need to tell the Talon to process its points every 10ms?

I'm not asking about the timing, but more why the talon needs to be notified instead of processing the buffer on its own. I'm sure I'm missing something, but I would have expected to be able to tell the Talon to start processing its buffer, and then check to see if it's done.

Why I gotta tell the talon to do the thing?

Tyler Scheuble 02-02-2017 15:55

Re: SRX Motion Profiling Control
 
Good question... I would love to know the answer for this as well.

ozrien 02-02-2017 16:52

Re: SRX Motion Profiling Control
 
We could have baked in a thread task into the CANTalon class, but I thought this would be a simple way to ensure there are no reentrancy or other thread-related issues without requiring much more testing/complexity.

I also did not want teams scapegoating a talon thread as the reason why their heavily threaded FRC program is not working or why their CPU utilization is high.

Additionally we did not want to assume what the correct frequency to call was, however the function itself is pretty fast (does not considerably block).

This could change in the future. I figured only advanced users would use motion-profile, and most users would use motion-magic since you don't need to create a profile by hand (instead you set PIDF gains and cruisevel/accel to quickly get motion control).

Ty Tremblay 02-02-2017 17:06

Re: SRX Motion Profiling Control
 
Quote:

Originally Posted by ozrien (Post 1639614)
We could have baked in a thread task into the CANTalon class, but I thought this would be a simple way to ensure there are no reentrancy or other thread-related issues without requiring much more testing/complexity.

I also did not want teams scapegoating a talon thread as the reason why their heavily threaded FRC program is not working or why their CPU utilization is high.

Additionally we did not want to assume what the correct frequency to call was, however the function itself is pretty fast (does not considerably block).

This could change in the future. I figured only advanced users would use motion-profile, and most users would use motion-magic since you don't need to create a profile by hand (instead you set PIDF gains and cruisevel/accel to quickly get motion control).

Thanks for the quick reply. Would this even have to be baked into the class? Would it be possible to do this logic entirely on the talon? Maybe then the API would be something like:
Code:

_talon.setMotionProfileUpdateRate(int ms)  //tells the talon how frequently to process its motion profile buffer.

_talon.startProcessingMotionProfile() //tells the talon to start processing its motion profile buffer.

Then we could use _talon.getMotionProfileStatus(_status); to determine if the MP has finished running.

One of the Talon's greatest advantages is the parallel processing it brings to FRC. If I could give a talon a MP, tell it to follow it, and check back in to determine when its done, I'd be sooooo happy.

kylelanman 02-02-2017 17:15

Re: SRX Motion Profiling Control
 
Quote:

Originally Posted by Ty Tremblay (Post 1639620)
T
Code:

_talon.setMotionProfileUpdateRate(int ms)  //tells the talon how frequently to process its motion profile buffer.

_talon.startProcessingMotionProfile() //tells the talon to start processing its motion profile buffer.

Then we could use _talon.getMotionProfileStatus(_status); to determine if the MP has finished running.

Why not just calculate the rate by dividing the delta time on the points in the profile by 2? Most users will get it right but why make them supply a value that could be determined automatically.

ozrien 02-02-2017 17:47

Re: SRX Motion Profiling Control
 
Quote:

One of the Talon's greatest advantages is the parallel processing it brings to FRC. If I could give a talon a MP, tell it to follow it, and check back in to determine when its done, I'd be sooooo happy.
That is how it works. But if your MP is large then it can't be sent all at once. Instead it has to be streamed into the Talon as it executes, granted there is buffering in all the spots you would expect. The process function manages this periodically.


All times are GMT -5. The time now is 07:06.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi