QVIO does not perform SLAM, only visual tracking to aid in stability by tracking the velocity vectors of key points through a camera. https://gitlab.com/voxl-public/voxl-sdk/services/voxl-mapper performs mapping and planning. Data can be imported and exported through VOXL Portal with "Load Map" / "Save Map"

Interesting! I'll keep watching this thread for when you commit a proper fix in voxl-modem. For the meantime, my hack is working for me. Thanks!

@ahmed-mustahid Unfortunately the "QUSB_BULK" mode that your VOXL is enumerating in cannot be fixed by our unbricking process and will have to be sent in for an RMA. See here for info on the RMA process: https://www.modalai.com/pages/rma

@Maxim-Temp That image is also still in test.

@Eric-Katzfey Hi Eric. The jpeg compression imposes a lot of load on the CPU, especially we're using the hires camera. Is there any way you can make the HW jpeg encoding available for us to test it? Thanks!

@tom Ok, thanks!

@Adrian-Hidalgo I get it. But from the moment I am giving throttle the vehile starts wobbling and it increase. I am unable to fly it for a second.

@Adrian-Hidalgo @Dobry-Kolacz Thanks for your reply, so the drone uses QVIO to control the altitude (I think it uses barometer or something else) which perfectly explains why the altitude sometimes drifts as our floors are a bit lacking in texture. I'll try adding some texture to the floor and give it a try. Thanks.

Yes, the service doesn't need to be enabled on voxl/voxl2 (the configure-mpa script will enable the correct imu server for whichever platform you're on)

@Chad-Sweet Thanks for responding to my post. is 32 GB the limit of what the VOXL can take as far as SD card size is concerned? Also, by auxiliary computer I mean an FPGA that is interacting with the VOXL/PX4. Regards

Hey @Patrick-Hinchey would you please send that board in for an RMA diagnostic. Details on our RMA process are here Before shipping the unit, please purchase an RMA via the link above and fill out the RMA form here. If you have any questions please let me know. Thank you!

@Maxim-Temp Also please upload the voxl-cross docker image v2.2 .

@Ed-Sutter That is correct, modemmanager is not used. As you can see in the patch here: https://gitlab.com/voxl-public/system-image-build/meta-voxl/-/blob/master/recipes-kernel/linux-quic/files/qmi_wwan2.patch The path to the qmi_wwan.c file that is being modified / used is drivers/net/usb/qmi_wwan.c

@hmlow I believe this is normal. You're utilizing some CPU hungry programs so they would indeed spike the CPU load. @modaltb @Vinny can chime in on this

Ok... whatever you did seems to have fixed it. Thanks

@Steve-Turner voxl-build allows you to build the kernel only which you can then flash on top of an existing system. Qualcomm licenses are required in order to build a full system image.

@modaltb This worked for me. Removing the USBC cable, booting up, and then plugging in.

Hey @ahmed-mustahid, pipe_client_send_control_cmd is a function provided by libmodal-pipe that you could use from another C/C++ application (not within voxl-mapper) to send commands, thats likely why you didn't see it. As for the syntax of the plan to command, messages are constructed as such: const msg = "plan_to: " + (pos[0] + plan_pt.position.x) + "," + (pos[1] + plan_pt.position.y) + "," + (pos[2] + plan_pt.position.z); i.e. message starts with "plan_to: ", and is followed by a comma separated (X,Y,Z) point. If you can follow this syntax you should be able to send commands using whichever method works best in your workflow.

@Steve-Turner Glad to hear you were able to make substantial progress!