[BUG] raspberry pi 4b system crash

[TedHerman]

First, everything works well in Ubuntu on an X86_64. Now I am trying to port over to an RPi. I am unable to get depthai working on an RPi 4b. I saw in a recent issue that USB3 might be a problem, so I am using just USB2 with an Oak.

After going through the install instructions at docs.luxonis.com, then trying python3 depthai_demo.py, the expected window does appear with classification bounding boxes. However after a few seconds, a background window blanks out, no commands work, the filesystem appears to be corrupted, and the only way to terminate is detach power. Following a reboot, the depthai_demo won't even start, it gets trapped in a perpetual loop of XLink errors.

I have been able to reproduce this several times, each time starting with a fresh RPi install. I don't know what documentation to provide. Perhaps I should back off to earlier versions, but which ones are known to work with RPi 4b, and how should I install?

[Luxonis-Brandon]

Hi @TedHerman ,

Sorry about the trouble here. So I am expecting that the problem is actually the power source for the Pi, and if the Pi is then also powering DepthAI/OAK.

What are you using to power the Pi 4? And are you powering OAK off of the Pi or off of the wall-wart (in the case of OAK-D).

I'm guessing that a brown-out is occurring because the power supply used the Pi4 isn't quite enough to power everything. OAK can take up to ~5W.

Thoughts?

Thanks,
Brandon

[TedHerman]

Hi Brandon, I tried three things to narrow down the problem: 1. I happen to have an Oak-D as well, and it works (powered by its own power supply). Score one for your hypothesis? Except ... 2. Of course the Oak can't get its power except by USB. I happen to have a big power supply (25 watt) which I used to power the Pi, thinking the Oak can get plenty of current that way. It still crashed (counter to your hypothesis); but I also saw a message about "disk unmounted" flash by on the screen - and my root FS is on a flash drive via USB3, which hints at some USB-related source of the problem. 3. Then I reverted to the regular power supply (a Cana Kit 3A = 15 watt) with the Oak attached. Then I added the "-fusb2" to the command line. That did the trick, no crash, objects being classified by the Oak/depthai combo. I guess this means you can close off this issue. Sure hope I don't have to buy bigger power supplies on account of the Oak - hard to find items. Thanks for your speedy response. Ted.

…

On Mon, Mar 8, 2021 at 3:02 PM Luxonis-Brandon ***@***.***> wrote: Hi @TedHerman <https://github.com/TedHerman> , Sorry about the trouble here. So I am expecting that the problem is actually the power source for the Pi, and if the Pi is then also powering DepthAI/OAK. What are you using to power the Pi 4? And are you powering OAK off of the Pi or off of the wall-wart (in the case of OAK-D). I'm guessing that a brown-out is occurring because the power supply used the Pi4 isn't quite enough to power everything. OAK can take up to ~5W. Thoughts? Thanks, Brandon — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#342 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHCZSDOPFWKY44RVTDH6MLTCU3P3ANCNFSM4YZ54RNA> .

[Luxonis-Brandon]

Thanks @TedHerman ,

Great data here! So I think I actually figured it out from what you shared:

TL;DR: The Pi has a 1.2A limit across all its USB ports. So the sum of all the power on the Pi USB ports has to be less than 1.2A. I think this is what you're seeing with the USB drive and depthai/OAK on there.

So the Raspberry Pi limits the max current summed across ALL of its USB ports to 1.2A. So I think the flash drive + DepthAI/OAK when running at full USB3 speeds is actually peaking above this, hence causing the disk errors you are seeing as well.

So solid state media (e.g USB drive) doesn't take a LOT of power, but they do spike quite a bit. And the spikes will hit that 1.2A current limit on the Pi. So that is to the say, DepthAI/OAK + the USB drive are together spiking over the 1.2A max USB limit that the Pi has.

So this would also make sense why depthai/OAK/-D in USB2 mode seemed to work. The device will pull less power in this mode as the USB2 interface will actually block other parts of the pipeline (because of its lower data rate), effectively causing the device to use less power (as its calculating not as quickly).

Thoughts?

Thanks,
Brandon

[TedHerman]

Hi @Luxonis-Brandon. Presumably adding a powered USB hub would overcome Pi limitations. Not something I would want to do, since I am building a custom enclosure for the Pi/Oak combination (I've 3d-printed things for this already). The enclosure should be small, and adding a powered hub would be unpleasant. The USB3 NVME is needed for capacity; nice also for low cost & speed, so I'd rather not lose that (eMMC is iffy to source). I'll be building six of these units.

Your answer has an element of nondeterminism - that under USB2 regime, the speed reduces peak power resulting in the drive and Oak being under the 1.2A limit. Do you think this will hold true in production? I'll be using a custom model rather than the default model; I'll use the Python API rather than the onscreen demo. What factors might cause the OAK to draw more current within the USB2 mode?

Thanks,
Ted

[wasauce]

@TedHerman - Out of interest - what are you using the cam for? Any interest in sharing your enclosure? I'm considering a similar Pi/Oak combination for a semi-outdoor installation (outside my garage) but haven't gotten to the enclosure portion of working on things yet.

[TedHerman]

@wasauce The project will repeat the PPE detection, but go further to classify types of errors in wearing PPE. So far, for the enclosure, there is a stand for the Oak and a printed plastic bolt; also a stand on which the Pi sits. The stand and the Pi holder can be adhered to a box using screws or otherwise. The enclosing box will be just cut up sheets of polycarbonate glued together. Not sure this is the place to attach a photo.

[wasauce]

Thanks @TedHerman. Sounds like an interesting and helpful use case! Thank you again for sharing.

[Luxonis-Brandon]

Hi @Luxonis-Brandon. Presumably adding a powered USB hub would overcome Pi limitations. Not something I would want to do, since I am building a custom enclosure for the Pi/Oak combination (I've 3d-printed things for this already). The enclosure should be small, and adding a powered hub would be unpleasant. The USB3 NVME is needed for capacity; nice also for low cost & speed, so I'd rather not lose that (eMMC is iffy to source). I'll be building six of these units.

Your answer has an element of nondeterminism - that under USB2 regime, the speed reduces peak power resulting in the drive and Oak being under the 1.2A limit. Do you think this will hold true in production? I'll be using a custom model rather than the default model; I'll use the Python API rather than the onscreen demo. What factors might cause the OAK to draw more current within the USB2 mode?

Thanks,
Ted

Well said and great question. So before I forget, this product may be of quite a bit of interest:

https://shop.luxonis.com/collections/all/products/depthai-rpi-compute-module-4-edition

So it is depthai (OAK-D) with a built-in Pi CM4 on the back:

So this can run its onboard OAK-D (depthai) and also an offboard one all together. And the Pi CM4 can be ordered with eMMB built-in as well, to help a bit with the storage situation.

But there's enough power budget to power the onboard OAK-D, an offboard one, and the SSD. And especially so given that this board will allow as much USB power as you'd want, allowing making use of the 25W supply.

But to answer your question, yes, there is some non-determinism there. And I think it's the reason for the unpredictability that you have observed. I'm trying to think of the best approach here. So what I've seen online is to pull power from the GPIO pins on the Pi to bypass this 1.2A USB-power limit (here. So you could do that perhaps... not quite as clean though. I think this may be best though in this case, have the OAK-D power come from a cable plugged into the Pi GPIO 5V output for example (which is hard-wired to its input 5V, I think).

@wasauce The project will repeat the PPE detection, but go further to classify types of errors in wearing PPE. So far, for the enclosure, there is a stand for the Oak and a printed plastic bolt; also a stand on which the Pi sits. The stand and the Pi holder can be adhered to a box using screws or otherwise. The enclosing box will be just cut up sheets of polycarbonate glued together. Not sure this is the place to attach a photo.

Awesome! I've wanted to see something like this made with the platform!

So in terms of enclosures. I'm a huge fan of the polycase enclosures. And WRT pictures, yes, feel free to post here to your tolerance. Totally OK from our side at least (I do it all the time in issues/etc.). Here's a polycase enclosure used with Pi 3 and variable-baseline depthai (for longer distance):

And there are of course smaller ones you could get as well. They're pretty reasonably priced too. See more details here. (Which I just realized I never replied to, replying now!)

Thoughts?

[TedHerman]

Thank you for the information @Luxonis-Brandon - food for thought in future projects. Given what I have on hand, I'll try to use minimal, clean solutions.

But there's enough power budget to power the onboard OAK-D, an offboard one, and the SSD.
And especially so given that this board will allow as much USB power as you'd want ...

For the OAK-Ds that I have, my plan was simple: use an ample 5v power supply (say 25 watt) with output 5.5x2.5mm connector; connect to a splitter cable, then one end to the OAK-D and the other to an adapter going from 5.5x2.5 to USB-C. I have not tested this yet, but it seems like a logical thing to try. However first I am trying to work with OAK rather than OAK-D because the models for this project don't need depth (later projects will use depth).

You can see the yellow stand for the OAK, secured by a standard camera-threaded bolt I also printed. The Pi has a supporting stand with mounting holes, also 3d printed. For the enclosure, we don't want visibility into the box, and the box doesn't need great strength, so standard corrugated polycarbonate sheets will do the job, I hope.

You didn't respond specifically to my point about using a USB hub - I still guess that would work in a pinch.

[Luxonis-Brandon]

For the OAK-Ds that I have, my plan was simple: use an ample 5v power supply (say 25 watt) with output 5.5x2.5mm connector; connect to a splitter cable, then one end to the OAK-D and the other to an adapter going from 5.5x2.5 to USB-C. I have not tested this yet, but it seems like a logical thing to try. However first I am trying to work with OAK rather than OAK-D because the models for this project don't need depth (later projects will use depth).

Sounds great for OAK-D. I think that will work well (assuming I completely understand, and I think I do).

You can see the yellow stand for the OAK, secured by a standard camera-threaded bolt I also printed. The Pi has a supporting stand with mounting holes, also 3d printed. For the enclosure, we don't want visibility into the box, and the box doesn't need great strength, so standard corrugated polycarbonate sheets will do the job, I hope.

Looks great and sounds good to me!

You didn't respond specifically to my point about using a USB hub - I still guess that would work in a pinch.

Sorry I missed responding to that one. Yes, a powered USB hub will definitely do it.

[TedHerman]

@Luxonis-Brandon

Thanks re powered USB hub, as I thought.