Legality of running a capacitor inline with roboRIO power

[ImOn3618]

Hi, we've been having frequent brownouts through our whole robot, with the roboRIO being the first device to lose power. This happens primarily when we change directions rapidly, or get into a pushing match. In an effort to minimize input current spikes, we're considering adding a capacitor inline between the PDP out and the roboRIO power in.

Is this legal?

Will it help with the input spikes?

[cgmv123]

Is this legal?

A capacitor would be considered a CUSTOM CIRCUIT. CUSTOM CIRCUITS aren't allowed to alter the power pathways of key control system components like the RoboRIO.

[Tom Line]

Sounds to me like you are not.powering the roborio from the correct the location. It's sounds like you may have it running through one of the non regulated pdp ports.

[ImOn3618]

We wouldn't have passed inspection if it was powered from the wrong place. We've got it running off the same rail as the VRM and PCM(which we don't have) on the PDP.

[RufflesRidge]

Sounds to me like you are not.powering the roborio from the correct the location.

What do you mean by this? While the roboRIO has dedicated connectors on the PDB, they are not regulated outputs, they are raw battery. The only difference between using these connectors and a 20A breaker slot is the different protection (10A quick blow vs the 20A slow triggering auto-resetting circuit breaker)

OP, please explain what you mean by browning out? Are you actually managing to reboot the roboRIO? Or just trigger the brownout protection which disables your motors until battery voltage recovers? Have you checked how much current you are actually drawing using the DS logs?

I think you need to look at solutions to your gearing or software to manage your current draw. Putting a cap on the roboRIO input is both illegal (as noted by another poster above) and is kind of like putting a bandaid on a cut that needs stitches.

[rtfgnow]

We wouldn't have passed inspection if it was powered from the wrong place. We've got it running off the same rail as the VRM and PCM(which we don't have) on the PDP.
Do you live in a perfect world? If so, how do I get in?

Inspection should catch that, but it is not unheard of for robots to go through inspection with a problem like that unnoticed. I know an inspector that will ask if everything is powered correctly and if the electrical system is a rat's nest, he will take the team at their word instead of trying to trace the wires.

You could double check you wires to make sure they are securely inserted on both ends. The wires could be bounced around when you change directions quickly or forcibly slam into a robot or the field meaning the roboRIO is reset.

[Michael Hill]

Putting one inline? Besides the fact it being illegal, it wouldn't work. A capacitor in-line (as in in series) with the power line would, in fact, block power from getting through (capacitors are commonly used to AC-couple, which blocks out DC power. What you would want, in this hypothetical situation, is a capacitor from power to ground. This would allow a capacitor to supplement the power rail when the supply decreases.

[Joe Johnson]

Do you live in a perfect world? If so, how do I get in?

<snip>

I'm throwing the Unnecessary Sarcasm Flag here. Come on. We're better than that on CD.

Please. I'm begging you. It's easy to run down hill until we are all tumbling head over heals into the mud that so many other discussion forums online live in. Elevate if you can.

Dr. Joe J.

[ImOn3618]

I can say with 100% certainty that our wiring is not the problem. The wiring is pristine, and correct. My question is what can be done to minimize input current spikes as much as possible, assuming all wiring is correct, and a non-issue.

We've considered adding code to soften drive input, as we tend to brown out when changing directions rapidly.

Changing the Talons to coast mode rather than break would also likely help to soften input, right?Correct me if I'm wrong, this would also make changing directions more taxing if still rolling.

[ImOn3618]

As far as the brownouts go, all components go into brownout protection mode when actually driving. The roboRIO also loses connection.

When we set the robot up on blocks (minimal load), only the motors go into brownout protection mode.

[Daniel_LaFleur]

Hi, we've been having frequent brownouts through our whole robot, with the roboRIO being the first device to lose power. This happens primarily when we change directions rapidly, or get into a pushing match. In an effort to minimize input current spikes, we're considering adding a capacitor inline between the PDP out and the roboRIO power in.

Is this legal?

Will it help with the input spikes?

Is it legal? No. Custom circuits are not allowed to modify power paths.

Check to see if the RoboRio is plugged in to the correct spot (This is a boost-buck port so it is less affected by power spikes).

Next, look at the driver station dashboard. There should be a graph of the battery voltage. This should give you a hint as to where the issue is.

I suspect that your battery is low and you are using a high traction drive train with an incorrect gear ratio.

[Jared]

I can say with 100% certainty that our wiring is not the problem. The wiring is pristine, and correct. My question is what can be done to minimize input current spikes as much as possible, assuming all wiring is correct, and a non-issue.

We've considered adding code to soften drive input, as we tend to brown out when changing directions rapidly.

Changing the Talons to coast mode rather than break would also likely help to soften input, right?Correct me if I'm wrong, this would also make changing directions more taxing if still rolling.

Coast/Brake won't have any effect. It shorts the motor to make it come to a stop faster, but doesn't do anything clever to apply more power.

Ramping your outputs will help, as will adjusting your gearing and using good batteries. It's also possible to do current limiting. The basic idea is to measure the current at the PDB and if you're over by n amps, decrease voltage by k*n volts, where k is some experimentally determined constant.

[Caleb Sykes]

We've considered adding code to soften drive input, as we tend to brown out when changing directions rapidly.

This is a great solution, we have been doing this for a long time. Basically, just put a limit on how fast your motor inputs can change. If you use java or c++ and want to implement this, pm me and I can walk you through the process and share our code.


Changing the Talons to coast mode rather than break would also likely help to soften input, right?Correct me if I'm wrong, this would also make changing directions more taxing if still rolling.

Switching to coast mode might help a bit, but this is almost certainly not the root cause of your issues. Switching to coast mode shouldn't make anything more taxing. Be careful with this change though, make sure that you can remain on the batter if your speed controllers are in coast mode.

[Mike Copioli]

Sounds to me like you are not.powering the roborio from the correct the location. It's sounds like you may have it running through one of the non regulated pdp ports.


There are no ports on the PDP that are regulated. The VRM has SEPIC regulated outputs. If you are getting frequent brown outs the most likely culprit is a poor connection somewhere between the battery and PDP. Scrutinize all of your connections and use the drivers station logs to determine current draw of each channel on the PDP and system voltage during high current periods. I found this to be to most effective way to root out wiring/brownout issues.

[Ether]

Some random thoughts:

I was wondering if you or anyone on your team calculated how much capacitance would be needed to actually make a difference.

You should focus on understanding why the brownouts are occurring, and address the root cause rather than treating the symptoms.

If you were to provide sufficient detail about your design, I think there are people here on CD who could make some very constructive suggestions for simple changes you could make that would possibly eliminate the brownouts entirely.

Follow Mike's advice about your wiring, even though you think it is "100% correct and pristine".

[EricH]

Follow Mike's advice about your wiring, even though you think it is "100% correct and pristine".


At the risk of getting another "Unnecessary Sarcasm Flag" thrown, I agree with this. This is CS101 Syndrome: "It's perfect, I did it!" Guess it applies to electrical as well... Get someone who isn't familiar with your wiring to examine it if you can. They'll be more able to find the problem easily than you are, because they don't think "Oh, that's normal" on something that might not be right.

[ImOn3618]

I suspect that your battery is low and you are using a high traction drive train with an incorrect gear ratio.

We have a rigorous standard for competition batteries, and start each machine with a fresh, fully charged battery, so I doubt that's the issue.

However, we have a very high traction drive train (brecoflex treads with about a 1.5 CoF, 750ish N force of kinetic friction while driving). The gear ratio on the drive belts is 14.2:1 using RAWboxes. While the drive train definitely contributes to our issue, there's not much we can do about it with 6hours of unbag time.

[ImOn3618]

Get someone who isn't familiar with your wiring to examine it if you can.

Guess it's worth a shot

[MrBasse]

We have a rigorous standard for competition batteries, and start each machine with a fresh, fully charged battery, so I doubt that's the issue.

However, we have a very high traction drive train (brecoflex treads with about a 1.5 CoF, 750ish N force of kinetic friction while driving). The gear ratio on the drive belts is 14.2:1 using RAWboxes. While the drive train definitely contributes to our issue, there's not much we can do about it with 6hours of unbag time.

Beyond just charging them, do you do any tests on them to gauge the batteries overall health?

[ImOn3618]

I suspect that your battery is low and you are using a high traction drive train with an incorrect gear ratio.

Was off on my math/material type. It's actually .7CoF, 370N force of traction

[ImOn3618]

Beyond just charging them, do you do any tests on them to gauge the batteries overall health?

We track and compile data from a battery beak, including power output, drain rate, and changes in amperage at various voltages. If they get below a certain threshold we stop using that battery and recycle it. We've also used FRC2619's battery maintenance guide in the past.

[Kevin Sevcik]

We have a rigorous standard for competition batteries, and start each machine with a fresh, fully charged battery, so I doubt that's the issue.

However, we have a very high traction drive train (brecoflex treads with about a 1.5 CoF, 750ish N force of kinetic friction while driving). The gear ratio on the drive belts is 14.2:1 using RAWboxes. While the drive train definitely contributes to our issue, there's not much we can do about it with 6hours of unbag time.Gear ratio only barely matters. What's your theoretical top speed, assuming 5400 RPM input?

I agree with Mike that your issue could be a bad connection somewhere between the battery plug and the PDP, on either the positive or negative leg. Double check every single connection starting from the battery plug. Check for corrosion or a bad crimp. If a ring terminal looks looks dull or corroded, either replace it or hit it with a wire brush till it's shiny. Check the contacts in your main battery connector for corrosion as well. You might also try replacing your 120 Amp Main Breaker with a new one. Main breakers can occasionally have weird issues.

[MrBasse]

We track and compile data from a battery beak, including power output, drain rate, and changes in amperage at various voltages. If they get below a certain threshold we stop using that battery and recycle it. We've also used FRC2619's battery maintenance guide in the past.

That's good, should rule out a bad battery. There is a really easy solution to this problem: don't change direction really quickly.train your drivers to not do it anymore and you won't do it anymore.

[ImOn3618]

Gear ratio only barely matters. What's your theoretical top speed, assuming 5400 RPM input?

About 4.75ft/sec.

[Ether]

...drain rate...

What are the units of "drain rate" and how do you measure it?

[ImOn3618]

It's just power output compared to ℅ battery charge. We use it to get a rough idea of how fast our batteries are being drained. Older, worse batteries tend to lose charge faster.

Theoretically, loss of 30℅ charge from 100% is normal for us. So about 12.5v to 8.75v per match, according to our multimeters

[Ether]

It's just power output compared to ℅ battery charge.

I'm still puzzling how you measure this. How do you measure power?

[ImOn3618]

It's voltage, not power(joules), my bad.

[Kevin Sevcik]

About 4.75ft/sec.4.75, or 14.75? 4.75 seems unreasonably slow. Like, low gear in a two-speed slow. I'm having difficulty believing you're browning out turning or pushing at 4.75 fps, unless you have serious drivetrain issues. I guess the other question is what your current draw is when you're running full forward with the treads off the ground.

[ImOn3618]

4.75, or 14.75? 4.75 seems unreasonably slow. Like, low gear in a two-speed slow. I'm having difficulty believing you're browning out turning or pushing at 4.75 fps, unless you have serious drivetrain issues. I guess the other question is what your current draw is when you're running full forward with the treads off the ground.

We're *really slow*, decided on pushing power early on. I'll get the current draw ASAP.

[cmwilson13]

When we set the robot up on blocks (minimal load), only the motors go into brownout protection mode.

That should not be happening. I'm surprised no one else caught this unless i missed a post. you have a problem somewhere if the drive is going into brown out protection when the bot is on blocks. mechanical issues with drivetrain components, or wiring.

[Kevin Sevcik]

That should not be happening. I'm surprised no one else caught this unless i missed a post. you have a problem somewhere if the drive is going into brown out protection when the bot is on blocks. mechanical issues with drivetrain components, or wiring.I was suspicious of this as well, thus the top speed question. Also don't forget software. Only driving one CIM out of 2 could cause fun problems like this.

[cmwilson13]

I was suspicious of this as well, thus the top speed question. Also don't forget software. Only driving one CIM out of 2 could cause fun problems like this.

we had to drag a cim few years ago on a practice bot and we drove it for a while without major issues. but code is definitely a possibility

[DonRotolo]

When we set the robot up on blocks (minimal load), only the motors go into brownout protection mode.
As cmwilson13 notes, this is your problem.

It could be mechanical, but I suspect one of your CIMs is turning against the other. Unplug all breakers except one, run the drivetrain and note the direction. Repeat for all other CIMs. Let us know what you find.

As for mechanical: If you cannot easily turn the wheels by hand (robot off), disconnect things until you can. Whatever you just disconnected has a mechanical problem, for example a gear in backwards and rubbing the housing. Happens all the time.

[GeeTwo]

As far as the brownouts go, all components go into brownout protection mode when actually driving. The roboRIO also loses connection.

When we set the robot up on blocks (minimal load), only the motors go into brownout protection mode.

Given the second sentence, I agree that a mechanical problem (chain alignment, grinding gears, etc.) is the most likely culprit. However, we had an issue very much like your first problem stated yesterday. That is, when we would hit an obstruction that largely stopped the wheels (moat was worst) or quickly reversed direction, the robot would lose connection. We spent a good bit of time brainstorming ways to prevent brownout (including the same capacitor you were considering) and strategies for the order we would attack the defenses. The thing is that if the issue seemed to be that the RoboRIO did NOT brown out, but go straight to blackout with no current spike in the logs. We finally tracked it down to a loose connection at the PDP inputs. The collision/sudden acceleration were giving us a voltage drop deep enough to reset the radio rather than just the motors. I don't recall if the RIO was resetting or just the radio. We changed to the correct bolts (long story there) and the problem did not recur over the next half hour or so of similar driving. OBTW, we found the issue just by wiggling and pulling on wires. A few queries revealed that the main power wires were secured by someone who did not know what LCKR (pronounced "locker") stands for. Loose Connections Kill Robots.

[cbale2000]

Regardless of the specific cause of this particular issue, control system brownouts are, in my opinion, a strong reason for FIRST to re-adopt the backup battery.

Back when we used backup batteries on our robots (pre 2009), the controllers on the robots, even without a backup battery, would restart and reconnect to the control system in about 5 seconds after a power loss, and even this was deemed so unacceptable that the backup battery was required.

These days you can wait upwards of a minute or more for a complete restart and reconnect of a robot between the Rio and the radio, meaning if you loose power at any point, your robot is basically dead for the rest of the match.
Why FIRST ever thought dropping the backup battery requirement was a good idea is unfathomable to me.

[cmwilson13]

Regardless of the specific cause of this particular issue, control system brownouts are, in my opinion, a strong reason for FIRST to re-adopt the backup battery.

Back when we used backup batteries on our robots (pre 2009), the controllers on the robots, even without a backup battery, would restart and reconnect to the control system in about 5 seconds after a power loss, and even this was deemed so unacceptable that the backup battery was required.

These days you can wait upwards of a minute or more for a complete restart and reconnect of a robot between the Rio and the radio, meaning if you loose power at any point, your robot is basically dead for the rest of the match.
Why FIRST ever thought dropping the backup battery requirement was a good idea is unfathomable to me.

it was for safety. battery dips caused weird behavior on that control system.
but yea i don't know why they got rid of it

[Alan Anderson]

We wouldn't have passed inspection if it was powered from the wrong place. We've got it running off the same rail as the VRM and PCM(which we don't have) on the PDP.

That is not the correct place to connect the roboRIO power. The VRM and PCM outputs have a green label and share a 20A fuse. The roboRIO power is a specific output from the PDP with a blue label and a 10A fuse.

[Robo Hamsters]

I suspect one of your CIMs is turning against the other. Unplug all breakers except one, run the drivetrain and note the direction. Repeat for all other CIMs. Let us know what you find.

Definitely check this. We have a 6 cim drive train and we were experiencing brownouts under heavy pushing. We found out one motor out of three on one side was wired backwards compared to the other two. Once we fixed that connection the brownouts stopped. Luckily that happened during testing and not at competition.

[ImOn3618]

That is not the correct place to connect the roboRIO power. The VRM and PCM outputs have a green label and share a 20A fuse. The roboRIO power is a specific output from the PDP with a blue label and a 10A fuse.

We're wired the same way as https://wpilib.screenstepslive.com/s/4485/m/24166/l/144971-wiring-the-2016-frc-control-system#!prettyPhoto
this. Which is correct.

[Alan Anderson]

We're wired the same way as https://wpilib.screenstepslive.com/s/4485/m/24166/l/144971-wiring-the-2016-frc-control-system#!prettyPhoto
this. Which is correct.

There is no disagreement. That picture matches the way I described it.

However, it doesn't match the way you described it. You said you had your roboRIO wired to "the same rail as the VRM and PCM(which we don't have)". While both the VRM/PCM power and the roboRIO power connections are ultimately connected to the battery+ connection of the PDP, they are separately fused. Robot rule <R42> requires that the roboRIO power is connected to the terminals specifically labeled for it, and <R44> separately prohibits it from being connected to the VRM/PCM power terminals.

[Al Skierkiewicz]

OK, I have to weigh in here...
If I had a nickel...
If you are browning out there are definite reasons for doing so. I can tell you most teams do not get everything in their primary wiring right the first time. I had more than twenty teams over the weekend with some kind of primary wiring issue. There were improper crimps, loose hardware, loose connection on the main breaker, etc. If you grab any #6 wire and wiggle it. If it moves of the connection moves, you have only found one problem. Keep going. Wire should not move around in a crimped terminal, or a screwed terminal. Hardware should never move, on the main breaker, PDP or battery. Loose means bad which leads to brownout. Sometimes your electrical problem could be a mechanical problem. Just ask if anyone has had issues with transmissions dragging, locking up or skipping.

[Mr. Lim]

As cmwilson13 notes, this is your problem.

It could be mechanical, but I suspect one of your CIMs is turning against the other. Unplug all breakers except one, run the drivetrain and note the direction. Repeat for all other CIMs. Let us know what you find.

As for mechanical: If you cannot easily turn the wheels by hand (robot off), disconnect things until you can. Whatever you just disconnected has a mechanical problem, for example a gear in backwards and rubbing the housing. Happens all the time.

Please do exactly what is stated above. Do not take any shortcuts.

Remove all your breakers from your drivetrain.

Put one in, check that the motor for that breaker is both:
a) running - a dead motor work will against you, and can cause potential brownouts
b) is running in the CORRECT DIRECTION - this is very likely the problem as you are browning out even when you are up on blocks. My best bet is that you have a gearbox with multiple motors going into to, and one of them is running in the wrong direction.

Remove that breaker, and install it on the next drivetrain motor. Do not install more than 1 breaker at a time when doing this check.

There are a lot of posts in this thread with a lot of "noise" but please ensure you do this 100% before moving on.

[philso]

Please do exactly what is stated above. Do not take any shortcuts.

Remove all your breakers from your drivetrain.

Put one in, check that the motor for that breaker is both:
a) running - a dead motor work will against you, and can cause potential brownouts
b) is running in the CORRECT DIRECTION - this is very likely the problem as you are browning out even when you are up on blocks. My best bet is that you have a gearbox with multiple motors going into to, and one of them is running in the wrong direction.

Remove that breaker, and install it on the next drivetrain motor. Do not install more than 1 breaker at a time when doing this check.

There are a lot of posts in this thread with a lot of "noise" but please ensure you do this 100% before moving on.

These are the most concise instructions that will likely locate the source of your problem.

The one other thing I would suggest would be to do a "pull test" on every wire connection to make sure every crimp is done correctly. I know you have stated "I can say with 100% certainty that our wiring is not the problem. The wiring is pristine, and correct." but you have not indicated how you have verified that your opinion is correct. I cannot count how many times I have been asked to look at "pristine" and "correct" looking crimps that, later, failed the pull test.

[evanperryg]

At the risk of getting another "Unnecessary Sarcasm Flag" thrown, I agree with this. This is CS101 Syndrome: "It's perfect, I did it!" Guess it applies to electrical as well... Get someone who isn't familiar with your wiring to examine it if you can. They'll be more able to find the problem easily than you are, because they don't think "Oh, that's normal" on something that might not be right.

If I could, I would print this out on wallpaper and cover the entire shop with it. OP, don't just check your wiring, check the wires themselves. You could have brownouts due to frayed wires or sketchy splicing. Check that you don't have motors fighting each other, and try replacing the motors, one at a time. My rule of thumb is that, if you can't put all of your weight into the connections on your robot, they're not good enough. I guarantee you that it is possible to make an entire electrical system that meets these standards; we do it every year.

[Ether]

The OP has not specified under what conditions the motors brown out when up on blocks.

I did not see any mention of how many motors are in his drivetrain or what drivetrain motor controllers are being used.

With e.g. 6 motors being commanded by controllers without voltage ramping, and given the high-motor-speed 4.75ft/s gearing, is it not possible to have up-on-blocks motor brownouts for step throttle changes from full forward to full reverse... even if all the wiring is correct?

[Fletch1373]

At the risk of getting another "Unnecessary Sarcasm Flag" thrown, I agree with this. This is CS101 Syndrome: "It's perfect, I did it!" Guess it applies to electrical as well... Get someone who isn't familiar with your wiring to examine it if you can. They'll be more able to find the problem easily than you are, because they don't think "Oh, that's normal" on something that might not be right.

I second the rubber-duck debugging technique.

TIL Software == Electrical