Topics created by Rowan Dempster

(top is Royale 4, bottom is 5)

@Rowan-Dempster ,

I myself tried to do this some time ago and ran into issues, which i could not resolve. I am sure also someone else at Modal also tried it before me.

If I remember correctly, my issue was that it could not get camera module in the second instance of the camera server, on this line, and i did not pursue this further (did not spend too much time on it though).

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/master/src/hal3_helpers.cpp?ref_type=heads#L79

So in your case you are able to get the camera module?

To help debug, you should run logcat while you are trying this and see what messages might show up there.

And, finally, just wanted to mention that we don't know if what you are doing is possible, but if you want to keep pursuing this direction, I can help if i know the answer to your questions, but may not be able to spend time working on it right now.

EDIT: in order to see if separate instances of camera server are possible, you could try to see if you can run multiple instances of gstreamer plugin that uses qmmfsrc. I found a doc that should be helpful in testing this, take a look : https://thundercomm.s3-ap-northeast-1.amazonaws.com/shop/doc/1596593567074634/Thundercomm EB5_Multimedia SDK User Guide_V1.1_ie89e.pdf

Specifically, the following command should work, although i did not test it:

gst-launch-1.0 -e qtiqmmfsrc name=camsrc ! video/x-raw\(memory:GBM\),format=NV12,width=1920,height=1080,framerate=30/1 ! queue ! omxh264enc control-rate=max-bitrate target-bitrate=6000000 interval-intraframes=29 periodicity-idr=1 ! queue ! filesink location="/data/vid.h264"

Also, i dont see how you sent the camera id in this example, but it should definitely be possible 🙂

See if you can run two independent instances of gstreamer using different cameras. I think it should work, but not sure.

Alex

@Rowan-Dempster I think it is safest to just not use data that reads 0,0,0 as the sensor cannot measure that close anyways

About 95C is when the temperature control loop will kick in and start reducing the maximum core frequencies (gradually). You can monitor the cpu usage and current core frequencies using voxl-inspect-cpu.

Here are the maximum core frequencies for all cores:

cpu0 1804.8 cpu1 1804.8 cpu2 1804.8 cpu3 1804.8 cpu4 2419.2 cpu5 2419.2 cpu6 2419.2 cpu7 2841.6

If you set the cpu governor mode to perf (voxl-set-cpu-mode perf), it will pin all the cores to max frequency and they will stay there unless they are being throttled due to temperature, which you can check using voxl-inspect-cpu.

@Rowan-Dempster Mainline PX4 now works on VOXL 2. It hasn't received that much testing yet but you are welcome to try it out.

@Rowan-Dempster No, it isn't

@Rowan-Dempster They've been released and are a part of the SDK but we just don't install them by default to save space.

The .debs are onboard already and should install with an apt install

In that context "blackisted" just means don't install by default.

@thomas I assume we don't want to be dealing with 4k raw arrays on the CPU for performance reasons. So yeah as early as possible in the image proc pipeline, and how early we can push it is what I'm asking for advice on. We'll also reach out to @Alex-Kushleyev thanks!!

@Rowan-Dempster, i looked through the changelog of our project (https://gitlab.com/voxl-public/voxl-sdk/third-party/voxl-eigen3/) and it does not look that there are any changes done to eigen3 itself, i think it is just a package we inherited from VOXL1, which did not use apt.

If you are willing to try it, remove voxl-eigen3 package (which may temporarily break something - note which packages require it). We could potentially update whatever gets broken to be happy with either voxl-eigen3 or eigen3 installed using apt.

Hi Rowan,

There is no one answer, it is entirely dependent on your circumstances. auto will be more conservative than perf. perf is intended to go as fast (and hot) as possible

if CPU was causing the issue, then you would see slower FPS, not degraded performance.

This sounds like the actual TOF sensor is heating up and at some point starts throttling itself by reducing the emitted power, which helps cool it down.

You could test it by selectively cooling TOF sensor (and not voxl) and see if performance goes back up.

@Rowan-Dempster If the packages you're looking to include are small I can look into getting them into our default system image. Otherwise yeah we may have to discuss other avenues for supporting a custom system image (not a decision that I can make personally)

Also most python packages are available via. apt with something like apt-get install python3-numpy

I narrowed it down to the ToF. I can run all the cameras in C17 (hires, tracking, stereo) except the ToF and no issues stressing the CPU. When I enable the tof in the camera server I cannot stress the CPU.

I have also found that using stereo:ov7251:3:4 instead of stereo:ov9782:3:4 works.

Hi Rowan, we do not provide source to libmodal-cv

@tom That fixed the CPU usage issue, thank you!

No, it is not the latest.

It's a few months of work on our end to update the SDK. We may try it later this year, but no formal plans to do so