Awesome, thanks!

Hi @m1baldwin , are you using VOXL1 and VOXL2 ?

@Moderator Have you gone through this document here: https://docs.modalai.com/qgc-wifi/ ?

and also a simple example here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-tof.c?ref_type=heads

Hi @LucaVertiq , this is cool stuff. I am curious if you were able to do any direct comparisons of qvio performance using unfiltered vs low pass (rpm-based) vs notch (rpm based)? In order to replicate the same conditions for each test, this would have to be done using mpa playback after collecting mpa logs of just imu data and images. since the rpm data is not coming from mpa, it cannot be logged / played back using our logger. However, one idea is to process the IMU data logs using RPM logs using a separate script and then run the playback + qvio to generate new results. The IMU data processing can have different options like the rpm-based notch filter and it would obviously also need to have a px4 log that contains the ESC status. This also leads to a question, whether the IMU data should be filtered in the imu server or the application that uses the imu, since the requirements for the IMU data may differ for different applications, so it may be best to leave the IMU server publishing the original data. But also, there could be a separate output pipe from the imu sever with the notch filtered imu data.. Anyway, just wanted to check if you happened to get any quantitative results from your testing that show how the filtering helps with QVIO performance. My understanding from working with QVIO in the past was that the best thing to do was to feed unfiltered imu data into QVIO and let it integrate the noisy data. low pass filtering the IMU data too much would actually remove some of the actual components of motion that are important for motion tracking. So i am curious what exactly has improved in your case when you added notch filtering - is the drift vs distance improved or the number of VIO "blow-ups" has reduced? Lots of questions, but I am happy to discuss this further and see how we can improve performance of our VIO stack Alex

@LR I would recommend upgrading to the newly released SDK 1.4.1 from downloads.modalai.com Simply, download, untar, and run ./install.sh It'll retain any important calibration files and will re-configure the drone based off the SKU

@arcj , I don't think we have tried it but i believe the approach you are looking for is described here : https://developers.redhat.com/blog/2015/04/28/remote-debugging-with-gdb If you are looking to use a GUI-based debugger front end, it would have to be compatible with gdb. If you try this, let us know if it works! Alex

@brahim after looking at this some more I think it is valid to have multiple streams per camera. I guess the use case would be to have a high res stream and a low res stream that's separate or something like that. However I think people would still like to setup multiple cameras. I haven't tried this yet, but I think it could also be valid to spawn a manager per camera, and then stagger the component ids for each app. I think this might also fix the threading issue since each application would initialize separate pipe reads and wouldn't be blocked by each other? @Eric-Katzfey I'm using a different mavlink GCS that's not QGC, so I need to make voxl-mavcam-manager conform to the standard.

@Alex-Kushleyev @Eric-Katzfey can you check it out and help with the code. I am also interested what kind of signal is send to the neopixel LEDs to turn it ON. And with addition to that what is the command to turn ON only blue lights.

@Alex-Kushleyev Thanks for letting me know! I'll have to give it a try

@tom thank you for reverting , I sorted out the issue, the file name in the voxl-qvio-server was opencv_tracking_front_intrinsics.yml instead of opencv_tracking_intrinsics.yml and in the voxl-vision-hub the name was tracking_front which i renamed in tracking. After the above mentioned changed the voxl-qvio-server is working fine. thank you for the support.

@VSK said in Stuck installing ros-melodic-pcl-conversions: configure python-twisted-core:all 17.9.0-2ubuntu0.3 <none> status half-configured python-twisted-core:all 17.9.0-2ubuntu0.3 Maybe that package got corrupted on the install. Can you try running sudo apt-get clean? If that doesn't work, you could also try removing both of the packages and do the install again. $ sudo apt remove python-twisted-core:all $ sudo apt remove ros-melodic-pcl-ros ros-melodic-pcl-conversions

@Darshit-Desai , In short, the VOXL2 system image contains the main Linux OS that is built from open source components and it also contains open-source and closed-source components that are specific to Qualcomm hardware. Building the system image uses bitbake and a very long manifest which has a list of SW components, their exact version and source, as well as order in which the components should be built). you cannot use dd to back up and restore system partitions, as you may be able to do on a Raspberry Pi. Fastboot is the tool that is used to properly install the system partitions. voxl-suite is a collection of software that is installed on top of the base OS on VOXL2. For each SDK version, we also have a manifest of each component and version that should go into the SDK. Can you clarify which deb files you mean in its always annoying to install the deb files one by one and revving up the versions -- are you updating SDK or installing your some other deb files? It sounds like you may have per vehicle configuration (every set up is slightly different). You can differentiate the VOXL2 boards using the SoC serial number (cat /sys/devices/soc0/serial_number) and do your custom install based on the serial number. Basically you would have your own "manifest" of some type that may have common parts but also describe different settings for different boards (IP address, etc). You can maintain different bash files for each board and install them based on the serial number. Alex

@Judoor-0 Thanks for the contribution, this is very helpful!

@Zachary-Lowell-0 offboard mode: [image: 1737382725235-d5d4a98e-4bf0-4aa7-baee-522cb331b4a7-image.png] The drone does NOT arm from the ROS2 command but it can be armed with the RC 3)rb5:~$ voxl-inspect-services Scanning services... [image: 1737382905455-bea8dc77-6e7c-4635-b0b0-c7b9a5ec7676-image.png] 4)/usr/bin/voxl-px4-start [image: 1737383495210-466822e7-ff3f-4c08-a6c4-780b619665d0-image.png] Best wishes,

@Alex-Kushleyev thank you alex i'll try that

@tom Thank you. I'll look it up.

@Samuel-Lehman , Not sure what is going on but i was able to build your example with the following command on VOXL2. I had to comment out #include "hello_cross.h" because i did not have it. voxl2:~$ gcc -O2 -Wall voxl_io_uart_test.c -o voxl_io_uart_test -lmodal_pipe -lvoxl_io -L/usr/lib64 voxl_io_uart_test.c:14:12: warning: 'opt' defined but not used [-Wunused-variable] static int opt = 0; ^~~ voxl2:~$ I am not sure what's going on, you can enable verbose CMake file to see what compile command CMake is generating and compare that to the above. Alex