@Viktor-Gal If you've already removed the board then sending in just the board as an RMA is fine

We have added support of the following barometers to voxl-dev branch of px4-firmware repo and you should be able to pick up the change tomorrow in the latest nightly build:

bmp280 bmp388 ms5611

http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/ (look for voxl-px4 and check build date).

the new barometers can be enabled connected to J19 (px4 i2c port 1, so -b 1) and modifying voxl-px4-start script:

qshell bmp280 start -X -b 1 qshell bmp388 start -X -b 1 qshell ms5611 start -X -b 1

You should disable the onboard barometer icp101xx, otherwise there may be a conflict where two barometers are publishing under the same instance (at least when viewed with px4-listener). We will investigate this issue.

Alex

@soraminds VOXL 2 is a Linux computer so you can just run Apache or any other standard web server. But be aware that voxl-portal is also a running web server so you would have to stop it or, even better, run your server on a different port.

@jonathankampia Brilliant! thankyou for figuring this out.

@voxluser12341 , the qrb5165-io limitation only concerns the UARTs that are connected to the DSP, so SSC_QUP2, SSC_QUP6, SSC_QUP7 (dsp uarts 2,6,7).

The limitation does not apply to any Application Processor (APPS_QUP) ports which show up as /dev/ttyHSx

qrb5165-io library could be extended to support multiple concurrent ports, but we have not done that yet, unfortunately.

Alex

@mkriesel,

For global shutter camera like AR0144, the center of exposure will happen at the time that you suggested:

int64_t center_of_exposure_ns = start_of_exposure_ns + exposure_time_ns / 2;

For rolling shutter cameras, this is not true because different lines are exposed at different times. In this case, the center of exposure, which means the center of exposure of the middle line ( 🙂 ) will be:

int64_t center_of_exposure_ns = start_of_exposure_ns + (exposure_time_ns + readout_time_ns)/2;

This means that you will need to know the readout_time (which is time it takes for the full image to be transferred from the camera). It is not currently exposed in camera server or the camera metadata.

Take a look at this resource, it should help understand the rolling shutter case if you need : https://www.1stvision.com/cameras/IDS/IDS-manuals/en/basics-shutter-mode.html , specifically:

shutter_global.png

shutter_rolling.png

Alex

@FIREBIRD

VOXL2:
https://www.modalai.com/products/voxl-2?variant=39914779836467
https://docs.modalai.com/voxl2-datasheets/

M0130 add-on board (1 USB 3.0 + 2 USB 2.0s):
https://www.modalai.com/collections/voxl-2-add-ons/products/m0130-3?variant=48186331693360
https://docs.modalai.com/lte-io-breakout-usb-hub-datasheet/

@Gary-Holmgren Thanks for the update!

@svempati Are you trying to access the mavlink data from VOXL 2 itself or from an offboard computer / ground station?

@Alex-Kushleyev Thanks, everything looks alright now that I've removed the other cameras from the config file

@tom thanks I had opened the board so I did not notice it, only if I had assemble I would have noticed it.
Thank you so much it worked!

@Jeremy-Frederick Okay, well then you will need to add support for such an external Mavlink enabled peripheral into voxl-mavlink-server. We don't currently support that.

@griffin Unless you have your network setup to manually cycle IP addresses every so often then your PC's IP address should stay the same. They're usually logged by mac address

@Eric-Katzfey Thank you for providing the updated package.
I will test it within the next three days.
I’ll get back to you with the results shortly.

@Vinny Thanks @Zachary-Lowell-0 @Vinny !!

@scosgrove , I just wanted to mention that our ESC driver for PX4 is also using UART running at 2Mbit. The Flight Control loop sends out commands at 800Hz and each control packet is 15 bytes long. Also one ESC channel (out of four) sends feedback to the DSP for every command. The feedback packet size is 16 bytes (at 800hz), that would be 12800 bytes/s. We almost never see missed RX data. I have also experimented with larger feedback packets (~42 bytes at 800hz = 33600 bytes/s received by DSP).

Can you please clarify how the data is batched when the byte loss happens - how many bytes are sent without a break?

Alex