ModalAI Forum

@Steve-Turner - Yeah I have put EKF2_AID_MASK to 0. Then the drone would just be behaving normally.

@Cliff-Wong - I understand that I would have to disable qvio-server, if I would only fly in non-evdata modus. But when flying with evdata, if then the evdata goes bad, I need to switch to non-evdata to be able to save the drone from crashing. But now the drone will still crash!

I am flying PX4 v1.11 and v1.13 on the ModalAI Flight core with their VOXL companion computer that gives VIO data - and we experience a bug in PX4 that results in crashes. It's something that should not happen, and normally does not happen but when it does we need to emergency land or if possible switch to acro mode and then safely make an emergency landing.

So what happens: In stabilize mode when flying the drone, after flying for some time without any troubles, the drone suddenly pitches or rolls in one direction to its maximum angle. Even counter-steering the drone in the other direction only works to some degree, it will still go in that direction. When changing to acro, we can still safely control and land the drone.

Here we have a Log of one instance. You can see the drone is only in stabilize mode, and at the end of the flight, the pilot is at full pitch and rolls to make a safe emergency landing. I have a video of this, and this just happens when hovering, the drone is not at any cruising speed or something. The drone is just scanning something an object from top to bottom.
https://logs.px4.io/plot_app?log=cde7b479-812b-4d3f-8035-c8c79fc4ca3e

The way we solve this problem is when we fly in stabilize mode we change the EKF2_AID_MASK from 280 to 0.

So what we think happens is that the VIO data becomes bad (due to low features or whatever), and think the drone is going in the wrong direction. So the drone wants to counteract this and rolls and pitches in the opposite direction the VIO thinks it's going to. This is something that would happen in position-hold mode. But here comes the bug, this also happens in modes that “don't” use the VIO data. We see this happening in modes like stabilize, altitude hold mode, and position failsafe.

How is this possible? And can we switch this off? Or is this a bug that needs to be fixed?

Hi @Matt-Turi,

Thank you very much for your clear answer. We will give this a try!
If you have any examples or more information on how to do this, please feel free.

When we fly in more difficult environment for the VIO, the VIO system tends to track the drone itself, it will track the prop guards/ landing gear. An example of what the tracking camera can see of its own drone, you can see here:

In our setup we have tilted the tracking camera 15 degrees more downwards so it sees less of the drone. But it is impossible to place the camera in an position where the tracking camera does not see anything of the drone. In the current and possibly the best placement of the camera, the image looks like this:

In the top corners it can still see some parts of the drone, the props guards. Now when the tracking camera tracks the prop guards, the drone will loose its positioning and crashes. Is it possible to modify the VIO code or just by parameters, so that it cannot and will never track any features/ points in that area where the prop guard is?

@gus and @modaltb did this work?

In our setup we are two UART short.
We would like to use 2 UART ports for:

1. TELEM3 (DJI FPV)
2. Dshot telemetry

The UART ports that we don't use are:

1. J2 Debug
2. J4 UART ESC

How could we use these existing UART ports the way we would like to?

We are trying to connect a arducam to the VOXL and stream that via Ethernet to QGC.

We are trying to that the same way as in this video: https://www.youtube.com/watch?v=iStAaxOtMLw
But then only with one camera, so we thought it would be simple.

But when trying those commands like:
-> voxl-uvc-server -v 0c45 -t (custom pipe)
-> voxl-uvc-server -s

It does not work, because we apparently use an older version.
But we have updated it to: 0.1.2. Did the pkg-manager dev etc. etc. and still it is giving us not more commands. (see image)

So a couple of questions:

1. Is this the right route to go to enable a stream for only one UVC USB camera?
2. And how can we get these commands?

@tom thank you! I can now see it, from now I will do:
voxl-logger --preset_odometry -d /mnt/sdcard

@Chad-Sweet thank you, its now downloading the logs, it works perfectly. But I think the logs are very large, so its a little slow.

I am debugging the VIO. With voxl-logger --preset_odometry.
I see that the files are being saved in /data/voxl-logger/, but I want to download the files to my computer to analyze them in plotjuggler.

1. How can I move the log files to my SD card in the VOXL via terminal (I have no idea, and all the linux commands I also do not know)?
2. How can I get the logger to save the logs directly to the SD card? I know I can do voxl-logger and then -d, but I also dont know the directory of the SD card.

Hey @Steve-Turner, thanks for your answer, I will take a look into it!

The full VOXL CAM will be angled 15 degrees forward, so this means the VOXL as well as the global shutter camera will be tilted forward. The flight core is already fixed. But we now need to change extrinsics file. /etc/modalai/extrinsics.conf

I have read the whole https://docs.modalai.com/configure-extrinsics/ and seen the video. But cannot really confirm if I'm doing a good job. Could someone please help me with this? I dont know what ''RPY_parent_to_child" I need to change. And if you know to what XYZ value, please do .

This now the only thing I get. So there is no intrinsics or extrinsics files for right/left/stereo & tracking. I will do the camera calibration then. Thanks

Where can I find local_position_ned?

Or is it this?

We have the VOXL CAM version with Hires, Stereo & Tracking.
We have uploaded 3.8.0 image with the 0.7 suite.

But this is now the error that I get after doing the following:
voxl-configure-mpa -p -f seeker -b blue -c 7 --fc yes
reboot
voxl-configure-cameras

We updated our VOXL CAM to a newer system image and suite, during the updating we did a clean wipe, removing everything. Now after this clean flash our position lock does not work anymore.

In VOXL we configured the following:
VOXL-configure-mpa / ...exentrics / ... vision-px4 / ... cameras.
Everything as a standard VOXL CAM v1/ seeker.
But still it doesn't work.

If we look at voxl-inspect-qvio, its says OKAY. And if we walk around it will also work just fine. I notice that over time the values get weird and will reset itself.

If we look at the mavlink message Odometry they are not very normal. They are staying at around 0, x and y are just 0 and doesn't change when walking around. And the others do all kind of crazy things, so I think that is why it also won't go into Pos Lock.
EKF2_Aid_mask is 280, of course!

Is there something we are missing? Do we need to perform some calibrations? The VOXL-inspect-QVIO isn't asking for it.

Thanks!!

Where can I buy replacements or just new vibration dampers that are on the VOXL CAM for the Seeker drone?

Thank you for the response! I didn't have time to look into this yet. But there is more going on with the system I think. WIFI also doesn't work anymore. And after trying to solve the WIFI, the ADB of the VOXL stopped working. So we for now we are using a different VOXL.

Something else we are running against is the message Reject position control, with working VOXL CAM systems installed on our drones. When we fly everything is super! When we land, after the drone has bumped into things while flying (drone is collision proof) or when heavy wind was pushing it. We cannot take off after landing, it will display Reject position control. Only when the we connect a laptop to the QGC, we can hear that the VOXL reboots and then the Reject position control is gone, and we can go fly again. But if we use QGC via the PX4 Telemetry port, this doesn't happen, and we need to unplug and replug the battery to be able to get the Reject position control message away again.

We don't really know why this happens and how we can solve this. It would of course be great if the VOXL didn't need to reboot in order the drone can fly again in position mode. But it already would be helpful that the VOXL would reboot without having to have WIFI connection with QGC. Please help!

We have flown the Seeker drone up to 4 hours maybe and everything with the VIO and position hold worked good. I did all the updates (v0.5.0) on the VOXL to get the voxl-mapper to work and it did work. In my thoughts it even worked with the VIO. Sometimes I did have Reject position control on QGC, but than I restarted the Seeker and I could fly in position mode again. But for some reason it keeps giving me the Reject position control, and now I am not able to fly in position mode anymore.

I did quite some troubleshooting -> voxl-configure-excentrics/ camera/ QVIO/ PX4 etc. all of that I did do that make sure the VOXL was correctly set.
I also checked if the FC got any Odometry data, but it did not get any of VOXL. At least I could not see the data with the mavlink inspector. It is weird, because I didn't change anything on the FC itself.

We really need it go back up in the air for some more testing! Any idea???

I want to create a static IP Address on eth0.

Now we have added an custom IP link to the USB 2.0 port of the USB expansion board via an ethernet to USB adapter. This works perfectly following the regular link: https://docs.modalai.com/usb-to-ethernet-with-voxl/

But our custom IP link will only work with IP address 192.168.144.20 to 192.168.144.24

Last Monday I got the eth0 to this IP address via changing /etc/network/interfaces to:
IP: 192.168.144.20/24
Mask: 255.255.255.0
Default gateway: Leave open

And everything worked perfectly and I was happy. Even for a couple of times restarting the system.
But today it doesn't work anymore, it's back again changing the IP address of eth0 to whatever suits the VOXL best. Was this the best method to change the IP address on the eth0? Or is there something wrong? And how can I change this on a better way?