The Talons update faster (1000hz instead of 50hz), so it should be better. Otherwise they work the same way. Ramsete itself is an error correction formula - so it should work fine even if you just use percent control.
WPILib PID is easier to implement. With TalonSRX PID, you run into all sorts of weird issues with unit conversions and making sure all your gains are in the right units.
Yes, you can call talon.set(ControlMode.Velocity, someVelocity, DemandType.ArbitraryFeedforward, someFeedForward) to add a feed-forward along with the velocity PID. Keep in mind thatsomeFeedForward needs to be a percent between [-1,1], so you would need to divide your voltage by 12 (if you have voltage compensation on) or by the bus voltage (if you have voltage compensation off)
I would say it’s worth the faster update rate. With trajectory following, the error is typically small, which allows pretty high P and D values to correct for it. In this case it’s less about figuring out all the correct units and calculations than about just guessing a number, test it, and adjust as needed.
I’m not aware of an official example that shows the combination of trajectory following and the talon srx velocity/feedforward control. This example from CTRE shows how ArbitrayFeedForward can be used. WPILib Example Projects, particularly this one, has examples for trajectory followings and drive train characterization
We are testing with velocity control using Spark Max. Modified from the example, uising the 3rd Ramsetecommand constructor passing the appropriate function that performs the pdi.SetReference(velocity) commands to the left and right motors. Our example trajectory is a straight line 3_m long. The code works (we travel nicely 3_m) until the end of the profile, where the robot decides to spin 180 degrees. Working backward all the unit conversion stuff appears to finally be working. We also confirmed our odometry is correct (in meters). Currently looking for bugs in either our creation of the trajectory or somewhere else TBD. Our gains, etc are good because our “old school” trajectory method using precalcluated 20 msec velocity updates works correctly.