In fact, I think the whole voxl-mavlink-server scheme to set the system time from the SYSTEM_TIME mavlink message is fundamentally flawed for the case when PX4 is run on SLPI. The SYSTEM_TIME message emitted from voxl-px4 uses the system clock of the apps processor as it's time basis. So essentially, it either

never changes the system clock if the offset between SLPI monotonic clock and apps monotonic clock is less than ten seconds continually sets the clock to either the future or the past by the offset of the monotonic clocks in the case where the offset is greater than 10 seconds

It seems like this system should really be based on GNSS clock time instead of the SYSTEM_TIME message for this setup.

@tonygurney See here for adb install instructions and debugging tips:
https://docs.modalai.com/setting-up-adb/#setting-up-adb

The udev rules at the bottom may solve your issue

Hi @taiwohazeez,

The " /fmu/in" prefix is used for sending data to the autopilot - you're never going to receive data from the autopilot listening to that topic.

Look at the "/fmu/out" topics to see messages coming from the autopilot.

Best,
Ted

@Jetson-Nano Can you please start a new thread for this new topic?

@wilkinsaf

Yes this is definitely possible You would need to modify flow-server and possibly feature-tracker to ensure this is pointed at the right pipe Might also need a bit of calibration here and there Have not tested having multiple versions of flow-server, but should be possible. Would need to ensure this works with a downard facing tof for accurate height estimate

To get a rough draft of this working, would take ~2 days

@Alex-Kushleyev would you be able to help troubleshoot this error with the rear tracking camera?

@Alex-Kushleyev

Thanks for the advice! Sorry for the delay in following up. Dan and I are on the same team and I currently have the physical drone in my possession.

I've attached a video of what the motor spinning actually looks and sounds like. The motor you see is actually a replacement, and the behavior is the same. It appears we may actually have an ESC issue or an issue at the connection point between the motor wires and ESC.

The video shown is the result of running:

voxl2:/usr/share/modalai/voxl-esc-tools$ python3 voxl-esc-spin.py --id 1 --power 15

Modal AI Starling 2 Max - Motor Spin Test Video

When running the voxl-esc-verify-params.py script, the output shows that params are all matching:

voxl2:/usr/share/modalai/voxl-esc-tools$ python3 voxl-esc-verify-params.py Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) [GCC 8.4.0] Found voxl-esc tools bin version: 1.9 VOXL Platform: M0054 Detected RB5 Flight, VOXL2 M0054 or M0104! INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000 Sending library name request: libslpi_qrb5165_io.so Sending initialization request INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000 INFO: Params from ID 0 match ../voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml INFO: Params from ID 1 match ../voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml INFO: Params from ID 2 match ../voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml INFO: Params from ID 3 match ../voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml INFO: Success! Params in all ESCs are valid and identical.

Any thoughts on next steps here?

You might have both qvio and openvins running? That could lead to issues. Only one should be running at a time

have you looked through the troubleshooting guide? https://docs.modalai.com/flying-with-vio/#troubleshooting-vio

Usually looking at the ovins-overlay in voxl-portal offers good insight

The common issues are vibration is too high, the extrinsics are incorrect or there are not enough features to track in the environment

@QSL here is our app note on thermal https://docs.modalai.com/voxl2-thermal-performance/#thermal-performance

@cmall the VOXL 2 IO connects via UART. You could use any breakout board, like an Arduino, to generate PWM

@shawn_ricardo , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue.

Regarding the issue in the step response where the feedback data appears not smooth, i believe it is related to FTID's buffer / delay. FTDI adapters have this parameter latency_timer which is 16ms by default, which amount of time the FTDI board holds the RX'ed data before passing forwarding it to the PC (and vice versa, i believe). You can set that value to 1:

You can check this value:

cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

And set it:

sudo su echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

You would need to do this every time you unplug / plug the FTDI device back in.

(note that this applies only to Linux PC, not VOXL2).

Besides this, i think the plots look good. It looks like you have set the kp pretty low, which keeps the response softer (less chance of de-sync).

Alex

@victochen , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue.

@Eric-Katzfey The update has been pulled into our fork now. You can access the updated package here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.106-202507311432_arm64.deb