Topics created by Aaron Porter

@Aaron-Porter Hello there,

voxl-evaluate-vins is currently not used by the Autonomy team @ ModalAI, we opted for our new benchmark solution, a bit more consistent in terms of statistical rigor and better integration with voxl-portal. Still, when replaying logs for VINS, it is imperative that one replays them using the ION pipes, as our VINS solution is optimized for cl_mem ptrs. Note that when replaying ION pipes, it is recommend to stop camera-server before replaying -- as clean killing ION pipes via the voxl-replay args is currently being optimized. This should resolve the common segfaults experienced during the replay/benchmark operation itself.

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-benchmark-vio

Finally, I would recommend updating your VINS to the latest available tag on Gitlab

@Aaron-Porter , perhaps systemd-timesyncd works together with systemd to correctly interpret the clock adjustments, so that run-time of systemd services is properly calculated.

Alex

@Aaron-Porter Most likely jump is due to NTP aligning the clock. The other device that is time stamping using real time clock really should move to monotonic.

The overall goal is just to get time synced between the Lidar and the VOXL2's IMU. Oddly enough, I was looking through the voxl-kernel for qrb5165 and the driver for PTP is there. Is the physical layer chip not able to support PTP?

Where I see the driver in the Kernel:
https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel/-/tree/qrb5165-ubun1.0-14.1a/drivers/ptp?ref_type=heads

So something that I was seeing while testing this was having a bit of instability with Open VINS flying and altitude flying (Not Using VFC). I was seeing that voxl-open-vins-server stated that the IMU temperature was too high and kept resetting. After letting the VOXL2 cool down for a day I was able to have the Drone Fly in VFC mode but not sure how it flew compared to Position mode using VIO.

@Aaron-Porter ,

Are you asking about a specific camera? (which one)

In general, you should not specify max exposure (in camera server config) which exceeds 1/fps. This can be often overlooked, so we recently added a check that enforces maximum exposure to be slightly less than 1/fps : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/aa3ce587f6be769e1b07edf57f66e1eec40d4644

However, in some special cases, there may be other limitations. One case that I know of is the synced AR0144 at 30fps has a maximum exposure of less than half of 1/fps, otherwise it will skip frames, so our defaults for AR0144 are set to have 12ms maximum exposure. Also, you don't want to set the exposure too high for tracking cameras, since you will get too much motion blur.

Alex

@Aaron-Porter , the voxl-logger does not control what format the images are coming from voxl-camera-server. Currently, voxl-camera-server can output images in RAW8, YUV format and JPEG only in the case of a snapshot (not continuous). So, to answer your first question, the camera server does not support outputting PNG or JPEG in continuous streams.

voxl-logger already supports saving images in png or jpeg format, depending on the type of image that is being logged (RAW8 mono or YUV color, etc). You could tweak the behavior to your needs or add a flag to voxl-logger to force a logging format : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-logger/-/blob/master/tools/voxl-logger.cpp?ref_type=heads#L1455 .

Alex

@Aaron-Porter , thank you for clarifying. We resolved your issue offline, as this was a pre-release development effort.

Moving forward, all customers have two options:

if you already purchased M0065 without ModalAI bootloader (the board was using old px4io bootloader and firmware), you can request a free replacement that will be sent with our latest bootloader and firmware installed (please request via support email) all the new M0065 shipments will come with ModalAI bootloader and firmware

With the new bootloader / firmware combination, there is no need for STLink at all. The firmware will be updated via UART directly from VOXL2 or optionally via a USB adapter. The firmware update protocol is very similar to our ESC firmware update protocol, so we will be able to use voxl-esc tools to perform the firmware update.

We will be updating the docs shortly (https://docs.modalai.com/voxl2-io-firmware/) and will post an update here once it's ready.

Alex

@Aaron-Porter The tracking sensor does not need to be straight, but the extrinsics need to reflect the accurate position of the sensor relative to the IMU

if you monitor the qvio-overlay in voxl-portal, it's usually obvious what is going on. If you need help interpreting, please post a screen video capture of the qvio-overlay here

@Aaron-Porter So I made a mistake that the IMU-server was not running during my screen shots. But I figured out the issue. Yo can use the starling file you have to run the command,

voxl-configure-qvio factory_enable_imu_apps

This will tell qvio-server to look for imu_apps instead of imu0.

@Moderator
Thank you

So this is the correct functionality, and that the Data is updated relative to the IMU and not to the Body of the Drone.

@Aaron-Porter I am facing the same issue, is it solved?