We are trying to stream 8 motion profiles to 8 different Talon SRX at the same time. Each profile is running at 100hz. Our thread that moves the points from the top buffer on the RoboRio to the hardware buffer on the Talon is running at 200hz.
The problem is that while the motion profiles are transferring down to the Talons the CAN bus is saturated at 100% and we are seeing the Tx Full counter increasing. We are seeing sporadic results on the motors. This might be due to the profiles we are sending them.
We have slowed down the CAN frame rate of all the different status packets and we have slowed down the control frame. This has helped marginally but we are still saturating the bus at 100%.
Has anyone successfully streamed 8 motion profiles simultaneously? Does anyone know what the theoretical limit would be or if there are any tricks to get this working?
We have not buffered 8, but we have buffered 2 at a time. You may have already tried some of this, but when we buffer, we check to see if the Talon is ready for another point before sending it. The number of points in our MPs are less than 128 (even for complex paths), so we can buffer completely before running.
Not knowing your application, I would investigate whether 8 simultaneous is necessary.
I would also look to see if the SRX internal profiling modes (e.g. motion magic) can fill in some or all of your profiles so you don’t need to use so much bandwidth sending them tick by tick.
We are attempting to have our swerve drive (4 drive motors and 4 steer motors) follow an optimized path that allows it to rotate precisely to a given angle while translating. In order to the accomplish this the speeds of all the motors need to be varied constantly to produce the desired motion.
You should be able to break each motor’s path into a series of parabolic approximations averaging a few hundred milliseconds each, and pass those acceleration ramps to the SRXs with a lot less network traffic.
Using Motion magic for the swerve portion seems very compelling to me.
Otherwise if you stick to your profiles but reduced the trajectory period from 10ms (100Hz) to 20ms (50Hz), that might be enough. I just did a simple test with a HERO and 12 Talons, 8 of which running the same MP. At 10ms I’m hitting >90%. But at 20ms the peak is 67%.
The HERO motion magic example only waits for 5 trajectory points to buffer before starting the MP, so I suspect its a comparable test to what you are doing on RIO. I call ProcessMotionProfileBuffer() at twice the rate of the trajectory point period.
That’s also worth pointing out. If the MP fits entirely in the Talon’s MPB, then you can ProcessMotionProfileBuffer() at a slower rate (less utilization), then fire the MPE after confirming the API-side buffer is empty.
If it doesn’t fit in the Talon’s MPB, try cutting trajectory period in half, and reduce the calls to ProcessMotionProfileBuffer() by half. I suspect you’ll still get enough resolution out of your profile. Be sure to instrument “HasUnderrun” to ensure you don’t slow down the feed by too much.
The default cycle for teleopPeriodic() is also 100Hz (10ms). Does this same issue occur when driving a 4 wheel swerve in teleop in speed mode with SRXs? If not, could you just read a synthetic table of joystick values from a table and use this to drive the system, or am I missing something subtle?
All good points. We hear teams preaching 200hz control loops so we were hesitant to go below 100hz. I think the solution is going to be 50hz profiles with buffering the entire profile first. Right now we are around 180 points with our paths so if we cut them in half we can easily fit them in the bottom buffer.
While we are generally fans of the Motion Magic feature the paths we are generating are not using constant velocities because the robot is performing a twist while translating so Motion Magic won’t work for us.