Motion Magic with slaved motor Help

We’re trying to use Motion Magic with the Falcon 500 motor for position control of our rotating arm mechanism for our climb this year. We’re having good success positioning the motor where we want to accomplish our traverse climb, but we’re now having difficulty increasing the speed at which the arm turns so we can complete the climb faster. We have two Falcon 500s in a leader/follower configuration with left motor following right with inversion of “oppose master”.

When I try to increase the cruise velocity and acceleration, the arm gets part way through its rotation then starts rotating back and forth violently before finally reaching its final destination. I also notice differences in speeds reported by each motor despite the left being set up to follow the right.

I believe the velocity we are requesting (716800/100 mSec is below the max for the Falcon assuming using internal encoder and max RPMs). As you can see from the chart, we never get close to the requested velocity. I’ve set the max acceleration to about 6969 counts/sec. The motors are driving the arm through a 100:1 GB and a chain with a 3.5:1 ratio giving a 350:1 gear ratio.

Here is a plot of speeds reported by the two motors:

You can see the left motor lags the right and doesn’t seem to be controlled in the same manner. When we control the system, we’re only setting the position for the right motor under the assumption that the left motor will follow because its following. Both motors are setup with the same configuration with the exception of the left being setup to follow the right.

As a side question, I’m also a little surprised to see the velocities have opposite signs considering they are setup with the left following the right in opposition.

Any advice is appreciated. Let me know if more data is needed.

If you don’t follow the master, but set them both in motion magic mode with inverted setpoints do the graphs look more closely related?

How is your CAN Bus traffic utilization? I think the common device API has followers getting applied motor output at 10 ms, and if your closed loop period hasn’t been changed, the motion magic motor will be running 1 ms resolution in the profiles.

I think what I said is true…would love someone to correct me on it.

The people over at CTRE will suggest looking at one of the other MM Examples. Try this one Phoenix-Examples-Languages/Java Talon FX (Falcon 500)/MotionMagic_AuxStraightIntegratedSensor at master · CrossTheRoadElec/Phoenix-Examples-Languages · GitHub

Leader/follower, not master/slave. Please.

3 Likes

Many thoughts… and don’t have all info about your setup to be sure, here are some things to consider:

Falcon max speed is about 21500 encoder click/100mSec… 6300 rpm converted to click per 100 msec

Seems that the follower is significantly delayed, check:

  • it’s ramp rate (i suggest 0 for both motors)
  • canbus utilization
  • leader motor status frame1 period
    Common Device API — Phoenix documentation
    usually i set the leader frame rate to 5mSec to have the follower “nearby”
  • regarding acceleration setting… If you want full speed - 20000 (which I don’t recommend trying. Usually working around 75% max speed is more feasible in heavy load systems), but … whatever speed… The speed you set dividend by the acceleration you set will be the time it takes the system to get to full speed. So … If you want the motor to get to full speed in 0.5 sec, acceleration of 40000 is a good number.

But, I guess the main problem is

  • apart from the delay, the graphs imply that there is some flexibility in the mechanical connection between the two motors, this is very problematic when working in leader-folower mode. Since the follower doesn’t have any feedback, and if it can move separately from the leader- it will not follow the leader under loads

If you share pictures of the mechanical setting, will be able to validate this guess.

If this is the case, and no option for rigid connection between the motors then , I believe running motion magic on both (with same values) will work better. Just don’t use too high accelerations in this case, so the motors won’t fight each other. Not optimal solution… But will look better than the graphs above.

Just make sure that all configuration parameters are identical (ramp, nominal, peak, pidf, period, window, current limits, etc…) So the motors will run the same “plan” , just with a few milisec time difference.

Again… Rigid connection and leader-follower mode is the preferred solution if possible

Hope it helps

You’re absolutely right. I’ve edited the post.

Now that you’ve pointed it out, my math error for the max speed is obvious. The chart clearly shows I hit max speed right before the trouble starts. I’m a little surprised that how the motor behaves if you try to drive it with a velocity too high, but now that I know the issue, I can fix that.

To answer your other questions/observations:

  • The ramps are set to 0.05. I can try putting them at zero.
  • Can bus utilization is around 27%
  • Gotcha on acceleration
  • We haven’t changed the status frame period, so its set to whatever the factory default is.
  • You’re right, there is play in the linkage between the two motors. Each motor is connected via a chain to a sprocket driving a rotating arm which lifts the robot. We have tensioners on the chain, but there is still some movement and it isn’t practical to change that at this point. Would we be better off driving the motors individually rather than use leader follower (as NewtonCrosby suggests)?

Thanks for the input on this!

Probably yes…
Above i suggested that if you do this , then lowering the acceleration will reduce the difference between both sides (will be caused by the timing difference between the motors).

And… Important to use same parameters for both, above i mentioned the important ones

1 Like