Posts made by Aaron Porter

@Alex-Kushleyev we are seeing this issue with NTP were the time is saying that the Service has been running for 2 years 7 months when the VOXL2 is booted up. It doesn't seem to correct after that. I am looking into away to solve this issue but odd that TimeSyncd didn't have the same issue.

Hello,

Just a general question about timesyncd and how it is used in voxl-services. I installed NTP onto the VOXL2 without an issue and noticed that systemd-timesyncd can not run at the same time. So since systemd-timesyncd is just a simplified version of NTP that only perform as a client so there shouldn't be any issue. I have to double check with voxl-mavlink-server and the updating time stamps when not connected to the internet. That is really the only thing that I would foresee causing an issue. Not sure if anyone else would have an idea of anything else I should check?

Thank you for your time,
Aaron Porter

@jmltt I understand it is personal preference, I just wanted to give more detail on the issue that you were originally seeing incase anyone else ran into the same problem. Shouldn't happen in the future with the recent changes, but some still use older SDK versions.

@jmltt So reading the original issue that you were having back in November. The Deb file that Eric posted will solve the issue of mismatching communication links in QGC. I tested it and it works. The problem was that the voxl-mavlink-server was assigning every drone sys id 1 regardless of the MAV_SYS_ID parameter. This resulted in QGC assuming each of the drones were the same since the SYS ID on connection were the same.

Now as for why the drones were all connecting at once sounds like the autoconnect for UDP is enabled. The drones should not connect unless given the IP address + Port number in the comm link like you described. If QGC is setup to autoconnect to any UDP connections then that would explain why since all of the drone are set to communicate on 14550.

https://docs.qgroundcontrol.com/master/en/qgc-user-guide/settings_view/general.html#auto_connect

I understand why changing the port number would help prevent confusion but I don't think 4 drones using port 14550 is the issue as other have had multiple drones all on 14550 connected to a single QGC instance. There are issues if you are suing a simulation but not for physical drones.

@dan64 Unsure if you have resolved this issue, but I am going to add some more information to anyone that stumbles across this. There was a bug in the voxl-mavlink-server setting and sending all System ID numbers to 1. The deb file below should solve this issue where the MAV_SYS_ID can be changed an reflected on the VOXL2.

http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202509181025_arm64.deb

@Eric-Katzfey

Sorry for the delay I had to do some research since I didn't fully understand how deadlines for Real Time clocks worked and why a Real-Time Clock might skip/jump other than for reasons like Daylight savings.

Basically since RTC is known for jumping ahead from time to time this will cause other voxl-services to believe that they are late one performing a task but the clock just jumped ahead. If we are not using a voxl2 connected to the internet or GPS then this shouldn't pose a problem? The reason I am asking is because the information I did find pointed to jumps being cased by NTP, Battery problems, or temperature.

I am guessing the most likely cause for a jump is temperature.

Thank you for your time,
Aaron Porter

@Eric-Katzfey

A second device use NTP + PPS for time sync. the problem is that the second device uses the Real-Time clock when time stamping its data. The goal is to sync up the data from the second device with the camera-server, and IMU data generated but the VOXL2. The Problem is that camera-server and imu-server use Monotonic. There is an obvious offset between real-time and monotonic but that varies from the offset +/- 150 ms. This wouldn't be a huge deal but using that data with that level of deviation cause problems with the postprocessing.

So the current thought is if it is possible to just use the real-time instead of monotonic then there will still be an offset but should be far more consistent especially when using Pulse-per-second (PPS).

Thank you,
Aaron Porter

Hello,

This is probably more of a question that is probably designed to make everything on the voxl2 stop working correctly but I am going to ask it anyways.

What would happen if we changed the code to use the real-time clock instead of Monotonic for voxl-camera-server and the voxl-imu-server?

Would the other services not function correctly? Would they have to also be changed to Real-time clocks? Is everything going to work smoothly like before?

Not sure where IMU-server is located, otherwise I would try it out and post here but I see Camera server can access real-time but it is not used.

Thank you for your time,
Aaron Porter

@george-kollamkulam Great just wanted to make sure there wasn't any other issue.

@george-kollamkulam Any updates or are you still running into issue?

@george-kollamkulam

Based on what you gave here. Yes, if voxl-camera-server is not running then there is nothing going into the ros2 topics to be published by voxl-mpa-to-ros2. The main way to figure out why voxl-camera-server is not running is to run voxl-camera-server on the VOXL2's command line. If need be you can also use the debug flags not sure what they are off the top of my head but you can find them by using voxl-camera-server -h.

First lets find out why voxl-camera-server is not working then we will have a better idea if mpa-to-ros2 has a problem.

The overall goal is just to get time synced between the Lidar and the VOXL2's IMU. Oddly enough, I was looking through the voxl-kernel for qrb5165 and the driver for PTP is there. Is the physical layer chip not able to support PTP?

Where I see the driver in the Kernel:
https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel/-/tree/qrb5165-ubun1.0-14.1a/drivers/ptp?ref_type=heads

So we are trying to sync the time between the VOXL2 and an external lidar that are connected via ethernet. We can collect the data from the Lidar however due to the timestamps between the Lidar's real time clock and the VOXL2's monotonic time stamp there is Skewing occurring because the Lidar does not have a IMU to use. The question here is how would someone solve this issue?

PTP was attempted of but the problem is that the VOXL2's Linux Kernel does not support software-transmit when inspected using ethtool. If there is a way to get around this that would be ideal. Then it would just be working with getting the Monotonic clock to work with the Real Time Clock.

The thought of collecting the time of the lidar and then setting an offset to match up with with the monotonic clock was purposed but due to the query-response nature of the setup. There is an unknown round trip delay from the VOXL2 query to the the Lidar's response back to the VOXL2.

Also alternative suggestions are welcomed if there is a far simple way then sure, but the request is to avoid adding additional hardware.

Thank you for your time,
Aaron Porter

So for anyone that has the same a question about VFC as I did, this post is just to answer the question.

The purpose is to be a more robust system that doesn't get PX4's state and EKF from being corrupted when VIO fails. So in essence it is a more graceful way for the drone to fail out of Position mode into altitude mode. So the functionality and performance seem to be the same as the drone using position odometry data just in offboard mode. More changes maybe in the wood works but as of June, 2025, this is its purpose so far.

@Judoor-0, are you using the ModalAI TOF? Depending on the point cloud format, I see that there is a way to get the confidence level and the rgb values from the point cloud data. You might be able to use the RGB as intensity and the confidence value for Noise information. I can test it out if you are using a ModalAI TOF to check the PointCloud formatting just so I can give you a full answer.

So something that I was seeing while testing this was having a bit of instability with Open VINS flying and altitude flying (Not Using VFC). I was seeing that voxl-open-vins-server stated that the IMU temperature was too high and kept resetting. After letting the VOXL2 cool down for a day I was able to have the Drone Fly in VFC mode but not sure how it flew compared to Position mode using VIO.

@Muqing-Cao You can get the VIO data from the ROS1 and ROS2 Topic /ov_overlay , /ov, or /qvio depending on which VIO you are using. Both have the same type interfaces available so either should work. Yes, you will be able to get run the commands on a host computer and as long as they are on the same ROS_DOMAIN_ID, for ROS2 this should be automatic.

Thank you, I was playing around with it.
Seems like for the controller it is a bit difficult since all main the buttons on the Xbox controller are mapped to the same channels. But at least then are set to different values.

Hello,

I am playing around with VFC on one of the Starlings 1. I am able to takeoff in altitude mode and change over to Offboard mode. I thought that changing to offboard mode from altitude would cause the drone to go into VFC_Altitude mode however, I get a message in QGC that the mode is VFC_Manual and feels similar to manual mode as well. Not sure if I am missing something? Am I wrong in thinking that it should be in VFC_Altitude?

I am using a joystick controller instead of an RC controller.

Thank you for your time,
Aaron Porter

Question about the frame rate on the voxl cameras. Is there a way to get voxl-camera-server to lock the frame rate regardless of the Exposure? We noticed that auto exposure will cause the camera frame rate to lower on cameras that are in darker locations compared to the cameras that are located in brighter areas. Just asking if there is a way to make it so that we can have a consistent frame rate regardless of where the camera is looking and the lighting in those areas?

Thank you,
Aaron Porter