@voxltester Only if it is connected to a GCS that sends the Mavlink SYSTEM_TIME message.

@Nitin-Varma-Vegesna I think it's this one: https://store.3dr.com/mini-gps-ublox-max-m10s/

@mkriesel First steps would be to verify that the correct propellers are installed, that all the propellers are spinning in the correct direction and that the motors are mapped correctly.

@Nitin-Varma-Vegesna None

@joseph-vale ,

to enable voxl-streamer and voxl-camera-server on startup, just use the following commands:

• systemctl enable voxl-camera-server
• systemctl enable voxl-streamer

Regarding your question about thermal radiometric readings, i am not sure - can you please elaborate? The default post-AGC 8-bit mode sends a monochrome processed image. The pixel value is related to the temperature, but the image itself does not provide the mapping from pixel value to temperature. Also, not all Boson units support outputting radiometric data.

I don't have much experience with this aspect (and I don't think we have any Bosons with radiometric output capability). Looking at some FLIR help, it seems that you have to use the 16 bit output (well it's actually 14 bit) and turn on linear T output and then the conversion from RAW pixel value (16 bit) to degrees is simple : https://flir.custhelp.com/app/answers/detail/a_id/3387/~/flir-oem---boson-video-and-image-capture-using-opencv-16-bit-y16

If this is the case, then here is how this could be tested (high level steps - don't worry if you don't know how to implement them at this point) :

• set up Boson to correct configuration (output RAW14, linear T, etc) using the FLIR SDK (using USB)
• configure VOXL2 to use boson driver that accepts 14 bit data (not 8-bit, which is default)
• voxl-camera-server will publish RAW16 unmodified images to an mpa pipe
• a client application can receive the RAW16 frame and apply the temperature conversion and publish the image that reflects certain temperature -> color mapping. Then this image can be used by voxl-streamer to be encoded with h264 / h265.

I have not actually tried that script (at the bottom of that help article) -- i wonder what would happen if i use it with a Boson that does not support radiometric output. Do you know?

I can help set this up if i can test it using non-radiometric Boson. It seems the conversion is straightforward, I could potentially add the support for this directly into voxl-camera-server.

Alex

@Rowan-Dempster ,

Yes, QVIO only runs as a 32-bit app due to the nature of the library from Qualcomm.

I tried to build the voxl-image-repub application for 32 bit and got the following error:

/usr/bin/arm-linux-gnueabi-ld: CMakeFiles/voxl-image-repub.dir/voxl-image-repub.cpp.o: in function `main':
voxl-image-repub.cpp:(.text.startup+0x228): undefined reference to `pipe_client_set_ion_buf_helper_cb'

So it seems like the 32-bit version of libmodal-pipe does not support sending ION buffers.

I just checked with the team - even though we have not tested the ION buffer sharing in 32-bit environment, it should work. You could try to build libmodal-pipe library and enable ION support : https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/blob/master/build.sh?ref_type=heads#L76 .

Then you would need to install that new library into your docker container where you are building your app, as well as deploy to VOXL2.

BTW in order to build the tools in voxl-mpa-tools i needed to disable -Werror and comment out a few targets like voxl-convert-image and voxl-inspect-cam-ascii due to lack of 32-bit version of opencv.

So.. if you really wanted the QVIO app to use the shared ION buffers, you would have to go that route..

Alex

@Zachary-Lowell-0 and @smiley ,

I just updated the docs to include more info on this https://docs.modalai.com/M0153/#misc-connector-pinout

Also verified that i could ping a i2c device connected to M0201 J4 and M0201 itself is connected to VOXL2 J7 via M0181 (there are other options how to connect M0201 to VOXL).

IMU -> [JST GH cable] -> (M0201 J4) .... (M0201 J2) -> [MIPI COAX cable] -> (M0181 J1) .... (M0181) -> (VOXL2 J7)

voxl2:/$ i2cdetect -r -y 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

(able to ping an i2c IMU board connected to /dev/i2c-4).

Please let me know if you have any additional questions.

Alex

@simiken1234 , Can you please clarify what exactly did not work in 4.6.6?

I have not tried it yet.

Let me check regarding 4.2, we may not be able to distribute it.

Alex

@Rowan-Dempster , sounds good, let me know how the testing goes.

Alex

@svempati said in No detections when running custom YOLOv8 model on voxl-tflite-server:

I just ran voxl-tflite-server directly from the command line instead of in the background via systemd - aka run voxl-tflite-server directly on the command line. I would recommend NOT quantizing your model as the directions in the train yolov8 do not recommend that.

Zach