Talon SRX ControlMode.MotionProfile works ControlMode.MotionProfileArc does not


I am trying to use the ControlMode.MotionProfileArc mode on the TalonSRX to control a differential drive.
Full source code here robot.py.

If I simply set the ControlMode on line 290 and 291 to ControlMode.MotionProfile it works well and the robot follows the given trajectory. As ControlMode.MotionProfileArc nothing happens, no motor output. I captured a “self-test” during each test MotionProfile.txt (1.6 KB)
MotionProfileArc.txt (1.6 KB)

I’m hoping someone can look at the attachments and/or my source code and tell me if they see anything wrong.

Arguments in Pigeon constructor

Remote LOS : 0 1 Remote Sensor is missing on …

This suggests (at one point) one of the remote sensors was missing, but this was likely during the bring-up phase - so I think this can be dismissed.

Probably should clear the faults to confirm it does not come back (blink button).

Buffer holds Primary PID points (Aux PID not in use)

Set the 'bAuxPID ’ member to true in your traj points. This is necessary for Phoenix to stream the points correctly. Set to false when not arc’ing.

Doc reference for posterity:

I’m not certain if this member is available in the python version of TrajectoryPoint. If not maybe write an issue tracker? (assuming one does not exist).


This looks compelling., note the additional members:


The missing remote sensor was because I was using gadeteer pigeon enum instead of straight pigeon. My pigeon is wired into the can bus. I was able to fix that and see the feedback coming from the sensor.

I cleared the sticky faults and updated the firmware (after i collected the attached test results) on all the devices and still no luck.

I think the bAuxPid flag is most likely the issue. My understanding is the BTrajectoryPoint structure is for use with the 2019 “one-shot” motion profile api and the Trajectory structure is for use with the legacy api. Looks like the bAuxPid flag is not available in that Trajectory structure… @auscompgeek or @virtuald can you comment?



The current implementation of pushMotionProfileTrajectory calls the _2 overload for backwards compatibility reasons. The current CTRE java implementation now calls the _3 overload. If you call that overload then you should be able to get the new behavior.

Unfortunately, it looks like the _3 API has a positional argument called zeroPos0 instead of zeroPos, so you can’t directly use BTrajectoryPoint via the * operator, you’d need to expand the arguments. Alternatively, you can create a new namedtuple that matches the argument names.

from collections import namedtuple

TrajectoryPoint = namedtuple('TrajectoryPoint', (

# .. create points, then you can feed them in via * operator

@ozrien should we just get rid of the old pushMotionProfileBuffer call and only make the new _3 overload available?


The _3 routine effectively deprecates the older versions - and will work for all use cases.
So its really your call. We will keep the old routines for at least this season.

I suspect Py users will want to use the latest features of MP just like everyone else.


We will try this. I will report back here if it works for us.


robotpy-ctre 2019.2.0 is updated so that pushMotionProfileTrajectory can take either the legacy TrajectoryPoint or a BTrajectoryPoint.