To all that might come across this, updating to OpenVPN 2.4.6 solved this issue. Note that a reset of the VOXL is required before the upgrade will take hold.

Also, if you are using the vpn-start service, do not use the full file path that is there by default; instead just use the openvpn call like you would in a terminal and use the file path to sudo /usr/bin/sudo before the openvpn call like this:

/usr/bin/sudo openvpn --daemon --script-security 2 --config mykeys.ovpn

If you don't make this change, it will try to run the older version of openVPN and will run into all kinds of issues.

I'm trying to run OpenVPN and it seems like it can't establish the TCP connection for the tunnel.

I'm getting the follow output from OpenVPN:

Not sure what is the most important line here but the TLS handshake failed might be something.

I did create a device on the OpenVPN portal and exported the .opvn file. Then I ran:

openvpn --script-security 2 --config mykeys.ovpn

(did it not a daemon to see the outputs)

The drone is connected to over wlan0 and I can confirm network connection with a successful ping of google.com

Thanks in advance for any help.

@Chad-Sweet We are using the ModalAI firmware. We can get you some logs for you to look into.

We have seen this issue so far on 5 of the m500 platforms that we've received in the last 3 months with varying levels of consistency (sometime altitude is correct right away, sometimes it takes some time, sometimes it figures itself out on takeoff.) We will be testing 20 more m500 vehicles in the coming week and I will let you know if they have the same issues.

Chiming in because since I'm on OPs' team. Do you mean completely disable it through voxl-vision-px4? It was disable from the FCU side in terms of the EKF aid mask was not using the VIO inputs (EKF2_AID_MASK = 1.) Will the VIO messages continue to affect the vehicles state estimation even if the EKF should not be reading in those measurements?

Yes, understood and that's part of the answer I expect. My bigger question though is if there is a way to tune the feature detection algorithm and or camera settings to be better suited for outdoor GPS denied flight.

I am going to be using the VIO for outdoor GPS denied flight using a stock m500. The environment will be sunny and have a mix of trees, roadways, and flat patches of grass. From what I'm gathering from reading through some forum posts, the VIO is generally setup for indoor flight out of the box. Is there a configuration that is better suited for outdoor VIO that does 1) handles sunny/well lit areas 2) allows it to pick up more features (maybe lowering the confidence required for something to recognized as a feature.) 3) assumes there are going to be zero indoor flights (as is the case for my vehicles.)

This is kind of a nebulous post and I apologize for that. For some context, when I flew my vehicle at around 6 feet in a field of rocky soil and patchy vegetation I was able to pick up numerous feature points. Once I got to around 20ft or greater, I lost all feature points. I tried pointing the VIO camera towards trees, rows of new newly growing vegetation, a gravel road and got nothing. I was able to pick up a few points when I pointed the camera towards a barn that was near by (yes I test on a farm.) To my understanding, trees, rocks and vegetation might not be the most robust objects for detecting features but I find it hard to believe that there were zero trackable features. Anyways, any help or ideas would be useful and I can post more info if needed, there's just a little bit of a phase lag (its a long drive out to the farm to collect data.)

@tom I updated to the newest firmware, then ran the voxl-configure-mpa wizard and I'm still getting PX4 DISCONNECTED FROM UART when I check the mavlink-server status. (I can see the visual odometry messages on wireshark, like before. Just not other mav messages.)

The mavlink-server config files looks like this:

And my px4 serial params look like this:

So still no dice.

@tom Copy that, I'll try the update and see if that fixes anything. We haven't modified the board or anything since receiving it so I'm not sure why something would have gone with the UART connection of all things.

@tom I have the M0019 version

@tom Thanks for answer! I'll give the upgrade a shot. That is probably the only thing I haven't tried yet. I should have mentioned in my original post also that I'm using a flight deck. I think that's why this is most confusing to me. All of the UART connections are board level so I can't be messing those up.