Posts made by Eric Katzfey

@Jetson-Nano Are you using WiFi to connect with QGC?

@Jetson-Nano Do you still get those messages from voxl-mavlink-server about dropped packets from external AP?

@Jetson-Nano Can you try a lower baudrate, like 57600, and see if that works better?

@brandon The latest voxl-mavlink-server is available here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202511040816_arm64.deb. This has added configuration for the GCS ports and also fixes the above issue so that it now responds to the correct port.

@brandon The latest voxl-mavlink-server is available here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202511040816_arm64.deb. This has added configuration for the GCS ports and also fixes the above issue so that it now responds to the correct port.

@ravi Keep in mind you must power cycle the VOXL 2 between each thing you do because the DSP (SLPI) won't cleanly shut down and if you try to start voal-mavlink-server again it will fail.

@ravi J18 should work. Let's try this one step at a time and see if we can figure out where the issue is. Start by disabling the voxl-mavlink-server, voxl-px4, etc. services and power cycle the VOXL 2. With port set to 12 and baudrate at 57600 does voxl-mavlink-server -z show connection with autopilot? If so, does it stay connected? And can you connect GCS? If all of that works fine, power cycle the VOXL 2 and just make sure that it reliably works. Let me know how all that goes before we move to the next step.

@ravi Can you stop the system service for voxl-mavlink-server (e.g. systemctl stop voxl-mavlink-server) and run it from the command line instead with the -z option to see all message traffic? You should see something like this:

voxl2:/$ voxl-mavlink-server -z
Enabling UDP to slpi recv debugging
Enabling qrb5165 external AP recv debugging
Enabling UDP to slpi send debugging
Enabling qrb5165 external AP send debugging
Enabling UDP GCS recv debugging
Enabling UDP GCS send debugging
loading our own config file
=================================================================
Parameters as loaded from config file:
primary_static_gcs_ip:        192.168.0.131
secondary_static_gcs_ip:      192.168.8.11
onboard_port_to_autopilot:    14556
onboard_port_from_autopilot:  14557
gcs_port_to_autopilot:        14558
gcs_port_from_autopilot:      14559
en_external_uart_ap:          1
autopilot_uart_bus:           12
autopilot_uart_baudrate:      57600
autopilot_mission_delay_start:      -1
autopilot_mission_delay_sound:      0
autopilot_mission_force_restart:      0
autopilot_mission_notif_dur:      0.10
udp_mtu:                      0
gcs_timeout_s                 4.50
en_external_ap_timesync:      1
en_external_ap_heartbeat:     1
=================================================================
Sending library name request: libslpi_qrb5165_io.so
Sending initialization request
Successfully opened bus 12 at baudrate 57600
starting qrb5165 external AP receive thread
Adding primary GCS IP address from conf file to list: 192.168.0.131
Added new UDP connection to 192.168.0.131
Adding secondary manual gcs IP address to udp connection list: 192.168.8.11
Added new UDP connection to 192.168.8.11
Init complete, entering main loop
to AP msg ID:     0 sysid:  1   to bus: 12
RECV  msg ID:    70 sysid:255 from bus: 12

@Tjark There is an updated voxl-px4 here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.116-202510301051_arm64.deb. You will also need an updated libfc-sensor library here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/libfc-sensor_1.0.8-202508141142_arm64.deb. Can you try to update with these 2 and see if it solves the issue?

@remill Normally what we do is build these libraries and create a Debian package to install them. Then, when building the application that depends on the library it is installed at build time using the install_build_deps.sh script. An example of this is: https://gitlab.com/voxl-public/voxl-sdk/third-party/voxl-jpeg-turbo/-/tree/dev?ref_type=heads which creates a package for the jpeg-turbo library. Then an application that uses it, like voxl-portal, will list that as a dependency in the script: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-portal/-/blob/dev/install_build_deps.sh?ref_type=heads#L16

@Eric-Katzfey Only for MONOTONIC. I'll look at this more and try to figure out the correct thing to do.

@Tjark Probably don't want to apply the offset if clock is REALTIME here: https://github.com/modalai/px4-firmware/blob/96011c76dc9fffb2f2a2528df1767cdf926b24ce/platforms/posix/src/px4/common/drv_hrt.cpp#L464

@Tjark The drone shouldn't land or crash when the system time is updated. To disable GPS on the drone edit the /etc/modalai/voxl-px4.conf file to set GPS=NONE. Is the system time message coming from PX4 or from a GCS?

@Jetson-Nano Regarding question #1, Yes, you can attach an external FC over the UART.

@jeremyrbrown5 Ah, yes, that'll do it.

@jeremyrbrown5 It doesn't look like there is any problem with the RC. The log shows the throttle stick being moved up. And it shows the motor actuators being set based on that throttle input. But, for some reason, the commands going to the ESC are all 0 so the motors don't spin. It kind of points to a configuration issue but I'm not able to see anything obviously wrong in the parameters. Which ESC are you using? Is this in a custom vehicle? Are you using any of the px4 parameter sets from the voxl-px4-params package?

@jeremyrbrown5 What type of RC are you using?

@jeremyrbrown5 Can you attach a px4 log?

@brandon Agreed, the code has a fixed port but should use the source port. We will fix that and also add configurable ports for the gcs IP addresses in the configuration file.

@Jetson-Nano Another thing you can do is attach an oscilloscope to the rx and tx lines of the UART. You may be able to sport obvious signal quality issues with that.