@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.

Hello all, I was doing a bit of testing with voxl-open-vins-server and noticed an issue where the PX4 flight mode remains in position mode when the quality dropped below the the EKF2_EV_QMIN. I am seeing that QGC is sending a message saying that the system is falling back into altitude mode, but the flight mode never changes. I changed the PX4 parameter for EKF2_EV_QMIN to 90, however it seems to stay in position mode even though when I look at the PX4 logs the VIO quality drops below the QMIN value. I tested qvio to see if this was a voxl-px4 issue, but voxl-qvio-server switches into altitude mode when the quality drops below the the QMIN value. My question is why is it that when Open-vins reports that the quality is less than the QMIN it stays in position mode?

Thank you for your time,
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?