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.

Thanks @modaltb , I appreciate your feedback. I think the usb-to-ethernet can make sense at least for proof-of-concept. @Chad-Sweet Yes, I am aware there is already a companion computer on the VOXL Cam. In my current work, I've already got an autonomy stack implemented on-top of a custom px4 drone platform with the upboard as the companion. My first interest is to add the VOXL Cam purely as a "tracking module" to replace something like the intel t265, and integrate the odometry out of it into my existing software. This would give me a way to evaluate the VOXL Cam in the use-cases I am exploring with a drone/autonomy configuration that is known to work. From there, depending on how well it works, I might consider replacing the upboard with the VOXL Cam, but that would not be the first thing I would do, as I would have quite a bit of software to re-work/port edit: It's good the VOXL can already run ros; I figure I could use voxl_mpa_to_ros to pass the VIO data over ROS from the VOXL to the Upboard in this PoC just to get started easily.

Hi @Chad-Sweet, even though this is not public (yet?), I setup a docker running open-vins. It runs without problems but I keep getting fast divergent behavior. Do you happen to have a launch file / parameter settings for open-vins with good parameter estimates for the flight-deck platform? I am not sure if my I set the extrinsics correct. I thought it must be simply the inverse of the output of voxl-inspect-extrinsics as open-vins expect a T_C0toI matrix: <rosparam param="cam0_wh">[640, 480]</rosparam> <param name="cam0_is_fisheye" type="bool" value="true" /> <rosparam param="cam0_k">[277.207560, 277.285144, 335.460288, 218.329580]</rosparam> <rosparam param="cam0_d">[-0.002486, 0.006832, -0.006556, 0.001300]</rosparam> <rosparam param="T_C0toI"> [ 0.0, 1.0, 0.0, -0.015, -0.70711, 0.0, 0.70711, 0.00283, 0.70711, 0.0, 0.70711, -0.0212, 0.0, 0.0, 0.0, 1.0 ] </rosparam> Another possible reason would be badly calibrated imu noise values. A reference file would be really helpful. Thanks!

@Matt-Turi @Chad-Sweet Sweeeettt. Thanks guys

@Chuck-Bokath Great to hear that you're making progress. As for developing your new program you can use the voxl-emulator docker image: https://docs.modalai.com/voxl-emulator/ in order to compile programs for VOXL on an Ubuntu machine. Here is a good doc on MPA https://docs.modalai.com/voxl-sdk/#what-is-modal-pipe-architecture-mpa

Hi @Aldo-Castro-Freire , The docker on target is somewhat old (see this post) and there's a chance there's compatibility issues going on with docker hub. We've tested with google cloud registry and had success but haven't tried docker hub.