Can you show an example output of what you are seeing? Also, which modem are you using?

@BrandMetis-Width
Also this might be of interst to you - https://github.com/facontidavide/Bonxai

Not yet ROS integrated - but could be an excellent match.
Core implemented in < 1000 lines of code too.

Hi @John-Mccarty , checking in to see if you've progressed at all through this? The process is a little picky and sometimes requires a few tried.

@Aldo-Castro-Freire We use Google Cloud to host our VPN servers so I would assume AWS would be just fine. This sounds like a configuration issue to me that the OpenVPN forum could help you out with.

Yep,

This was an bug with voxl-utils v0.8.4 sourcing ros files in the wrong order, I just pushed a patch (0.8.5) up that fixes this, should be available in a few minutes.

Hi @Cole-Mathieu ,

We have a little bit of documentation here with respect to AUX outputs. The FlightCore form factor only has the 8 PWM outputs, so it's a little limited, but we've used it to control a two channel gimbal:

https://docs.modalai.com/voxl-m500-gimbal-user-guide/#auxillary-outputs

For anyone who runs into this same issue, I changed my subscriber to listen to /map/tof_pc (which has the PointCloud2 type). My code (to extract the z value) is this:

# get the depth image dep_frame = np.fromstring(data.data, dtype=np.single) # get numpy array dep_frame = dep_frame.reshape(172, 224, 3)[:,:,2]

@Daniel-Ryu

I figured. We just wanted to double check that this was the case. Thank you!

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.

@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

@Matt-Turi @Chad-Sweet

Sweeeettt. Thanks guys

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!

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.

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

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.

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

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

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.

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