We have an intake that is driven by a Falcon500 (running phoenix 6 firmware) fhat we are going to run with Motion Magic.
I was curious if anyone had an examples of this that they’d recomend.
I say wrist/arm because this thing isnt nearly as long as an arm, but is a similar premise
I’m particularly currious if anyone has any recomendations on how to calculate gravjty when using these ‘rotation units’, somehow create a circle around the 2 horizontal Rotation values?
Another thing i’m pariculsry concerned about is overdriving the motor into the robot or into the ground if i overshoot targets!
Well, it sort of depends on your mechanism. However, simplistically:
Your gravity feed forward is simply the sine or cosine of the angle calculated from the start position of the rotor sensor, to the current position. You can decide whether you want sine or cosine to be the reference angle, based on where the mechanism starts. You want your gravity feed forward calculation to return 0 when the mechanism is vertical, and 1 when it is the horizontal position.
You calculate the feed forward value empirically by putting your mechanism horizontal, and increase the motor output in Phoenix Tuner until the mechanism holds its position against gravity.
(You do this by choosing either voltage or duty cycle i.e. percent output, I recommend voltage because duty cycle will be affected by the battery voltage sag as the match goes on)
Then, lastly, when you do your motion magic control request, you can add the arbitrary feedforward value.
// Call the arbitrary feed foward value according to the current rotational position
// and pass that to the MotionMagic control request
m_talonFX.setControl(request.withFeedForward(getAribitraryFeedForwardValue()));
We haven’t done that this year, but I think that will work based on how it used to work in Phoenix 5.
Additionally, we have an arm whos center of mass changes since it extends and retracts. In this case, I believe that the necessary feedforward would vary directly with the length of the arm
They don’t mention their usage of kG much in their docs
Looks like you can specify a gravity type and then have to specify a sensor offset so that it is 0 when it is completely vertical.
This makes sense.
My only question then would be how does it handle the other side? If the sensor offset is set so that it is 0 at the horizontal, it can then continue rotating and be another value, completely horizontal on the other side
90 degrees will be vertical, and completely horizontal on the other side will be 180 degrees - or, per the library’s standard units, 0 turns and 0.5 turns are horizontal, and 0.25 turns is vertical.
The calculation should handle angles greater than 0.25 turns just fine.
ah okay. SO this is where the ratio comes into play I guess.
We have a decent gearing on our arm, so I’m not sure if a quarter turn gets us to vertical, but I guess we’d test it and then understand the ratio pretty easily.
Is there a correct approach to be setting current limits? I’m very afraid of overdriving into the mechanical limits and hurting the falcon500. But I don’t want to accidently ‘choke’ the motion magic algorithm while its working
This is great, I wonder why their docs don’t specify this exact thing…in their closed-loop docs they specify adding the feedforward to account for gravity in more than one place.
I hadn’t looked at the actual structure of the slot config, which does very nicely specify there’s a kG to account for gravity.
A motor controller running a duty cycle is effectively a buck converter. The current flowing through the motor coils (stator current) is higher than the current flowing in from the battery (supply current) whenever the voltage seen by the motor is lower than the voltage on the bus.