Trajectory Following

[joecaraccio]

https://daltz-private.readthedocs.io/en/patch-20/docs/software/wpilib-tools/path-planning/index.html

Will,

Today you mentioned some characteristic or measurement we were missing from the encoders that you couldn't find on the data sheet that you needed in order to run the path following systems..

Do you remeber what that was? I am guessing you saw it used in some sample code somewhere.

I didn't realize wpilib pretty much pulled in 254s path following code. This looks fantastic.. we should use it, would allow for more time fine tuning other elements

[joecaraccio]

https://www.youtube.com/watch?v=DxY1PTTtRDI

Here is a example coming out of what trajectory falling on the high end enables

[ajwharton]

Their launcher flywheel didn't seem to suffer any velocity loss even when sustained firing.

On Mon, Feb 17, 2020 at 11:04 AM Joe Caraccio notifications@github.com wrote:

https://www.youtube.com/watch?v=DxY1PTTtRDI

Here is a example coming out of what trajectory falling on the high end enables

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Team138Entropy/Entropy2020/issues/95?email_source=notifications&email_token=ABIDEB4T5EVRG4674NUVSOTRDKYQRA5CNFSM4KSG3LS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL65UPY#issuecomment-587061823, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDEBYLBEM3KGG5RZRS5GTRDKYQRANCNFSM4KSG3LSQ .

-- andrew

[Nick-P-Orr]

Definitely something we should try to investigate - our time between shots with the turret mounted on the practice bot is about ~1.5 seconds (not sure about the competition shooter though).

Tough to tell what may be different though, but I also dont know if their design could shoot full field. They could have a couple motors powering their shooter so the torque is increased and drop in speed is less significant (this may also give them more room with PID tuning if they dont need to run their motors at full speed to make the shot?). Could also be a flywheel design? Tough to say but definitely something we should look into once auto and turret aiming is done.

[ajwharton]

Yeah, they were definitely closer to the target. Torque would help, but we ran into that 100ms sample problem trying to tune the PID to be more reactive to the velocity loss after a shot.

On Mon, Feb 17, 2020 at 12:12 PM Nick Orr notifications@github.com wrote:

Definitely something we should try to investigate - our time between shots with the turret mounted to the practice bot is about ~1.5 seconds (not sure about the competition shooter though).

Tough to tell what may be different though, but I also dont know if their design could shoot full field. They could have a couple motors powering their shooter so the torque is increased and drop in speed is less significant (this may also give them more room with PID tuning if they dont need to run their motors at full speed to make the shot?). Could also be a flywheel design? Tough to say but definitely something we should look into once auto and turret aiming is done.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Team138Entropy/Entropy2020/issues/95?email_source=notifications&email_token=ABIDEB4MYAV3WR2UTII7LU3RDLARTA5CNFSM4KSG3LS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7EKUY#issuecomment-587089235, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDEBZBUDUQOFGXPQMI2S3RDLARTANCNFSM4KSG3LSQ .

-- andrew

[joecaraccio]

@ajwharton was this when we were tuning the PID up front? But yeah, this is an Einstein team (final tournament contenders)

I want to say we saw better than 1.5 second recovery time on velocity.. but I could be wrong.

The other thing though is at this range we probably don't need to regain the much velocity. I'd be willing to bet there is a wide range of shots that would work (that close). Whole different ball game 40 feet away

[maxh65000]

My understanding was that the encoder is sampled every 20ms but it was in units of encoder ticks per 100ms (Example: a speedometer doesn't sample every 1 hour). But correct me if I'm wrong.

[maxh65000]

We do need to tune the PID, however. We are only using the P constant anyway.

[joecaraccio]

@maxh65000 Close. We actually haven't looked into this a ton. You are right that its units are 100ms. But it actually looks like we could drop the sampling period as low as 1 ms. But it does default at 100 milliseconds. It also supports 20 Milliseconds.

Towards the bottom of this page it goes into these sampling rates https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html

We could definitely improve performance

[ajwharton]

Oh great. We definitely should adjust that rate to something lower than 100ms. Probably 20ms would give us the resolution needed.

On Mon, Feb 17, 2020 at 1:17 PM Joe Caraccio notifications@github.com wrote:

@maxh65000 https://github.com/maxh65000 Close. We actually haven't looked into this a ton. You are right that its units are 100ms. But it actually looks like we could drop the sampling period as low as 1 ms. But it does default at 100 milliseconds. It also supports 20 Milliseconds.

Towards the bottom of this page it goes into these sampling rates https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html

We could definitely improve performance

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Team138Entropy/Entropy2020/issues/95?email_source=notifications&email_token=ABIDEB56DOJEK6EBAPYPUD3RDLIFLA5CNFSM4KSG3LS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7JNPY#issuecomment-587110079, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDEB42J63CHO6P7L4UHWLRDLIFLANCNFSM4KSG3LSQ .

-- andrew

[Nick-P-Orr]

@joecaraccio Just was looking that up as well and noticed there seems to be ways to change the "velocitymeasurementwindow" and "velocitymeasurementperiod" for velocity with the phoenix api. Also the 1.5s is just off the practice bot, the competition setup may be quicker, I just can't remember now.

I'm not really too familiar with the PID stuff, I haven't looked into it much so its a bit over my head, but when we were testing the competition shooter, we sampled current + velocity . The part I'm mostly not understanding is why current isn't being set to the max when there is a velocity drop (wouldn't the ideal situation be to feed the max current when the gap in desired velocity is big enough), but is instead kinda on a ramp up. I can pass the google sheet we were marking this stuff down on along, but I attached an image of a small part of it below. (The goal was around 3090 ticks, so its just kinda surprising you'd already start to see less current being supplied at 300).

[joecaraccio]

My guess is the talon was making decisions as to how much current it needed to reach its goal velocity. It might be gated by max's and mins ... so we can probably play with that. We can also tune the PID so we overshoot our goal, and then come back down.. the penalties for being under velocity are worse than if were are slightly over velocity.

I'm also wondering if there are drawbacks of shorter polling periods.. probably accuracy although it takes a rolling average

[joecaraccio]

People on Chief Delphi recommend decreasing the amount of filtering on the Talon's velocity measurement, by decreasing the number of samples in the velocity average and by decreasing the measurement window.

they claim it'll make the proportional gain substantially larger. Lets try this on the robot tonight @Nick-P-Orr @maxh65000 @ajwharton