Posts made by Umut John

OMG! The protective cap on the camera
You're right! Just saw it minutes before checking it here. There was no cap on the first drone; it was probably dropped or something, so I did not even feel the need to look for it.
Thank you, Adrian; sorry for the trouble. Case closed!

Stereo cameras and Tof streams work, but not the tracking. "camera-test" returns the following:

num_cameras = 4
Testing camera id=0
camera-test: /opt/workspace/build/apq8096-le-1-0-1_ap_standard_oem.git/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oemllib32-linux-gnueabi/lib32-qmmf-sdk/git-r0/qmmf-sdk/recorder/src/client/qmmf_recorder.cc:326: qmmf::recorder::status_t qmmf::recorder::Recorder::DeleteVideoTrack(uint32_t, uint32_t): Assertion `recorder_client_ != __null' failed.
Aborted

And this is what I see in the portal:

Tried both multiple times, no changes, unfortunately. I'd like to add that in the VOXL Portal, there are no camera streams for the tracking cam and Qvio overlay channels (which are all black), although stereo cams and tof streams seem to work.

Hello Adrian, thanks for the prompt response. There is no custom software/hardware. Configuring MPA didn't seem to help either. And here is the output of "voxl-inspect-services" command:

Service Name         |  Enabled  |   Running   |  CPU Usage
docker-autorun       | Disabled  | Not Running |
docker-daemon        | Disabled  | Not Running |
modallink-relink     | Disabled  | Not Running |
voxl-camera-server   |  Enabled  |   Running   |    23.5
voxl-cpu-monitor     |  Enabled  |   Running   |     0.0
voxl-dfs-server      | Disabled  | Not Running |
voxl-imu-server      |  Enabled  |   Running   |     0.0
voxl-mavlink-server  |  Enabled  |   Running   |     1.8
voxl-modem           | Disabled  | Not Running |
voxl-portal          |  Enabled  |   Running   |     0.0
voxl-qvio-server     |  Enabled  |   Running   |     1.8
voxl-streamer        | Disabled  | Not Running |
voxl-tag-detector    | Disabled  | Not Running |
voxl-tflite-server   | Disabled  | Not Running |
voxl-time-sync       | Disabled  | Not Running |
voxl-vision-px4      |  Enabled  |   Running   |     1.8
voxl-wait-for-fs     |  Enabled  |  Completed  |

And here is the output for "voxl-version":

system-image: 4.0.0
kernel:       #1 SMP PREEMPT Thu Oct 13 17:57:05 UTC 2022 3.18.71-perf
hw version:   VOXL
voxl-suite:   0.9.5
Packages:
Repo: http://voxl-packages.modalai.com/dists/apq8096/sdk-0.9/binary-arm64/
Last Updated: stat: cannot stat '/var/lib/opkg/lists/modalai': No such file or directory
stat: cannot stat '/var/lib/opkg/lists/modalai': No such file or directory
WARNING: repo file has changed since last update,
        packages may have originated from a different repo
List:
        apq8096-dfs-server       0.3.1
        apq8096-imu-server       1.0.3
        apq8096-libpng           1.6.38-1
        apq8096-system-tweaks    0.1.3
        apq8096-tflite           2.8.3-1
        libapq8096-io            0.6.0
        libmodal-cv              0.2.3
        libmodal-exposure        0.0.7
        libmodal-journal         0.2.1
        libmodal-json            0.4.3
        libmodal-pipe            2.8.2
        libvoxl-cci-direct       0.1.5
        libvoxl-cutils           0.1.1
        voxl-camera-calibration  0.2.3
        voxl-camera-server       1.3.5
        voxl-cpu-monitor         0.3.0
        voxl-docker-support      1.2.4
        voxl-gphoto2-server      0.0.10
        voxl-jpeg-turbo          2.1.3-4
        voxl-libgphoto2          0.0.4
        voxl-libuvc              1.0.7
        voxl-logger              0.3.4
        voxl-mavlink             0.1.0
        voxl-mavlink-server      0.3.0
        voxl-modem               0.16.1
        voxl-mongoose            7.7.0-1
        voxl-mpa-to-ros          0.3.6
        voxl-mpa-tools           0.7.6
        voxl-opencv              4.5.5-1
        voxl-portal              0.5.0
        voxl-qvio-server         0.8.2
        voxl-streamer            0.4.1
        voxl-suite               0.9.5
        voxl-system-image        4.0-r0
        voxl-tag-detector        0.0.4
        voxl-tflite-server       0.3.1
        voxl-utils               1.2.2
        voxl-uvc-server          0.1.3
        voxl-vision-px4          1.4.0
        voxl-vpn                 0.0.6

Finally, there is no Local Position NED tab in the MAVlink Analyzer Tool in QGC.

By the way, "voxl-qvio-inspect" command gives the following output:

waiting for server

 dt(ms) |    T_imu_wrt_vio (m)   |Roll Pitch Yaw (deg)|features|quality| state| error_codes |
   30.3 |    0.00    0.00    0.00|   0.0   -0.0    0.0|     0  |   -1% | FAIL | CAM_MISSING STALLED

Hi,

We have just received a pair of Seeker drones. One of them works flawlessly indoors (w/ Vision enabled, w/o GPS); however, the other does not switch to the Position mode under the same circumstances, regardless of our efforts. It can switch to Manual, Altitude, and Stabilized modes, though. I made sure that the parameters were the same by exporting/importing; and made the calibrations as well. What else should be considered?

Best

Hi,

Is it possible to find/estimate the speed of the wind, most profoundly, the headwind during the flight from what we normally have in the log files, without using an extra sensor, etc.?

Best

Still need some troubleshooting on the logs I've posted if anyone in the team have some time. Cheers to all!

I'll definitely check that one out to see how stable the vision inputs are. However, in the second flight, when we included GPS in the EKF2 fusion, we excluded the vision inputs to isolate the problem. So it can't be the sole reason, either.

The result was that the drone flew away to the deep in the sky during a so-far pretty stable orbit move (unfortunately no logs for this one). Thus, I am thinking like we were occasionally getting faulty positioning data from IMU. Because we were orbiting at 10 m altitude, then suddenly alt reading changed to -8.8 m and the device started to rise possibly to reach 10 m again.

Dear Chad,

Thanks for the reply. During that flight (which the log belongs to), we got signals from 14 sats and had stable GPS signal until the drone started rolling wildly around 3:11 just before crashing (please refer to the 3D flight demonstration - you can also verify this by looking at the very first plot under the map). Furthermore, at that time, EKF2 fusion excluded GPS data, relying on other positioning input like vision, baro, etc. (pretty much like an indoor mode). So, GPS had no effect on the strange behavior we experienced.

In the second flight where we lost the drone, GPS was included in the fusion this time as we first thought that this was the reason of such unstable movement, however it was apparently not. The drone somehow loses its position estimation even though GPS works correct.

That was actually a very good question. Any recommendations?

Here's today's update: we lost the drone, it is gone!

It was supposed to fly slowly in an orbit around a fixed point (r = 9 m) with altitude of 10 m. Though it started very well, after a shortwhile the reported altitude in QGC suddenly became -8.8 m (was precisely 10 m beforehand) and the drone started to gain altitude. It did not follow the land and return commands possibly due to the altitude error. The device continued to gain altitude until it disappeared at some point. It never turned back to the field although it had a 50% battery. Our mistake was obviously not forcing disarm, we forgot this with fuss and stuck to land. There is no log as the device was lost, but we have the previous one above.

Just to note, we were using WiFi, not the RC. This appears to be another bad decision but we are working on autonomous swarm ops, so we eventually cannot operate every single drone with an RC. Another note is GPS was active and healthy, EKF2 fusion included GPS data this time.

We apparently need urgent feedback on that one.

Best

Hi everyone,

From time to time, we experience difficulties in executing stable flights, whether a manual flight, a PX4 mission, or a Python-driven flight. At some point in the air, drones (I guess) lose their local position and go to (I cannot call this a drift as it happens very fast) a totally irrelevant position, then enter the descend mode and hit the ground. This happened multiple times. It is clear from the logs that there is something unusual, but we couldn't find the root cause as we have limited hands-on experience. Could anyone help us by reviewing the attached flight log belonging to a very short mission that ended up in an instant crash?

Log: https://review.px4.io/plot_app?log=0363540b-211b-4b83-a00e-2d3957565918

Best,

Umut

@Umut-Can-Çabuk It is possible to set the wlan0 to "ad-hoc mode", but channel allocation can't be done apparently. Any help would be highly appreciated.

Dear all,

We are working on an autonomous network topology maintenance scenario where the nodes (i.e., drones) should be interconnected through the Wi-Fi ad-hoc mode. We are having the same issue as Yuezhan mentioned here: https://gitlab.com/voxl-public/other/documentation/-/issues/23. I see that there is no native support for this on VOXL, but is there any way or a workaround that lets us use Wi-Fi in ad-hoc mode? If not, can Bluetooth (e.g., forming piconets) be useful in this case? Any bit of help would be awesome!

Many thanks,

Umut