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.

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