@bendraper in other words, what factors/scripts affect the generation of that conf file?

Hi @Anubhav , Docker should natively work on VOXL2... so the voxl-configure-docker-support shouldn't be used at all on VOXL2.... Should be able to use this directly: https://docs.docker.com/engine/install/ubuntu/ If VOXL2 isn't booting... you can reflash with the platform release, and please just don't run voxl-configure-docker-support (and we need to fix this script to not run on VOXL2.....) To reflash: https://docs.modalai.com/platform-releases/#install

@Adrian-Hidalgo I redesigned the mounting piece for the cameras, used new refocused cameras, and fixed some errors in my general camera extrinsics file (although I'm not sure that last one is related)

It seems no data has been received by modal_esc module, but it also seems that the ESCs have not been armed yet. Let's try to query the individual ESC version information: modalai_esc -i 0 version and modalai_esc -i 0 version-ext (you can replace -i 0 with ESC ID 0..3) These commands will explicitly send a request to each ESC and get information about its version and should print. version-ext is the extended version information, but basic version command should be sufficient for checking communication.

@Dobry-Kolacz I think I'm getting close. Im pretty consistently getting a reprojection error ~0.6 at this point so still have yet to successfully calibrate stereo extrinsics. Tried new stereo cams, refocusing, different lighting, different scales of checkerboards, but can't get sub 0.5

Hi Tamas, it seems like something you could add to voxl-mpa-to-ros?

After some digging, I came across the qtiqmmfsrc GStreamer element. If I use this to get the video stream at 4000x3000 (video/x-raw, format=NV12), I get the same distortion shown above. However, if I request the H.264 stream (video/x-h264, format=NV12), I get a clear picture. Below are the pipelines that I tested using the IMX412. # Distorted Output gst-launch-1.0 -e qtiqmmfsrc name=qmmf ! video/x-raw,format=NV12,width=4000,height=3000,framerate=30/1 ! \ omxh264enc control-rate=2 target-bitrate=6000000 ! h264parse ! \ matroskamux ! filesink location=43_raw.mkv # Good Output gst-launch-1.0 -e qtiqmmfsrc name=qmmf ! video/x-h264,format=NV12,width=4000,height=3000,framerate=30/1 ! \ h264parse ! \ matroskamux ! filesink location=43_h264.mkv On a side note, the video's white balance from qtiqmmfsrc is better than when requesting images through voxl-camera-server. The video is extremely warm when delivered through voxl-camera-server, though I admit that I never looked into the configuration for this. In any case, it looks like this is maybe an issue with Qualcomm's libs. I haven't yet looked further into the voxl-camera-server source, though I don't suppose there's been an update to the qmmfsrc or related libs that can be updated on the VOXL2, is there?

Yes, those servers were disabled. The QVIO server was running. You can download the log here. please note the modified info.json file which was used to replay only the IMU and the camera data.

1,000,000 bps (1Mbps) seems low for a FHD stream. What bitrates did you try? Did you try increasing it to 10,000,000 or even 30,000,000 to see if that makes a difference? I'm running 1920x1080 @ 20 FPS with no major artifacts using this. The alternative would be either changing resolution or trying to switch to a different codec such as H265 or VP9 (which appear to be supported on the VOXL2 by just searching the gst-inspect-1.0 output), but that would require changes to the voxl-streamer source.

Regarding voxl-configure-docker-support, I tried and was unable to replicate it causing VOXL not to boot. voxl-configure-docker-support isn't strictly necessary, it's just a handy tool to apt-install docker-ce from the internet and replace the official docker systemd service with one that we tweaked for VOXL. I did find that the optional docker-autorun service was not starting on boot, that is now fixed in voxl-docker-support v1.2.5 If you are still seeing voxl-configure-docker-support preventing voxl from booting I can look into it more if you provide a full copy/paste of the output from running that command. Perhaps something is different between our configurations.

voxl-replay should be working on VOXL 2.

Understood. Thanks, Chad.

Right now we just support QTY. 2 TOF on VOXL 2. We will look to add more in the future.

@Chad-Sweet I haven't tried. However, I manage to get it working by doing a factory reset configuration of the VOXL2. Don't know why it made a difference though.

Yes, of course. VOXL 2 is a Debian Linux single board computer with tons of I/O. Check out the data sheets at https://docs.modalai.com/voxl-2 and there are many options for connectivity and a complete development environment for you to write code to build the capabilities required for your application

[image: 1671029064348-whatsapp-image-2022-12-14-at-15.29.48.jpeg] Here is the weight in a balance with and without power module. [image: 1671029207466-whatsapp-image-2022-12-14-at-15.46.24.jpeg] For our application, we will change the huge 12AWG cables and XT60 connectors for short 18AWG cables and XT30 connectors. Eloi Vilalta

Hi @Eric-Katzfey, We had some finds. Here's what we've understood so far: Two things are needed to make a voxl-px4 package using px4-firmware(voxl-dev) modalai_rb5-flight_default modalai_rb5-flight_qurt And each one needs the following different crsf_parse function modalai_rb5-flight_default needs crsf_parse(6 arguments) modalai_rb5-flight_qrut needs crsf_parse(8 arguments) Each px4-firmware has a different version of crsf_parse Branch: main has crsf_parse(6 arguments) Branch: voxl-dev has crsf_parse(8 arguments) Our goal was to build the voxl-px4 included MicroRTPS_bridge in px4-firmware(branch: voxl-dev), so we added the following two functions to crsf.cpp in px4-firmware. bool crsf_parse_buffer(uint16_t *values, uint16_t *num_values, uint16_t max_channels) as crsf_parse_buffer_6 bool crsf_parse(const uint64_t now, const uint8_t *frame, unsigned len, uint16_t *values, uint16_t *num_values, uint16_t max_channels) as crsf_parse_6 Then the build progressed to 89% and stopped with an error below. ERROR #1 [ 89%] Building CXX object src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/pwm.cpp.o /usr/local/workspace/px4-firmware/src/systemcmds/pwm/pwm.cpp: In function 'int pwm_main(int, char**)': /usr/local/workspace/px4-firmware/src/systemcmds/pwm/pwm.cpp:810:3: error: 'qurt_loop' was not declared in this scope 810 | qurt_loop = 320; | ^~~~~~~~~ compilation terminated due to -Wfatal-errors. make[3]: *** [src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/build.make:63: src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/pwm.cpp.o] Error 1 make[3]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' make[2]: *** [CMakeFiles/Makefile2:12085: src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/all] Error 2 make[2]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' make[1]: *** [Makefile:152: all] Error 2 make[1]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' make: *** [Makefile:222: modalai_rb5-flight_default] Error 2 We changed the int qurt_loop variable's scope to like this. Before [image: 1670957157167-32b86fac-1631-4048-b2ce-a29792ee533b-untitled.png] After [image: 1670957171221-f6a25f03-3c63-4f66-92e4-b3181adacef6-untitled-1.png] After that, an error occurred for the label for jump, and it was resolved by changing it as follows. ERROR #2 [ 89%] Building CXX object src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/pwm.cpp.o /usr/local/workspace/px4-firmware/src/systemcmds/pwm/pwm.cpp: In function 'int pwm_main(int, char**)': /usr/local/workspace/px4-firmware/src/systemcmds/pwm/pwm.cpp:864:1: error: jump to label 'err_out_no_test_2' 864 | err_out_no_test_2: | ^~~~~~~~~~~~~~~~~ compilation terminated due to -Wfatal-errors. make[3]: *** [src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/build.make:63: src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/pwm.cpp.o] Error 1 make[3]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' make[2]: *** [CMakeFiles/Makefile2:12085: src/systemcmds/pwm/CMakeFiles/systemcmds__pwm.dir/all] Error 2 make[2]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' make[1]: *** [Makefile:152: all] Error 2 make[1]: Leaving directory '/usr/local/workspace/px4-firmware/build/modalai_rb5-flight_default' So we changed the goto command to "return 0" instead of using err_out_no_test_2 label. After that, the build.sh worked and the make_packages.sh also worked.(in the voxl-px4) However, it did not run with the following error on voxl2. ERROR #3 voxl2:~$ voxl-px4 Found DSP signature file /usr/bin/voxl-px4: line 42: /usr/bin/px4: cannot execute binary file: Exec format error Based on the above results, we think the voxl-px4 with microRTPS_bridge can be built by changing modalai_rb5-flight_default and modalai_rb5-flight_qurt to use the same crsf_parse. So if you think our thinking is correct, can you give us some guidance? If it is not possible in px4-firmware(branch: voxl-dev), can we build voxl-px4(included micrortps_bridge) using another branch? Any advice would be appreciated.

MPA Config took care of it.

Hi @tom, Thank you for your help, I got it going and is now back to a usable state!