The motion profile is being regenerated in real time. There is no PID around position
Please see below.
This is the same test as before, but with the new parameters. Active Trajectory Position and Closed Loop Error are on the secondary Y axis in this chart for readability.
Based on continuing experimentation, it looks like the active trajectory position is the desired position of the motion profile at that point. That then is used to generate the closed loop error for the position PID, though it appears to be constrained to prevent the closed loop error from causing the position PID to exceed cruise velocity (you see it smooth out as the position PID approaches cruise velocity).
Right now, running these tests I’m using a massive setpoint - so active trajectory position increases without bounds, but in actuality it clamps itself to the setpoint once it reaches there.
Neat! It looks like the closed loop error increases until the motor starts to turn and pick up speed. At steady state, (closed loop error)*kP is equal to the output required to maintain the specified cruise velocity. The motor is no longer “falling behind” the trajectory, and the closed loop error is no longer increasing, so the output remains steady.
In most use cases you’d have a kF value so that the profile is tracked correctly, but this test nicely demonstrates the inner workings of the motion magic algorithm.
Right - ignoring the kF for now which would be required to hit the desired trapezoidal path.
As another followon, here’s the sparkmax with an appropriately tuned velocity PID across a complete motion.
SparkMax.restoreFactoryDefaults(); SparkMax.setIdleMode(CANSparkMax.IdleMode.kBrake); CANPIDController pidC = SparkMax.getPIDController(); pidC.setOutputRange(-1, 1); pidC.setP(0.00016, 0); pidC.setI(0, 0); pidC.setD(0.0004, 0); pidC.setFF(0.000156, 0); pidC.setSmartMotionMaxVelocity(2000, 0); pidC.setSmartMotionMaxAccel(1500, 0); pidC.setDFilter(0.25, 0); pidC.setSmartMotionAllowedClosedLoopError(0.02, 0); pidC.setSmartMotionMinOutputVelocity(0, 0); SparkMax.setEncoderPosition(0); pidC.setReference(200, ControlType.kSmartMotion, 0, 0);
We’ve made a few changes and have a new build of the roboRIO API v1.1.5.
Online json location remains the same.
Beta API Update v1.1.5 Changelog
- Improvements to address issue related to this report.
- Method to stop any REV periodic frames before enabling heartbeat
- Improvements to heartbeat protocol
- Moved all heartbeat implementation into its own dependency called by C++ and Java through JNI
- Removed setControlFrameRate() call and removed repeating packets, updates to control frames are now as fast/slow as the user calls Set() or SetReference()
- Adds inversion properly to PID output range, IAccum and SetPosition
- Updates to doxygen/javadocs comments
- Maven artifacts now include source for both Java and C++
SPARK MAX Critical Safety Warning: motor controller causes unintended, unexpected motor activation
Hi, could someone provide a C++ code sample for having a Spark Max follow a Talon SRX?
Has anyone had success having a SPARK MAX follow a Talon SRX running firmware 4.11 in LabVIEW? We have been unsuccessful so far.
The SparkMax-driver headers artifact seems to be another copy of the SparkMax-cpp headers, and I can’t find the
rev/CANSparkMaxHeartbeat.h headers anywhere (so the C++ source can’t be compiled). I presume this isn’t intended?
Good catch, updated the drivers artifact which now has those two headers. Thanks.
Alright - we were able to get the Spark Max to follow a Talon SRX using the highlighted code. Sorry for the bad quality image.
The Get/SetIMaxAccum methods negate the values they get when the motor is inverted. I thought the IMaxAccum is supposed to be an absolute value though. If not, where’s the corresponding SetIMinAccum method?
The SetOutputRange method flips the order of the arguments when inverted, but doesn’t negate them… surely they should be? Otherwise the maximum would end up less than the minimum…
Good to know we weren’t the only ones who ended up with very small PID gain values. As another sample point, we got our velocity PID tuned up last night and working with the trapezoidal motion profiling. Seems to be working well so far!
Does this beta only work for teams with the beta hardware?
Nope - this is for the production hardware. If you want features like Smart Motion, encoder position setting, and a few others, you’ll definitely want to use the beta.
Please note: we have rolled the beta into an official release here SPARK MAX - Firmware Release v1.1.31