A lower measurement frequency results in less noisy measurements. I would recommend placing the CANrange in a setup similar to how you would deploy it in your application, then swap between the modes and see which mode (and measurement frequency) has the acceptable combination of noise to distance.
Noise is not consistent application from application, this changes based on ambient lighting, material, etc. We did profile 100Hz in our indoor facility against ~.2in thick cardboard and observed less than 1cm of noise.
Software
Phoenix 6 API Compatible
Supported Commutation Types: Trapezoidal with Hall Effect Sensors
DutyCycle and Voltage Control Output Types.
Motion Magic motion profiles Brake configuration via Brake/Coast config in API or Phoenix Tuner X
Reset to Factory Default via Phoenix Tuner X
Out-of-the-box PWM Calibration compatible with FRC CAN bus or PWM control automatically detected over the same wires (pioneering feature of CTR-Electronics controllers)
LED indicators blinking proportionately to output speed for easier debugging.
Follower Mode - Talon FXS can auto follow output of another Talon FX or Talon FXS
Integrated PID control running at 1Khz
Independent limits for supply current and stator current
looks like it doesn’t have a button but could be configurated
It would be nice for CTRE to contribute code so the RIO would automatically substitute an alternate data source, when no CAN-enabled Power Distribution board is found. This would apply for PDP 2.0, but would also kick in if there was a CAN issue with one of the other allowed PD variants. By data source, I mean the supplier of the value which gets filled in to be sent to and logged in the Driver Station as the per-slot current (with the robot voltage and other diagnostic data).
The data to substitute could come from any CAN-based motor controller which provides supply current measurement. Vendors could choose to support this and, when they do, collection of this data should be automatic. For example, a hash of the CAN ID might be used to work out the number to use for the PD slot/channel. The main point is to provide this data in a way that makes it easy to find with the tools people are used to using to view this data. Of course, any vendor-specific tooling or different logging packages would continue to work.
We are aiming to have a public preview of the new product APIs by early December. In the meantime, if you have any specific questions I’ll be happy to answer them.
Using a CANrange as a remote feedback sensor will probably not be supported in the kickoff release of Phoenix. However, we are evaluating our customers needs constantly, and will adjust our priorities if we see an increase in demand for this feature.
it would be easy enough, though, to write something that reads the canrange or lasercan CAN packets and sends CAN packets impersonating a CANcoder, which you do support, right?
Bumping this question is there any way we can know if there is a planned rule change before PDP2.0 starts shipping? More high power ports on my PDP giving me more flexibility is awesome but not being able to legally run critical components on my robot is
As far as I understand while the PDP2.0 is a legal device per the First blogpost, R615 suggests it is not legal to run the Roborio off of it. I am of the mind there will be an update to this rule, just unsure exactly how it will be structured and was hoping there could be some clarification before shipments start.
Or conversely, evidence that a rule such as "All low powered devices can be powered by a second battery " will exist
While its wishful thinking, we’re at the point where all of our LP devices other than the radio/rio (cameras, cancoders, coprocessors, etc.) are planned to be on a separate battery bank. Allowing the radio/rio to do the same would be really cool. It would allow the PDP2.0 to run 24 high power devices, and rule out the chances of a brownout on the radio/rio.
It will absolutely be possible to have a radio/rio on your robot. Common sense dictates that FIRST wouldn’t make a new PDP legal if it made running these components illegal.
I don’t know when the exact rule changes will be released. You might have to wait until kickoff. When the REV PDH was made legal, it was announced in 2020, but was not mentioned in 2021 team update 00. As far as I can tell, there was not a 2022 team update 00, but multiple 2022 team updates contain tweaks to rules around the PDH. The PDH is also only mentioned in the 2022 manual, not 2021. Admittedly, the 2021 updates were focused more on logistics than robot rules, and I don’t remember when the PDH actually became available.
This all indicates to me that the exact rule changes are more likely to come out in the initial game manual, and will probably be the minimal changes necessary to make the new PDP legal, like they were last time. I agree that a secondary power source for the components you mentioned would be cool, but there hasn’t been any indication so far that FIRST is planning to allow that. I would have expected them to mention a change like that already, but I guess you never know.
Thanks, it makes sense it would be in line with how the pdh release was structured.
My main concern/speculation is that the safest option is to put the radio/rio on a non-resettable fuse like the pdp1.0 and pdh do. With this new pdp2 that’s not possible on board. My best guess is that the radio/rio will be required to be on a non resettable breaker with the use of something like the rev MPM.
Now the big leap is why power a separate rev MPM off of the pdp2.0 when teams are already running or planning to run a rev MPM off of a battery bank for things like vision, sensors and coprocessors. I do agree allowing the Rio/radio to be not on the main battery would be a deviation from the norm and a pretty hefty rule change
@daltzsmith Do you have any updated shipping estimate for the PDP 2.0 (early/late December)? More importantly, will all pre-orders ship before kickoff?
