@SMRazaRizvi in order to arm drone in offboard mode, px4 must be first able to arm in position mode. i would recommend checking if this drone arms in position mode (not manual)

@Matthew-Wellner, The ESC params should have min_rpm parameter set to the minimum RPM that you obtained during your tests, specifically the RPM that motor spins when you send ./voxl-esc-spin.py --power 10 command, as 10% power is pretty much the minimum you would want to use on the ESC itself. Then you make sure your PX4 params also use this value for min_rpm for the following param: VOXL_ESC_RPM_MIN , however you also want to make sure the max_rpm ESC param corresponds to VOXL_ESC_RPM_MAX in PX4 params, otherwise the rpm range will not work correctly in PX4. You should also do some sanity checking. Knowing your propeller's thrust vs rpm curve helps a lot. Then you can check the commanded / actual motor RPMs versus your vehicles weight. It is possible to build a very lightweight vehicle, such that even small amount of thrust % would result in above hover thrust. You typically want to avoid those situations because it would be hard to achieve stable flight. Finally, you should check your px4 log, you could load it here to generate plots, including actuator commands and reported RPMS and you can check if those RPMs make sense. https://review.px4.io/ . Please take note that this is a public site.

@Moderator Thank you for reply. This connecter is not working. [image: 1706060134869-9bb90eef-d3df-44a6-9311-3521bcc67dca-image.png] I connect usb3-camera device into this connecter, but not recognized. I checked to using bellow commands lsusb: did not add new device. dmesg: did not output new kernel messages(info. warn error etc.). When using Cable USB3 10-pin JST, usb3-camera device is recognized and working. So I think hub IC and peripheral circuit are working.

@Evan-D , VOXL m500 uses VOXL1 computing board, which comes with a wifi module on board. The wifi module can be configured in SoftAP mode (access point) or station mode. If the ground sensors have wifi access points, then once m500 gets close to the access points, it can connect to those access points. Alternatively, m500 could be an access point and once it is within range of the ground sensor, the ground sensor could detect m500 wifi SSID and connect to it.

Unfortunately, there is no publicly available documentation or technical paper that specifically details the lead data enrichment fusion routines and their underlying mathematics used on the VOXL flight board's IMU and cameras. This information is often considered proprietary by the manufacturers or research institutions involved in the project. However, some resources might help understand the general principles and approaches used in sensor fusion for attitude estimation and motion tracking: PX4 Autopilot Documentation: The PX4 Autopilot is an open-source autopilot system commonly used in research and hobbyist drones. It implements sensor fusion algorithms for various sensors, including IMUs, magnetometers, GPS, and optical flow sensors. While not directly related to the VOXL flight board, the PX4 documentation provides a good overview of sensor fusion concepts and the underlying Kalman filter and complementary filter techniques. You can find the relevant documentation here: https://docs.px4.io/main/en/ Research Papers on Sensor Fusion: Several research papers have been published on the topic of sensor fusion for attitude estimation and motion tracking. These papers often discuss different algorithms and their mathematical formulations. "Sensor Fusion for Attitude Estimation: A Tutorial" by Mahony et al. (2008): https://arxiv.org/pdf/1912.13077 "A Comparative Study of Kalman Filter and Extended Kalman Filter for Attitude Estimation" by Julier and Uhlmann (1997): https://www.researchgate.net/publication/269254094_Extended_Kalman_Filter_vs_Error_State_Kalman_Filter_for_Aircraft_Attitude_Estimation "Real-Time Attitude Estimation from Gyroscopes and Accelerometers" by Madgwick et al. (2011): https://arxiv.org/pdf/2002.10205

Thank you!

@tom Thanks - that worked.

Yes, the M0014 from the flight deck replaced M0072+M0008 and are identical from an electrical standpoint

@Abdullah01 , OK this is strange. So it seems like all the cameras are functional, because originally you were able to detect TOF and Hires camera, but not tracking camera. However, now you can detect hires and tracking but not TOF. I am not sure why this is happening. Are you able to do a clean install of SDK 1.1.2 and follow the same configuration option as you originally tried (TOF + Hires + Tracking). Make sure to plug the cameras as instructed here : https://docs.modalai.com/voxl2-camera-configs/#c-14-tof-hires-and-tracking

@lattanze , we are not 100% sure, but most likely not. This has never been attempted / tested and unfortunately we cannot provide support for this feature.

Hey Eric, so I ruled out the dsp as the problem since I am getting the same behavior on an nxp nuttx-flashed board. It appears the external device is the issue as it is not responding to i2c commands. From what I can tell qurt uses the same I2C 'transfer' command at least with the same parameters. It can find the device on the bus when I give the command "qshell xm125_evk start -X -b 4" but probing it appears to be impossible right now.

@david-devassy Hey David, We do support deep learning inference on VOXL2! You can check out this page on our docs to read more about our deep learning capabilities. Out of the box our YoloV5 model gets around 30 frames per second. You also mention object avoidance and SLAM using path prediction. We have our own implementation of Visual Object Avoidance (VOA) which you can read about here. You could certainly create custom implementations of both of these on VOXL! However I want to highlight that our code for both of the above is C/C++ and not in Python for speed reasons. I can't give you a reasonable estimate about Python performance but it would likely be slower. Hope this helps! Let me know if you have any other questions. Thomas Patton thomas.patton@modalai.com

@Vinny Thank you very much for the reply, it is quite helpful. We will review the doc links again and take the lead times into account when making an order. We look forward to our evaluation of these systems.

@Alex-Kushleyev Thaaaaaaaank you very much. It worked INFO: ESC Information: INFO: --------------------- ID : 0 Board : version 34: ModalAi 4-in-1 ESC (M0117-1) UID : 0x2037343356435707003E001E Firmware : version 39, hash eb6fb500 Bootloader : version 183, hash 25317f42 Params : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml ID : 1 Board : version 34: ModalAi 4-in-1 ESC (M0117-1) UID : 0x2037343356435707003B0022 Firmware : version 39, hash d4fe8e3d Bootloader : version 183, hash 25317f42 Params : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml ID : 2 Board : version 34: ModalAi 4-in-1 ESC (M0117-1) UID : 0x2037343356435707003C0019 Firmware : version 39, hash eb6fb500 Bootloader : version 183, hash 25317f42 Params : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml ID : 3 Board : version 34: ModalAi 4-in-1 ESC (M0117-1) UID : 0x2037343356435707003A0057 Firmware : version 39, hash d4fe8e3d Bootloader : version 183, hash 25317f42 Params : ../voxl-esc-params/mavic_mini_2/mavic_mini_2.xml --------------------- successfully pinged ESCs disabling bridge bridge disabled DONE

@nickyblanch thank you so much for the great write up! We accept pull requests if you think there is a bug or worthwhile improvement.

@aharvey I believe TFLite Delegate logic is available only in C++ per TFLite Sources. Likely you would want to implement your inference code in C++ anyways as on VOXL your inference times will likely be much faster than in Python. We have some example of assigning delegates inside our voxl-tflite-server source code, check out these lines: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tflite-server/-/blob/master/src/inference_helper.cpp#L216 Hope this helps, Thomas thomas.patton@modalai.com

Hi @Eric-Katzfey eventually we managed to solve the problem by resetting to default the parameter of px4 and performing the calibration from qgc