@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

@voxl-phoenix , this may be a hardware issue because VOXL2 will boot just fine without M0173 camera front end plugged in (if the hardware is OK). It is possible that one of the camera connectors (where M0173 plugs in) has broken off or is loose, causing a hardware failure. If you would like a better diagnosis, please share a video of the voxl2 not booting, so we can see the LEDs (i realize there are green leds on top and bottom, but the way your image shows, you can see both of them. Also, in this non-booting state, does the VOXL2 show up as any USB device when plugged into a linux machine using the main USB C connector?

Alex

Hi @dew54 ,
Are you willing to share your schematic with us? We always perform a courtesy review of any customer design.
What Alex said is true but there are some more subtle nuances because our Microhard design pre-dates Voxl 2. Everything was designed to be backwards compatible but a custom design can certainly step on some toes of the 5V network.
Let us know if you are willing to share and we'll email you to exchange the Sch.
Thanks!

@bkim1301 I would start by connecting the VOXL 2 UART 7 to a PC with a serial to USB cable. Make sure you can communicate back and forth using that setup and then do the same with the Teensy before connecting the Teensy and the VOXL 2 together. It's often very helpful to use an oscilloscope on the rx / tx lines to verify that there is actually data flowing.

@antenna-eng What hardware do you have connected to the VOXL 2 board? Cameras etc.

Hi @scosgrove,

Thanks for the details.

On the DSP there is a dedicated HW block for each UART (similar for the UARTs connected to the application processor). All the UARTs supported on DSP have hardware FIFOs. Since you asked about the size:

DSP UART2 has 64-byte low level FIFO on RX DSP UART6, 7 have 128-byte low level FIFO on RX

When fifo is close to filling up, there is an ISR that triggers on the DSP which transfers the data from FIFO to other memory, and then the data propagates to the user. I wonder if there is some issue when fifo is read while another byte is incoming into fifo at the same time.

Which uart port are you using for this test?

I can do some testing with bursts of 70-250 byte packets. In the past we have tested continuous data transfers of several KB but not at high rates. Also, what baud rate are you using now?

Alex

@Jetson-Nano The M0173 kits include the IR filter on all sensors.

@tom Is there a way to voxl-logger the outputs from voxl-inspect-cpu and play it so that I can see the graphs on voxl-portal? Currently I can only voxl-inspect-cpu or view the graphs in real-time on voxl-portal, but I would like to record the data when the drone flies and review it post-flight

@Zachary-Lowell-0 as mentioned I have set offboard-mode in voxl-vision-hub.conf to "off".

I did a flight test shifting to offboard-mode,

The drone was able to execute the script in a stable way without any jittery motions or trying to come back to home position.

These are the flight logs,
https://review.px4.io/plot_app?log=e32a28df-cbba-4765-8499-6fe46e2ff890

@Eric-Katzfey thanks! I got started using mavsdk and pymavlink

Hello @zauberflote1! Thanks for sharing.
Made any progress on this package?

@Alex-Kushleyev Correct, I just used the last 4 more powerful cpus. That was enough of a performance boost to run my optimization at the frequency I was hoping for. I didn't try using all 8 threads, I can give it a shot if that's useful information for you

@tahawaru Okay, that shows you have 1.14.0-2.0.78. If you want to build 1.14.0-2.0.63 then you need to check that version out instead.

@modaltb

Hey Travis,

Thank you very much for your explanation and for passing on the link.
I understand how it was done now.

I will consider what is the next possible option for the project.  
I appreciate your time.

Best Regards,
Leon

@nickk14

Awesome, glad to hear it! Yeah, we've actually mounted fans to our boards that run multiple models simultaneously because the thermals definitely get up there. Might be worth thinking about depending on your application.

All the best, let me know if I can help out in any other way.

Thomas

@Moderator Thank you for the response.

I did come across this product of yours here: https://www.modalai.com/products/mdk-m0135?_pos=1&_sid=e4d19a51b&_ss=r that should work great after looking through some of your user guides and technical documentation.

@eric

Sorry for the late response on this!!

Your best bet would be to just try it out, I can't say without trying it myself. It's possible it works, it's possible something fails. I've never had to deal with this so I can't say for certain.

It's also worth pointing out that voxl-tflite-server is more meant to be an example of how TFLite models can be run on VOXL and not an in-depth ML framework for deploying custom models. If voxl-tflite-server doesn't support it, by all means fork the repository and build out the functionality to be able to. Even better, make a pull request with that functionality and I'll test and approve it!

Hope this helps,

Thomas Patton

@david-devassy

Hey David,

We do support deep learning inference on VOXL2! You can check out this page on our docs to read more about our deep learning capabilities. Out of the box our YoloV5 model gets around 30 frames per second. You also mention object avoidance and SLAM using path prediction. We have our own implementation of Visual Object Avoidance (VOA) which you can read about here.

You could certainly create custom implementations of both of these on VOXL! However I want to highlight that our code for both of the above is C/C++ and not in Python for speed reasons. I can't give you a reasonable estimate about Python performance but it would likely be slower.

Hope this helps! Let me know if you have any other questions.

Thomas Patton
thomas.patton@modalai.com