So this past weekend we fried our Orange Pi with a DC DC converter that had a big voltage spike on power up (was not USB-C and as I’ve now read the orange Pi doesn’t have much protection built in). So we are planning on using this now.
And hoping it’s better. Does anyone have experience with something like this?
Second question is: if our battery voltage dips to 7V for a short time, will the Orange Pi reset? There’s not much info on this DC-DC but I have to assume it’s going to have trouble keeping the 5V when the input drops fairly low.
The buck regulator in your link is specified for an input voltage range of 8-23 volts. Without knowing more about what’s in the box, all bets are off at input voltages under 8 volts. There are 5V buck regulator designs out there that will stay in regulation with only a 6 volt input. That’s about as good as you’ll get without the complexity of a buck/boost regulator.
It claims to have under-voltage protection and so far we’ve not seen any problems with the orange pi when you have those voltage drops from the drivetrain etc. Hopefully it holds up for us.
There’s a lot of cheap regulators on Amazon with widely varying quality. They’re good enough for certain things, but coprocessors need ample amounts of good, stable power, and quality regulators don’t cost much more. We’re fans of the Pololu line of regulators because they’re small, reasonably priced, have good specs, and in our experience are reliable. They’re our go-to for regulating power to Ethernet switches, sensors, coprocessors, and other critical things.
Thank you for that suggestion. I was stuck on the DC-DC but the linear regulator makes a lot of sense. I doubt the pi is averaging 2A anyway so it’s not a huge hit on the power budget.
There seems to be some confusion here. The Pololu product is not a linear regulator, it’s a buck converter (a form of switching regulator). It’s the same technology as in the other converters you linked, but a high quality implementation from a known vendor.
Power budget has more to do with the number of OPi boards and how heavily you’re loading them vs. the specific regulator you’re using to run them. The Pololu regulators are, per their specs, about 92-95% efficient in the load range you’d be using. This is likely higher than the Amazon ones, but it’s hard to know since those don’t generally provide detailed specifications.
[Edited to add: relative to power-hungry robot motors, a single coprocessor’s power consumption is a rounding error - even at 4A, which you probably won’t see, that’s ~20W. You might notice it impacting your idle power draw, at most.]
The 4091 is nice because at the 12V input range, it can provide 8A, which is enough to run 2 OPi5 boards (should you ever need to do that). Pololu makes smaller, possibly cheaper versions that could be enough for one board, but I would not go below 4A capacity to avoid issues.
The board calls for 4A, but honestly, 3A is probably OK as long as you’re not using a lot of power-hungry things plugged into the USB ports - each camera usually isn’t more than a couple hundred milliamps. I’d try it under expected maximum-load conditions just to make sure, of course, but it’s probably going to be perfectly fine.
My team is using this external power supply instead of using the robots battery, and it seems to be going pretty well for us so far. The main benefit of it, from what I know, is that no matter the battery voltage, you can keep the OPi 5 going no matter what, as long as the power pack is charged.
If you’re going this route, pay close attention to the Q&A items relating to USB battery packs and PD/QC protocols (that may allow for operating outside the specified limits). E.G. Q138 and Q177 which is currently pending an answer.
I will second the Pololu 4091 D36V50F5. We are running two cameras - the OV9281 for AprilTags and a LifeCam for object detection. Our object detection pipeline kept crashing, and we traced the issue to power. We switched to the D36V50F5, and all our issues went away.
I was surprised a power issue could manifest like this. I figured the co-processor would just shut down - I never thought a pipeline would become unstable. I guess the NPU has needs. In any case, if you want to avoid weird issues, get the D36V50F5 and be done with it.
Answer to Q177 has been updated. Basically, as long as the actual output of the battery is 5A/5V or lower, it’s legal. But, if the battery itself is capable of exceeding either 5A or 5V, then it’s up to the team to demonstrate that it’s not actually exceeding those values.
I would think that this means bringing documentation for the powered device showing what it negotiates to.
It’s kind of weird that the update to this answer came out the same time as the team update but was not mentioned in it, especially considering the original answer refenced a team update. Edit: It is mentioned, I didn’t look close enough.
While I would love to see proper USB-PD utilized more on robots, this answer is definitely great news since it allows for modern and higher-end power banks.
In anticipation of a ruling along these lines, I picked up a few of this power bank from Amazon for my team: https://www.amazon.com/dp/B0C2ZB2BNB
It is the larger version of the one linked by @Napkino above. With this update, I can now recommend this as a great USB power bank option for FRC use. It is just under the 100Wh limit with a capacity of 92.5Wh, and my testing shows that the claimed capacity is realistic. Plus it has a screen that shows % remaining, output voltage, output amperage, and time remaining until charged or discharged. The one con is that the stated amperage limit is only 3A per port which is slightly lower than the smaller version.
For USB-PD device of unknown voltage teams could use a USB power meter like this one to show what voltage is being negotiated or even just force the voltage to 5V with the switch on the side.
I more meant as a good voltage regulator that could be used for both the coprocessor and the LEDs (we’re actually using that exact voltage regulator but at 10A right now and I’m wondering if that’s what the problem with object detection dying on us is)