This whitepaper is a guide on how to test large mechanisms that can fail easily (like arms or elevators) without breaking them it was built with CTREs Talon SRX motor controllers in mind

Can you explain the math behind the parameter calculations on your updated JVN calculator. I’ve been thinking about how to do something like that for a while, but I have never been able to get something that actually works. I’d love to hear how you did it.

Great first whitepaper-- thanks for putting in the work to thoroughly document your processes and make them public for the community!

One thing I’m curious about is why this whitepaper suggests placing the encoder as close to the motor as possible. The current iteration of encoders in the CTRE ecosystem (http://www.ctr-electronics.com/srx-magnetic-encoder.html) have plenty of resolution (4096 counts per rev). Meanwhile, slop in gearboxes adds up on each reduction and even more if there’s an external chain/belt.

The equations are basically just pages 85-87 of the now-legacy “TALON SRX Software Reference Manual” v1.22. That manual is now replaced with the Phoenix documentation, but I appreciate the presentation of the math in the older manual. The equivalent of the old manuals math is in the definition of the pidf terms located here: https://phoenix-documentation.readthedocs.io/en/latest/ch16_ClosedLoop.html#closed-loop-configs-per-slot-four-slots-available.

If you take the definition of feed forward, and the definition of P, and you do the unit conversions and basic geometry math for the situation represented by the sheet in question, I hope you get an equation similar or equivalent to the equations in the sheet. Feel free to reach out if you would like me to dive into more detail, or if you find any mistakes.

We have found is that the lag between the motor movement and the movement of the encoder causes more problems than the small amount of movement between the intended and actual position. the problems that we have found are not with the resolution of the encoder, but, when using motion magic or motion profiles, having the encoder directly attached to the motor means that the movement of the motor is smoother.

also, on a related note high-reduction final stages in mechanisms tends to greatly reduce apparent slop in the mechanism, as it tends to reduce the impact of the accrued slop roughly proportional to the amount of reduction in the final stage. So, if a final stage has a 3:1 reduction, slop will roughly be 1/3 as much as the equivalent 1:1 stage.

Great paper and resource for teams. Thanks for releasing this.

We would be delighted to hear about anyone’s success our failure stories if teams do attempt to use the spreadsheet to calculate pidf values. That way we can keep tweaking the spreadsheet to improve it further.

Hmm that’s an interesting take. I’ve always prioritized putting the encoder on the output so it measures the actual position of the end effector. While the motor’s actual speed would have a bit more jerk in it to compensate for the slop, the mechanism would be smoothly controlled by the motion magic.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.