Quote:
Originally Posted by mikets
So if I understand you correctly, using CAN to control the kicker basically saved you a limit switch. And what does an under-damped PID loop has to do with CAN? I don't quite see it probably because I don't know your kicker's design.
|
It was a rotary kicker direct driven by a motor: the boot would rush 120ish degrees to kick the ball, return to 90ish degrees to get back within the envelope, and then slowly return to 0ish degrees to reset.
The kick (0 -> 120 ->90) was handled in a single CAN command of "Travel to 90 with constants P,I,D". Since those constants were under-damped, it would reliably "over-travel" to 120. It was surprisingly easy to tune.
The return was just a "apply amperage -A". Yes, we could have done this with a limit-switch, but it was just as easy to do it this way. One benefit was that it made it really easy to hold it in the ready position against gravity. Not enough reason to move to CAN, but since it was already there...
I've used this as an example with a few students, and I think it is a very interesting teachable moment. Plot the desired response on a torque/speed chart, and then compare it to voltage, current and speed modes. For kicker return, current mode is pretty darn close to optimal.
Quote:
Originally Posted by mikets
... I know CAN bus offers a lot of new nice functionalities but how many teams are actually using them in software and if they absolutely cannot do without these functionalities? Every year we had a discussion on switching to Jags but when doing cost and benefit analysis, Jags always lose out for us.
|
I really don't think that CAN should be used for every motor on every robot. It isn't a blanket replacement for PWM (though it can be used as one), and it isn't a silver bullet - it enables access to new control modes that can provide significant benefit when applied correctly in the appropriate situations.
I'm glad your team has the discussion, and I'm glad they are coming to a conclusion that works for them.