Should I upgrade?
-
@Eric-Katzfey By the way, regarding "upgrading"... All I did was opkg update; opkg upgrade. I really don't know what all that updated (aside from /etc/modalai/voxl-streamer.conf); but the output of "voxl-version" didn't change at all.
Based on that it appears I'm running with a system-image that was built on 2021-06-06 (about 15 months ago). Is that the most recent? -
@Ed-Sutter We are preparing a new VOXL platform release but are still completing an update of our ToF camera support. Once that is complete the release will go out.
-
@Eric-Katzfey Ok, no rush (just curious)... Is that updated by the same procedure (opkg update; opkg upgrade)?
-
@Ed-Sutter No, there is a bash script to handle it. The opkg method is good for SDK and package updates but the full platform release also contains a new system image that needs to be flashed via fastboot.
-
@Eric-Katzfey Update regarding the intermittent frame size when using the MS-1080P-HD camera... I pulled down the latest libuvc code from github and built it on my Ubuntu 18.04 machine. I was then able to run uvc_test on that camera and it always came back with the same (correct) frame size.
Is there any chance that the libuvc version you guys have on voxl-public is a bit out-of-date? -
@Eric-Katzfey Just to gather a little more data, I took the voxl-libuvc code and built it on Ubuntu18.04. Then I ran uvc_test with the MS-1080P-HD camera and it worked fine.
To do this I cloned libuvc and voxl-libuvc, then prior to building libuvc, I copied all the source files (*.[ch]) from voxl-libuvc to libuvc. This allowed me to use voxl-libuvc source code, but still build on a native ubuntu host.
Anyway, that eliminates voxl-libuvc from the suspect list. Since voxl-uvc-server's callback is fed the frame size, that kinda points to the driver as a possible suspect.
Any thoughts?
If interested, I can post the script I used to do that build.
-
@Ed-Sutter What is uvc_test?
-
@Eric-Katzfey Its the output of building test.c which is part of the libuvc code. It just uses libuvc to grab frames and they are pushed to the console with OpenCV.
-
@Ed-Sutter It looks like it prints the length each frame. Do you see it show same frame length each time or does it ever change?
-
@Eric-Katzfey Yes, it does print every frame, and it is consistently (i.e. always) 614400 in my case.
-
@Eric-Katzfey I modified the voxl-libuvc/build.sh script so that it would build the uvc_test (from test.c) program I mentioned earlier. Refer to the README.md file in the original libuvc code)...
cmake ../libuvc -DBUILD_TEST=ON -DBUILD_EXAMPLE=ON
The test.c code uses opencv to display to a monitor, so I also stubbed that code out so that the callback simply prints the received frame size.
With those changes I was able to install the uvc_test program on my Voxl Flight Deck and I see the same inconsistent frame size. That eliminates any suspicion of a problem with voxl-uvc-server code; and since this works correctly on a standard x86 linux machine, this points to the driver. Are there any open issues with this that you are aware of?
-
@Ed-Sutter Thanks for the testing! No, I am not aware of any issues.
-
@Eric-Katzfey Just an FYI... I have been experimenting with libuvc on my host machine and I do notice occasional incorrect incoming frame sizes. So my earlier assumption that this only occurs on VOXL is false.
-
@Ed-Sutter Okay, thanks! That's good to know. And really appreciate the investigation!
-
@Eric-Katzfey so why i bought VOXL Flight Deck month ago with 3.3.0-0.5.0 version? it was difficult for your team to upgrade to new version before sending? wonderful service for 1000$. im 2 weeks trying to get video streaming to qgc. Result - 0.
-
@Anton-Gereles If you have a specific question that we can help you with please open a new forum post and we'd be more that happy to help get you going.
