So while at SCRIW, we had more and more severe connection issues as the event went on. We have done our post action diagnostics and made an interesting discovery that we wanted to pass along.
Since we were doing an off-season swerve build, we put together a robot with a mixed control system. Our robot used a CTRE power distribution panel (PDP) and a REV Radio power module (RPM). The REV RPM was powered directly by the CTRE PDP VRM connection (as if we were using the REV PDH). This does not work reliably. In order to use the REV RPM with the CTRE PDP, you MUST add the CTRE Voltage regulator module (VRM). We haven’t seen any “mixed setup” wiring diagrams, so we wanted to document this for others.
Since an all REV setup works without a VRM, this must mean that the REV PDH must have an internal voltage regulator for the side port(s) (circuits 20-23). Unfortunately, we had assumed the REV RPM had this circuitry. I didn’t find this in the REV documentation documentation anywhere, perhaps REV can confirm this for us.
Anyway, I’m posting this here so that others can learn from our experience.
This is false; something else was likely the culprit. To my understanding, adding a VRMVoltage Regulator Module in between the PDPCTRE's Power Distribution Panel and RPMRevolutions Per Minute is a violation of R616/R617 and is therefore not a legal setup. The way you originally had it wired is correct and the only legal way to do it.
There’s a few things that could’ve caused this behavior (though it’d help if you described it further):
-The fuse for the VRMVoltage Regulator Module port is loose or worn, causing an intermittent connection that you didn’t properly recreate in testing.
-Your RPMRevolutions Per Minute is faulty. As a CSAControl System Advisor, I assisted one team whose RPMRevolutions Per Minute output would become insufficient if the input voltage dipped too low, despite still being in operating spec.
They do not. There’s no voltage regulation on any port on either the PDHREV's Power Distribution Hub or PDPCTRE's Power Distribution Panel; they’re identical in that regard.
It does. It’s an 18V boost converter, that’s its primary function. Its operating range is 4.75V-18V; if that doesn’t match your experience, then there was an issue somewhere.
Was the radio rebooting? You loose coms for 30-60 secs. I would look at power connection between the PDP to the RPM and RPM to the radio. Replace the Ethernet cord if you are running POE. Also check battery terminals and breaker lugs. I have found the RPM to be more reliable than VRM.
If you not loosing your coms for at 30 seconds, the problem is not in the radio power.
It appears that your team is jumping to conclusions before investigating the problem sufficiently.
As others have stated, many of the assumptions are incorrect. This will virtually guarantee that the conclusions will be incorrect.
Frequently, the initial impression one gets for what is causing a problem is incorrect. It would be of benefit to your team to learn to apply the “5 Why’s” technique for determining the root cause of a problem through a more thorough process.
Thanks for the suggestions. The 30 sec was approximate; but had the time of a radio reboot.
Given the feedback here, I now suspect a faulty RPM (good suggestion @thatnameistaken). I could go through the various things we’ve tried; but the common thread is the RPM and a weaker main battery (yes, we’ve swapped radios, ethernet cables, wiggled power connectors, etc.). By the end of SCRIW, simply raising our arm would trigger it the communication failure (we didn’t bring a full battery compliment, so the batteries got weaker at the day went on and the comms issue got worse). We reproduced the issue at our shop with the same conditions, and (improperly I guess) inserting the VRM before the RPM could keep the communications up.
If the RPM has a voltage regulator, then either it’s much more sensitive to brown outs or it’s bad.
That sounds like a faulty RPMRevolutions Per Minute to me. It’s supposed to operate down to 4.75V; for reference, the roboRIO disables motor outputs at 6.3V, and the roboRIO 2.0 has a default brownout of 6.75V. It’s unlikely to sink down to 4.75V from there, and the RIO itself isn’t guaranteed to stay on below 4.5V.
The team I assisted at an event was seeing similar issues, and could reliably reproduce it by aggressively driving back and forth on the practice field. The LED on the RPMRevolutions Per Minute would visibly go out briefly too. After swapping the RPMRevolutions Per Minute for a fresh one, everything worked as expected.
For clarity, there’s nothing improper from an electrical perspective about inserting the VRMVoltage Regulator Module (other than the efficiency loss compared to using just a VRMVoltage Regulator Module or (functional) RPMRevolutions Per Minute), and it makes sense that it resolved the issue; it’s just against the rules because the radio power path is heavily regulated to ensure there’s no extraneous loads or failure points in it.
The RPMRevolutions Per Minute implicitly has a voltage regulator; it outputs 18V, which is higher than what it’s taking in. Its listed operating input voltage is 4.75V-18V.
It sounds like you’re seeing it drop out much higher than 4.75V. I’d recommend contacting REV support; I’m sure they’d appreciate the opportunity to look into this.
@Greg_Needel, has REV ever seen this behavior from an RPMRevolutions Per Minute? I love the product, but I amAndyMark intrigued by this being the second instance of this issue I’m aware of.
OK I thought I’d update everyone. We pulled the RPM off the robot and put it on a variable power supply (4V->5.5V) with a radio on the output. The RPM would show the power LED at all voltage ranges; but would not power the radio anywhere in the voltage range. Putting a new RPM in the test setup, we saw that the new RPM power LED stayed lit, and it would power the radio at 5.5V. It dropped radio power as the voltage fell below 5V.