Thank you.

@Shlok-Agarwal I assume you've taken a look at this page in our docs: https://docs.modalai.com/unbrick-voxl/ If not, give that a read through and it'll give you a bunch of good info. Were you able to ADB into the VOXL before you started the flashing process?

@Nirge You should use voxl-wifi for wlan0.

I found the QGC EKF2_AID_MASK parameter settings above (configuring to 280: Vision position fusion, vision yaw fusion, vision velocity fusion) to allow the seeker to enter position and off-board modes. Prior to configuring, QGC was receiving VIO but was still unable to enter position mode as referenced here To make the forum search engine happy: seeker position mode rejected

Alright! Thanks for the update, I'll likely use this post to get some updates to our docs, appreciate it!

Hello @alarm_hq! Please see the updated readme on voxl-mapper's dev branch for an overview guide of this package. As for the timestamp too new error, this error typically arises when there is a VIO blowup, and one way to prevent this is by ensuring that the tracking camera is correctly calibrated pre-flight. Also, please see the overview guide for instructions on viewing, as RVIZ is no longer utilized!

Thanks, so what is the emulator for exactly? emulating native compilation? I am unclear of the emulator use case if it is not intended to emulate the voxl platform for application testing. Let me know, cheers!

Hey @alarm_hq! The props for the Seeker development drone can be found here.

@alarm_hq said in How to: Seeker ESC calibration: And if I've already made the "mistake" of reflashing px4 firmware, is the closed loop RPM control affected? The ModalAI ESCs used on Seeker have their own firmware and settings stored on the ESC itself, independent from PX4 so your ESC is fine after changing PX4 firmware.

Thanks Chad. We did the calibration again with a better calibration target, and this fixed the problem.

Have you looked at voxl-tag-detector?

Hello, There were a few issues with the uart loopback example: the test buffer size was not handled properly (if test size is larger than HelloWorld strin the sleep time was not enough to allow the transfer to happen (the write function is non-blocking, it seems) I have made some fixes here: https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/dev/lib/apps/voxl-uart-loopback.c Now the behavior is as shown below.. please try it. ./voxl-uart-loopback -d 7 -b 9600 -s 20 INITIALIZING Sending 20 bytes: 0123456789:;<=>?@ABC Transfer should take ~20833us, sleeping for 25833us (+5000us overhead) Reading back data... Received 20 bytes: 0123456789:;<=>?@ABC closing uart bus PASS ./voxl-uart-loopback -d 7 -b 9600 -s 500 INITIALIZING Sending 500 bytes: 0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ Transfer should take ~520833us, sleeping for 525833us (+5000us overhead) Reading back data... Received 500 bytes: 0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789:;<=>?@ABCDEFGHIJ closing uart bus PASS

Hi Prasobh, It looks like rosnode got an invalid metadata when reading from the hires camera pipe. This is an uncommon issue and should really only occur if the CPU is overloaded and starts throttling the client reading the camera images, eventually overflowing the camera pipe, thus getting out of sync. Additionally, it says that the data pipe disconnected, possibly indicating a problem with voxl-camera-server. If this occurs again, checking the logs with journalctl -u voxl-camera-server may provide some useful information as to what issue may have occurred on the hardware side.

That cable was posted as a mistake, it is now deleted. You can stream any sensor connected to QGC. This doc here articulates all of the possible connections

Interesting, can you post a picture of the hardware setup you are attempting to use that isn’t working?

The VOXL platforms are all open, with the code available at https://code.modalai.com . This enables our customers to modify however they see fit. The qvio server that ships takes ~33% of one CPU core (out of 4 cores). So it might not be a worthwhile exercise to move that to the could. If you were processing a much larger state estimate, like a full keyframe SLAM, then that processing could be done on a server. It might be hard to close the control loops in flight if you are trying to fly with it. As an outer loop though, it should work fine.

Also, ensure you aren't connecting to your VPN with the same key on a different machine.