Hi Steve,

You would likely want your own separate project that uses libmodal_pipe to create the client interface. That can be a systemd service if you want it on boot. MPA encourages lots of separate microservices and projects to all be compiled and run independently to avoid monolithic programs that grow too big and become hard to maintain. Examples such as all the voxl-inspect-*** tools in voxl-mpa-tools also serve as good starting points along with the modal-hello-client example you already found.

I hope this helps,
James

Hi Matthew,

When you try to run voxl-logger with the hires camera it should have given the following error message:

voxl:/$ voxl-logger --cam hires --samples 1
connected to ch 0 cam server: /run/mpa/hires/
ERROR only support RAW8, RAW16, and FLOAT32 images right now
got NV21 instead

The reason these are the only formats currently supported is because it uses opencv to save/load images. OpenCV is quick enough for black and white images, but simply too slow to be practical for large color images.

As an experiment I just made a new branch of voxl-mpa-tools with a slow but functional switch-case for the NV21 images produced by the hires camera. This will work for saving one or two images, but won't be able to keep up with a steady 30fps stream.

Here is the code if you want to try:
https://gitlab.com/voxl-public/modal-pipe-architecture/voxl-mpa-tools/-/commit/633adfdaf8162548d5df4218243a32e06d2ea7b1

Migrating voxl-logger to use a faster image compression library and/or hardware acceleration is in the pipeline but I can't promise a release date for that I'm afraid.

I hope this helps,
James

This is a known bug that was fixed in voxl-vision-px4 v0.8.8 which is currently on the development repo, scheduled to be merged into the stable repo in a week or so.

The bug is not caused by PX4, it was due the the handling of the specific mavlink packet containing console data. It should behave normally when not using the PX4 console.

Hello Aks,

I'm afraid there is no clean way in software to rotate the debug images other than copying the image byte-by-byte.

Typically we only use the tof_depth and tof_confidence image pipes for quick debug. voxl-vision-px4 makes real use of the sensor by subscribing to its full point cloud pipe and then projecting the 3D points into space using the known location and orientation of the TOF sensor as specified in /etc/modalai/extrinsics.conf

Best,
James

Hi Serge,

The file /etc/modalai/extrinsics.conf contains the location and orientation of IMUs, cameras, body, etc. Likely this was never configured and both voxl-qvio-server and voxl-vision-px4 think the IMUs are in their default orientation which is different than VOXLCAM.

You should be able to run voxl-configure-extrinsics and select the option for Seeker/VOXLCAM. Then reboot and both voxl-vision-px4 and voxl-qvio-server will load in the new extrinsic parameters.

Best,
James

@stevet said in VOXL not connecting to QGC:

voxl-mavlink

When using MAVROS the vvpx4 offboard_mode setting should be set to "off" since the figure 8 and trajectory modes let vvpx4 send offboard commands which would naturally conflict with offboard commands coming from MAVROS.

the "HP: requesting home position" message is perfectly normal, I've always seen it come up and it's never stopped me from running the mavros figure-8 example.

Hello, do you mind sharing the contents of the config file /etc/modalai/voxl-vision-px4.conf and the output from voxl-vision-px4 when started from a terminal? I'd like to see what it prints before getting to the ringbuf error. Thank you!

James

@hmlow

Yes, PX4's obstacle avoidance and Collision Prevention are separate features. We only support the Collision Prevention functionality which is governed by the PX4 CP_DIST and similar parameters. Make sure the COM_OBS_AVOID parameter is OFF (0) in PX4

James

Hello,

VOXL and VOXL Flight contain different IMU combinations. on VOXL, IMU1 should be preferred, and on VOXL Flight IMU0 should be preferred.

Configuring MPA services with voxl-configure-mpa will automatically select the correct IMU for the VIO service based on board part number.

I've updated the documentation to clarify: https://docs.modalai.com/voxl-flight-datasheet-imus/

Best Regards,
James

Hi Steve,

It's possible for you to host your own opkg repo and point opkg to two repositories simultaneously. You could also install the new ipk in your docker manually without the install_build_deps.sh script and then "commit" the docker image so it's still there next time you start it.

I briefly checked out your fork and I would suggest two alternate routes:

1. The simple helper does the same sort of raw read on the pipe that your new function does, but with additional checks and signal handlers to ensure safe start/stop behavior. This is extensively tested and took a while to be robust.

2. There is an existing function called pipe_client_get_fd(int ch) in the library that will allow you to retrieve the pipe file descriptor and do any custom read behaviors you desire should the helper threads not over your specific use case. You can then have your raw_read function built into your custom project without needing to rebuild libmodal_pipe or worry about managing that separate dependency.

I hope this helps,
James

Hello, thanks for the videos. I just noticed in /etc/tag_locations.conf your tags are listed as having an "unknown" location type. Change the location type (loc_type) from "unknown" to "fixed" and they will be accepted as valid for fixed-frame relocalization.

an environment may contain moving tags, or tags with unknown location. Therefore it in unsafe to assume every tag is in a fixed location. The header at the top of that configuration file explains in a little more detail:

 * A tag can be flagged by the user as fixed, static, or dynamic.
 *
 *  - fixed: The tag is at a known location in space as described by the
 *    T_tag_wrt_fixed vector and R_tag_to_fixed rotation matrix. These fixed
 *    tags are used by voxl-vision-px4 for apriltag relocalization.
 *
 *  - static: A static tag can be trusted to be static (not moving) but does not
 *    have a known location. For example, a landing pad.
 *
 *  - dynamic: A dynamic tag can be expected to be in motion such as an object
 *    to be tracked or followed dynamically.
 *
 *
 * If the tag is fixed then you must specify its location and rotation relative
 * to the fixed reference frame. Otherwise the translation and rotation
 * parameters can be ignored.

I'll update the public docs to make this process easier to get going.

Best,
James

Hello,

voxl-suite 0.4.6 is a little outdated now. You should be able to run opkg update and opkg upgrade to update to voxl-suite 0.5.0.

voxl-tag-detector and voxl-vision-px4 are meant to run as services in the background. If you launch them manually from the command line you will see something like:

existing instance of voxl-tag-detector found, attempting to stop it

Since two instances of the binary shouldn't run at the same time, it stops the background service first before continuing. The service would then need to be started again in the background with systemctl start voxl-tag-detector. Alternatively you can use the voxl-inspect-* tools which simply print output data published by the service without stopping the service. voxl-inspect-tags will show when tags are detected similar to voxl-tag-detector -d but in a less invasive way.

https://docs.modalai.com/voxl-inspect-tags/

Similarly, voxl-inspect-pose will show the local and fixed-frame locations of the drone without needing to launch voxl-vision-px4 manually which also kills the background instance of voxl-vision-px4.

10.6cm is very small for an Apriltag and it is unlikely the tracking camera will be able to identify it from the air. I see you are holding it very close (13cm) away in your debug prints. We typically use tags around 40cm large such that they can be seen from 2+ meters away with the wide fisheye lens.

Note that when the tags are detected, the output of voxl-inspect-tags and voxl-vision-px4 --debug-tag-cam will both print the location and rotation of the tag's coordinate frame with respect to the camera's coordinate frame. This relation has nothing to do with VIO or world/body coordinate frames. voxl-tag-detector only has the camera input stream available and is unaware of the camera's mounting position on the drone, or the drone's location in space. All coordinate transforms are done in voxl-vision-px4.

Running voxl-vision-px4 --debug-tag-local will show where it thinks the tag is with respect to the local coordinate frame (centered wherever VIO initialized). If the tag does not move, you should be able to move the drone around and the predicted location of the tag in local frame should remain mostly constant with a little noise from the detection error. (assuming the tag remains in view of the camera). I recommend running voxl-inspect-tags simultaneously in another window to ensure the tag is detected while doing this.

Although this video is based on an older software stack, the geometry and coordinate frames referenced have not changed. I hope this helps a little in understanding the debug outputs.

https://youtu.be/0j7CjmDvluM

Let me know if this helps,
James

Hi Steve,

You would likely want your own separate project that uses libmodal_pipe to create the client interface. That can be a systemd service if you want it on boot. MPA encourages lots of separate microservices and projects to all be compiled and run independently to avoid monolithic programs that grow too big and become hard to maintain. Examples such as all the voxl-inspect-*** tools in voxl-mpa-tools also serve as good starting points along with the modal-hello-client example you already found.

I hope this helps,
James