Hi @jonathankampia, After running voxl-mpa-to-ros, you should see the /tflite_data and /tflite topics created as they just mirror the existing pipe names from the tflite-server. I am not sure what you are referencing with the tflite_detections topic, but if you could share the output of voxl-version, voxl-list-pipes, as well as a rostopic list with the two services running I can help debug.

@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