Posts made by peterkrull

@James-Strawson That makes a ton of sense, thanks for the explanation! Also just noticed that it mentions this right above the definition. I should just learn to use my eyes

@Moderator I would just have expected the frequency graph to be smoother. I guess I could adjust the phase_constant and scale_constant parameters if it even turns out to be an issue. I am still a bit confused by the STARTING_CLOCK_RATIO 0.9765625 == 1/1.024 thing. Do these IMUs come from the factory with a clock that is biased like that, and is it just chance that a good initialization for the clock ratio is 1e3/(2^10)?

I saved a log using voxl-logger --preset_odometry with the intent of creating some data sets to try other VIO solutions. I was curious about the sample rate (before I thought about looking in /etc/modalai/voxl-imu-server.conf, where it is configured to 1000 Hz) and decided to calculate it based on the actual data. The image shows a sequence of 1e9/data_imu['timestamp(ns)'].diff()[1:200] which corresponds to the instantaneous frequency between two samples.

First I noticed that there is an offset from the 1000 Hz configured, which according to icm42688.c on line 117, the IMU should be able to reach. I find that the mean of this frequency, which is around 1023.89, is suspiciously related to the inverse of the #define STARTING_CLOCK_RATIO 0.9765625 (which is excactly 1/1.024) parameter in the ICM42688 driver. Is this supposed to mean that the IMU runs at a deterministic 1.024x too fast, or am I missing something?

The second thing I notice is that the frequency (and in turn the delta-time) varies a lot. I see that the timestamp from the sensor itself it not used, but that they are instead generated manually using the rc_ts_filter_... functions. I imagine that the sensor itself is a lot more consistent than this, even if the actual frequency might have some bias. So is this timestamp misleading? Too rough of an approximation?

@Eric-Katzfey Yea I found out about the dependencies the hard way by spending some hours trying to figure out why my installed dependencies were not accepted by Cmake. Of course because they were installed as amd64. Apart from slower compilation, what is the argument against using the qrb5165-emulator?

@Eric-Katzfey Thanks, that seems to be exactly what I need. I also figured out that GTSAM with the GCC compiler is what caused the extreme memory usage and eventual failed compilation, changing to Clang helped. It is right that I am using the qrb5165-emulator and not the voxl-cross image? I believe some parts of the documentation recommend using the voxl-cross for new development, but I could not get it to build the voxl-qvio-server out of the box.

I will preface by saying I am a novice as both working with docker, and working with complex C++ code bases for cross-compilation.

I am attempting to make a custom vio-server for the VOXL 2 which bases its estimation on an open source VIO solution from a science paper, specifically DM-VIO My plan is to start with the voxl-qvio-server, pull out the mvVISLAM guts and replace the relevant parts with the equivalent DM-VIO parts. DM-VIO however requires GTSAM as a dependency, which has to be compiled and installed. Is it right that I would have to to compile and install GTSAM inside docker (qrb5165-emulator)? From my experience compiling GTSAM natively on my PC, I know it is very slow. In addition, I have had issues with the compilation consuming large amounts of ram, eventually bringing everything to a crawl. Having to do this every time i restart the docker would not be viable. Maybe I am doing something completely wrong?

By the way, I am on a Windows machine running a Ubuntu 20.04 install through WSL, which also launches the docker image. Perhaps this is suboptimal, but I could not get voxl-docker work natively in Windows.

@david-moro That is my impression too, that and, it does not seem to be all that robust in general. I am very interested in using an open source VIO solution, and build it to be a mostly drop-in replacement for Qvio. I need it for high-altitude flight too, in mostly texture-less environments, a most robust solution seems necessary. I only just started looking into which methods could be interesting to use, and came across DM-VIO: Delayed Marginalization Visual-Inertial Odometry which seems to be very modern and robust. The paper for this states that it was run in real time on a 2013 mobile i7 at 2.3GHz, so I am hopeful that it could run on the VOXL 2. I would be interested in following along if any of you decide to go in another direction than Qvio.

@Caio-Licínio-Vasconcelos-Pantarotto I have not experimented with collision avoidance. I doubt that would do much in the case where VIO has completely lost its tracking, but that is only my guess.

After my recent mishap I decided to put together some prop guards for the Starling.

They can be found on printables.com as .3mf files, and are easily printable without supports on an FDM printer.

They are designed to not obstruct the view of the front sensors, specifically the tracking camera. As such head-on collisions should still be avoided. But they do allow for bouncing side-ways off of walls.

As far as PID tuning goes, it seemed to still handle fairly well with the default tuning. The center of gravity being slightly further back did also not seem to be an issue either.

@Caio-Licínio-Vasconcelos-Pantarotto I just got new propellers and tried flying again. This time with visually contrasting objects on the ground in front of the drone. Much better than before. One thing that might help, is to set "enable_init_while_moving": true in etc/modalai/voxl-qvio-server.conf. Then if the track is bad at some point during flight in position hold, it will in my short experience at least, do a better job at reinitializing in-flight. It can however also also initialize in a way where the position estimates quickly become nonsensical, before returning to something normal. In any case, I think the behavior when VIO loses track or otherwise performs poorly is not great. Unless the pilot is also inspecting the Qvio overlay while flying, it is not easy to know the state of the estimator.

In my case, I did my initial flight on a carpet which is has a bunch of contrast up close, but not so much at a medium distance. It could be that Qvio decided to track the carpet initially but lost all tracking shortly after and never recovered.

@James-Strawson Thank you for the reply,

I will revert the CAL_MAG0_ROT parameter back to 0, and also study the other configurable parameters and their impact.

About VIO losing track during the test, that is definitely possible, but I believe this part of the room was fairly visually distinct. In the log it seems that the failsafe flag for local position invalid was 0, but global position invalid was 1. Shouldn't the local position be the indicator for good VIO? I will just have to try again and double check the robustness of the tracking beforehand. But that makes me wonder, what happens if VIO loses track during flight? Must I then land and be stationary before I can take off again? At least that seemed to be the case when I was waving the drone in the air to try out the tracking. Also if the VIO was unable to make a good estimate from before take-off, shouldn't it refuse to take off in position hold? I guess if it loses track again, I should just switch it into manual mode to regain control.

Thank you for taking the time to answer my questions.

Regards
Peter Krull

Edit:
We later noticed that it seemed like the drone compass always was at 0 deg after power-on. It seems like this is the intended behavior when bit 3 is set in the EKF2_EV_CTRL parameter, which was the case here. I would have expected the behavior to be to trust the mag heading initially, and then fuse in yaw-data. This seems like odd default behavior to me. It does however explain why the drone was facing 180 deg in the wrong direction during my test.

I just tried, after a fresh mag calibration with rotation_none for the magnetometer, to place the drone in the same location as I took off initially. The values seem to align in this case. What is the correct rotation to use? Our previous observations about it being right at 180 deg might just have been because we happened to power on the drone in the right orientation.

Hello all,

I am interning at a company who purchased a Starling V2 to get started working with a flying VOXL 2, in anticipation of integrating the VOXL 2 into their own aircraft. I was tasked with getting it flying to validate the Qvio performance.

For the initial flight test I followed the video guide:
https://www.youtube.com/watch?v=Cpbbye3Z6co

The purpose of this test was just to arm the drone, hover it above the ground in position hold mode, land and disarm.

I first confirmed through VOXL Portal using the Qvio overlay that the room I would use for testing had enough feature points, and that position estimate seemed reasonable by moving the drone through the room. I also checked that the IMU and gyro readings seemed good. No errors were present in the Qvio overlay prior to flight. I had the left-hand rocker switch on the Commando 8 in the middle position, and confirmed through Portal that it was indeed in position hold mode. The propellers and motors were free to spin. At this point I had (probably mistakenly) not confirmed through QGroundControl that heading looked good.

I armed the drone, observed the motors start spinning. Moved the throttle to the middle position and the drone started to take off. It slowly, but immediately started to drift to the right which I then tried to counteract. After the drone kept drifting I attempted to land it by pulling the throttle down, but It stayed airborne. It felt like it was not really responding to inputs at all at this point. I decided to disarm the drone mid-air (which worked immediately) before it eventually hit a wall. This broke the propellers on the front left motor, but the drone otherwise seems fine.

The log is attached
https://logs.px4.io/plot_app?log=41653826-4300-4222-bc74-d8a169c3e31d

The VOXL 2 is on SDK version 1.0, system image 1.6.2.

Something else I, and another person present in the room noticed, was that the thrust sounded "spikey", which the logs also seem to confirm on the thrust plots.

I noticed looking at these logs that the yaw estimate seems to be rotated 180 degrees from where I would have expected. Though I am mostly certain I had the front pointed in my forward direction, which would be mostly north-facing. This is why I suspect the compass calibration might have been off. After doing a few compass calibrations through QGroundControl (and looking at the arrow on the GPS module in the Starling V2 Datasheet)l, it seems that the magnetometer rotation should be a yaw 180 degree rotation. However we noticed that this setting did not always stick after power cycling the drone, and sometimes still pointed 180 degrees in the wrong direction until we changed the parameter back and forth. We are not able to reproduce this consistently though. Sometimes it would also just take ~10 seconds after connecting to QGroundControl before the yaw heading snapped to the correct value.

We were wondering if this had something to do with the split PX4 architecture, somehow causing the yaw configuration to not be loaded in time, or at all. Merely speculation on our part.

Any feedback on what might have gone wrong would be appreciated.

Regards
Peter Krull