Last year there was a manual with thirty-ish pages about the Motion Profile control mode, but I can’t find it in the new documentation system for 2019 season. Where can I find it?
Talon SRXs and anything else made by CTR has good documentation on the CTR website.
Some of that got moved to the legacy subfolder. I didn’t want teams confused with prev season docs.
I should also point out that there is a new, simpler API for firing MPs.
This no longer requires you to perform your own buffering.
Single axis…
Drivetrain with Pigeon…
2 Likes
I have tried running the motion profile arc simple example and have failed to get any results with the motion profiling.
Check self-test and Driver Station message log. report both.
Also did you complete the hardware bring up first? (confirmed firmware version, sensor health, all the things mentioned here.
Start at his link and work your way down towards sensors.
https://phoenix-documentation.readthedocs.io/en/latest/ch13_MC.html
Are there labview examples of this put there anywhere?
“MotionProfile Legacy” has the older comprehensive API
“MotionProfile” has the newer simpler API.
This is the self test log.
********** Robot program starting **********
NT: server: client CONNECTED: 10.35.39.53 port 54105
Warning 44003 FRC: No robot code is currently running. Driver Station
Default disabledInit() method… Overload me!
Default disabledPeriodic() method… Overload me!
Watchdog not fed within 0.020000s
Warning 1 Loop time of 0.02s overrun
edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:273)
Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:273): Loop time of 0.02s overrun
Warning 0 [phoenix] Initialization is complete.
Default teleopInit() method… Overload me!
Default teleopPeriodic() method… Overload me!
Watchdog not fed within 0.020000s
Warning 1 Loop time of 0.02s overrun
edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:273)
Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:273): Loop time of 0.02s overrun
MP started
MP finished
RemoteLOS fault is set. That means the Talon is trying to get remote sensor data and its not on the bus. Probably the remote filter is wrong.
You have to make some decisions about what sensors you want to use before firing MPs.
Some steps …
-
Decide which talon will be running the profile. I usually use the right side, so I’ll treat that as the example. This means the right talon will execute PID[0] + PID[1]. That the other side talon (left) will be setup as an Aux Follower, so it will apply PID[0] - PID[1]. All the math is done in the master, aux follower just takes applies the processed result.
-
If you have other talons/vics to mirror, make them simple followers that follow the rightMaster or LeftAuxFollower, respectively.
-
Decide what sensor source you want to use for robot-distance. It can be one encoder, sum of two encoders, difference of two encoders.
(sometimes you use diff if the left and right encoders are oriented that way).
Let’s say we want to use masterTalon (right) - followerTalon(left) quad sensors. -
Decide what sensor source you want to use for robot-heading. Pigeon IMU or difference/sum of right and left encoder are typical. Lets say we want to use PigeonIMU (on CAN, device ID zero).
-
Open begin.vi
-
Open front-panel of the configs passed into CONFIG ALL
-
Config Selected Sensor for primary PID0 to be Sensor Difference or whatever you decide in [3]. Later we will select difference of what)
-
Config Selected Sensor for auxiliary PID1 to be Remote sensor 1or whatever you decide in [4]. Later we will select which remote device.
-
Sensor Diff means “Diff Term 0” - “Diff Term 1”. So select Diff Term 0 to be quadrature (or similar) and select Diff Term 1 to be the remote sensor 0. Later, we will select which device is the remote sensor 0.
-
Config Remote Sensor 0 to be the AuxFollowerLeftTalon. Remote sensor 0 has a device type and a device ID. Enter matching values for the auxFollowerLeft.
-
Config Remote Sensor 1 for Pigeon on CAN bus - device ID 0
So to recap
PID[0] (drive) will use SensorDiff, which means SensorDiff0Term - SensorDiff1Term
- SensorDiff0 is set to master talons attached sensor.
- SensorDiff1 is set to RemoteSensor0 (a remotely sourced sensor)
- RemoteSensor0 filters for the left talon’s selected sensor (quad).
You may want to use SensorSum depending on orientation.
PID[1] (turn) will use RemoteSensor1
- RemoteSensor1 is set to capture Pigeon’s heading.
Testing
-
Test the config by pushing robot straight forward and back.
Only PID[0] position should rise and fall.
You can use self-test/tuner-plot/ custom plotting, prints, LabVIEW plotting, whatever. -
Test the config by turning robot left and right.
Confirm PID[1] position rises and falls, while PID[0] remains mostly unchanged during zero turns.
2 Likes
Sorry that this may have not been clear when I first mentioned having a problem but we use java in vscode. Also thanks for responding so soon as well as I will get back to you to let you know if I have fixed the problem with your helpful tips thanks Omar.
I HAVE FIGURED IT OUT! After many attempts at changing small variables it turns out that the reason was the I thought that I could construct the pigeon through a talon using a gadgeteer cable then use that for motion profiling how ever this is not the case and it needs to be plugged into the can bus. I thought that it would work through the gadgeteer cable because we had used it this way in the 2018 season.
Ahh so that missing steps was performing sensor-bringup on your remote sensors first (self-test, plots, etc.). We’re currently expanding the Sensor bringup and Closed-Loop doc sections for remote sensors, MP, and MPA. That should help teams leverage these advanced-features.
One important details is to perform sensor-bringup after you select your sensor sources, then test the sensor signals as they are reported by the Talons, to ensure closed-loops get properly configured, healthy data.
Not true. Both work fine. There are different enums for (CAN) Pigeon and (ribbon) GadgeteerPigeon
Juniormunk, Thank you so much for sharing your experience and tips! I can offer our experience as a confirmation of your finding. We spent two long fruitless evening trying to get Pigeon as Remote 1 sensor in auxiliary PID. We use a gadgeteer cable in 2018 season and it worked well. In 2019 season, Pigeon as Remote 1 sensor stopped working while the sensor reading via imu reference works fine. As Omar noticed, RemoteLOS fault is set. We could not resolve it by following the available limited instruction and sample code. We did make sure we are using GedgeteerPigeon enum. We almost gave up on this Your finding that direct can bus connection works like a lifesaver for us. Once we directly plugged in our Pigeon into the can bus, things are working again. Either the failure via a gadgeteer cable is a bug introduced in 2019 built, or the instruction on how to use is not completed in public documentation.
Omar, thank you for answering question in this thread ! we would love to hear from you how to make a gadgeteer cable works for pigeon as Remote 1 sensor. Which part of documentation is missing or what we did wrong ?
Thanks!
After some additional testing, I can confirm that under certain circumstances we can replicate the issue of ribbon-cabled Pigeons not working as remote sensors. We’re working on a fix (which will be a Pigeon firmware update) that should be released soon, and in the meantime using a CAN-connected Pigeon as a remote sensor should work as normal.
This issue is now fixed.
You can see the release notes and download the new Pigeon firmware here:
Hi Jacob_C, thank you for the quick fix! Yes, the new firmwire fixed the ribbon-cabled Pigeon as remote sensors. We had one issue that may or may not relate to the new firmwire. After we installed new firmwire, we could not get any reading from one of Quad sensors. Initially we thought it is our sensor broken, it turned out it is not. After rebooting the driver station pc and a few resets, we were able to get the Quad sensor reading again.
We also noticed that the remote 1 pigeon sensor reading (LV version of this line _targetAngle = _rightMaster.getSelectedSensorPosition(1); ) seems changed a little. In 2018 build and 2019 v4.0 build, the value is : 10 x fused heading. In sample code, it only zeroed Yaw, not fused heading. In new build, the reading seem to be Yaw reading, not fused heading. This is our guess. Our workaround is to zeroed fused heading too to avoid the inconsistent reading.
The fix was new Pigeon firmware only, and has no effect on Talon firmware or functionality.
It sounds like this could be an intermittent wiring connection that happened to resolve itself at the same time you were power-cycling or resetting devices. I would advise double-checking your encoder wiring.
I’m not sure what this and the rest of your paragraph is describing. There should not have been a change to the values returned by Pigeon - this was confirmed during our regression testing of the new firmware.
Can you e-mail our support? We can help troubleshoot the issue faster than over CD.
Support e-mail can be found here: CTR Electronics
Sure it is the loosing connection. Never mind about sensor reading comment. The hot fix works fine. Thanks.