@nekolny , you should use a linux PC to run voxl-esc tools in order to connect to the ESC and check / update the ESC firmware. VOXL1 does not have support for voxl-esc python tools to communicate directly with the ESC.

Alex

@nekolny You should be able to use voxl-mavlink-server --help to see the various debug options available. You can stop voxl-mavlink-server from running as a service and then start it manually from the command line with the desired debug options to see which messages it is getting from the autopilot and what it is sending to QGC (and vice-versa). Then you can also use tcpdump to look at the IP traffic on both VOXL 1 and the QGC computer to see which messages are being sent.

@jonathankampia Correct, The VectorNAV needs to have the serial port implementation changed to support SLPI. That can either be done by modifying the code on our branch or going to mainline PX4 and modifying the implementation to use the platform independent Serial port abstraction.

it's more likely I will be commanding attitude / body rate which are already available

Indeed. I highly suggest you to use those two unless your application stricly requires direct actuation control.

I just wanted to get a clear overview of what the information dds client / agent can give me access to in the modalai version of px4.

By editing src/modules/microdds_client/dds_topics.yaml you can access any PX4 uorb message so the limit here is just about what has been implemented on PX4 that is or is not available in the voxl version.

How do you know what types of control / input & output data are not directly supported in px4 voxl version, as you said?

the type of offboard control you can achieve is exposed by OffboardControlMode.msg. As you can see in main PX4 you have

bool position bool velocity bool acceleration bool attitude bool body_rate bool thrust_and_torque bool direct_actuator

I've added thrust_and_torque and direct_actuator one year ago (more or less). However, latest voxl is still using the old version: this old version let's you control via thrust and torque setpoints but does not let you control the single motor individually.

@Zachary-Lowell-0 Yes I installed voxl-ros2-foxy. This time I just tried "source /opt/ros/foxy/mpa_to_ros2/install/setup.bash" and that was accepted. However, looking now px4_msgs is still not recognized within my program.
73d768a7-bab0-42d9-b73e-b4e84749294a-image.png

@KnightHawk06 , DFS on VOXL2 uses the Qualcomm's proprietary implementation of the DFS algorithm, which runs on the specialized DSP (CVP - Computer Vision Processor). Unfortunately we do not have any details about the actual algorithm.

Alex

@Alex-Kushleyev, I using voxl2 with M0173 board with camera config 29.
The errors are now solved, I made the necessary changes and reconfigured every server and pipeline and calibrated the cameras.

Also this is what I was getting when inspecting the mavlink server.

00:19:39.969721 IP 192.168.1.1. domain > 192.168.1.134. 40850: 5282 Refused 0/0/0 (42)
00:19:39.970315 IP 192.168.1.134.48451 > 192.168.1.1. domain: 5282+ PTR? 1.1.168.192. in-addr
• arpa. (42)
00: 19:39.973637 IP 192.168.1.1. domain > 192.168.1.134.48451: 5282 Refused 0/0/0 (42)
00:19:40. 106351 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:41. 068099 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:41.553204 ARP, Request who-has 192.168.1.1 tell 192.168.1.134, length 28
00:19:41.553488 ARP, Request who-has 192.168.1.138 tell 192.168.1.134, length 28
00:19:41.558414 ARP, Reply 192.168.1.1 is-at 80:69:1a:06:84:4e (oui Unknown), length 28
00:19:41.561634 ARP, Reply 192.168.1.138 is-at 34:c9:3d:07:16:8d (oui Unknown), length 28
00:19:42. 065376 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:43.070712 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21
00:19:44.075718 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:45. 064630
IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:46.062935 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21
00: 19:47. 107960 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21

@Jetson-Nano We have never used Microhard on windows but it's possible your firewall is blocking UDP data on that port

@Yoshimaru-Tanaka , you are right, the information in the documentation is not sufficient to diagnose this issue.

There is a page already for camera debugging information, but it is very brief. We will add more details (from this thread and more) to this page.

https://docs.modalai.com/debugging-camera-issues/

Thank you

Alex

@ssansoy , you cannot access the data from these pipes directly, you have to use the MPA mechanisms to do that. There is an example of doing that for tflite detections right here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-detections.c and the compiled app should also be present in the SDK, so you can run it on your VOXL2 (voxl-inspect-detections).

Alex

@Eric-Katzfey

From other discussion,
I add

qshell gps start -d 7 -b 115200

and get the GPS now.

Here is my setting and please let me know if any questions.
Thank you for your precious time on this matter.

AIRFRAME=MULTICOPTER
GPS=AUTODETECT
RC=CRSF_RAW
ESC=VOXL_ESC
POWER_MANAGER=VOXLPM
AIRSPEED_SENSOR=NONE
DISTANCE_SENSOR=NONE
OSD=DISABLE
DAEMON_MODE=ENABLE
SENSOR_CAL=ACTUAL
ARTIFACT_MODE=DISABLE
EXTRA_STEPS=(
qshell gps start -d 7 -b 115200
)

@astro_phil with some further investigation over the weekend, i found a small fix in the px4 codebase that seems to reduce the velocity estimation error. I low pass filtered the delta time (dt) value that is used to integrate the linear acceleration to obtain the velocity estimate.

vibration_fix.png

Left is without the "fix" and right is with the "fix". Flying in position hold.

WhatsApp Image 2025-05-03 at 15.50.57.jpeg

I tried to induce more vibration on purpose to test the impact on position tracking.
Both flights shown in the plot where done with the system shown in the picture.