@AP123 Hi, I have not seen this before, but I also haven't tried enabling obstacle avoidance. I can't pretend to know much about the obstacle avoidance code running inn the VOXL SDK, but I suppose this error could be caused by some obstacle avoidance service not running on the VOXL when it should be, hence QGroundcontrol being confused.
Hey all, apologies on this. We were finally able to recreate the issue but unable to determine what the root cause was. Regardless, we have a new SDK (1.1.0) released which isn't showing the stack smashing issue.
@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.
@Moderator will try to on our next flight. Do you have an easy way to trigger a capture when certain conditions are met? It is hard to correlate hundred of images to the autopilot logs to find these instances. We are working on streaming the qvio-overlay as an RTSP stream down to the GCS. That might be easier.
Unrelated question. Can the VIO algorithm use the colored images coming from the camera? If yes, is there an advantage at all?
Thank you. I got the VIO going on the drone. I noticed that when running the VIO server, the IMU_BW error kept coming up and that was the cause of the server's crash. Therefore, I increased the limited_imu_bw_trigger parameter in the voxl-qvio-server.conf arbitrarily to 100 and it worked fine.
Thank you for your help.
I realize you are not part of the ModalAi Dev Team, but I would like to ask for your help with this.
There is more information that I have posted on this thread.
I am lost, and would really appreciate any kind of help you could provide.
@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!
The MV library is made by qualcomm and has some licenses attached to it, we can't publish (and don't even have access to ourselves) the source code and have to keep the headers behind a EULA. Since both our voxl system images and docker build environments are behind said EULA, that's where we keep the header. It can be found in /usr/include/mv/ on both the voxl and the voxl-emulator docker image.
We're still not sure what caused the scheduler issue, it was a new feature we were hoping to integrate into the stack when you found this bug but aren't able to right now. In the meantime we've pushed updated packages with these calls removed so that all of the packages can run as intended. If you update the packages via OPKG to latest there should be no issues with the scheduler.