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

@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 Thanks for letting me know! I'll have to give it a try

@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

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

@tom that was from ubuntu 20.04. Looking back up the terminal history I see the install script stopped at: [ERROR] missing /data/modalai/sku.txt [ERROR] please run voxl-configure-sku to make a new one and didn't run the next setup steps. I didn't realize the flashing failed until seeing voxl-px4 couldn't start. And digging into that found this thread.

@tom yes that link worked fine, thanks

@Zachary-Lowell-0 Thank you for your reply. I will test it out and let you of any developments.

@Eric-Katzfey thanks! I got started using mavsdk and pymavlink

@Jetson-Nano If you want v1.15 then you just build from mainline, not from our fork.

@Judoor-0 I would recommend re-flashing the latest SDK from downloads.modalai.com Yes, /home/root gets wiped by default. When flashing a new SDK, /data is retained unless otherwise specified with a flag

@atomsmasher9 said in Ultralytics version for voxl-tflite-server yolov8: Reply Hi @atomsmasher9 - so ultralytics is leveraged for training - have you followed the instructions within this repository? https://gitlab.com/voxl-public/support/voxl-train-yolov8/-/tree/master?ref_type=heads Currently I have some updated written for this as well - so for example in export.py, this line: model.export("tflite") --> model.export(model = "tflite"), but I have yet to make the PR or commit for it - the README is relatively straight forward for how you can build a model leveraging docker, an nvidia gpu, and ultralytics to create the custom model. I was able to do these below and have a successful model created and uploaded to the voxl2 - ensure you place the model in /usr/bin/dnn directory alongside the labels.txt file to ensure you have the right labels - also you can manually update the file path in the conf file in /etc/modalai/voxl-tflite-server.conf.

(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

@Alex-Kushleyev I tried on a fresh VOXL2 that I factory flashed with 1.3.3 and did not see the same issue. Was probably something caused by my setup (either in config or something else). I know that particular voxl2 had damage to one of the mipi ports too I appreciate the help!

@giladWDS M0151 should expose /dev/ttyHS1 for use. It's just a UART so it isn't specific to external flight controllers.