@Vinny thanks for the reply!

Is this link suitable for both the bigger camera and 2 smaller cameras in the picture?

@tom Thank you for your quick response. Do you have a model with these dimensions and technical specifications that is also waterproof, or is it possible for you to develop one? Thank you again in advance for your response.

@Alex-Kushleyev
Thank you for the information and support!
the calibration worked well after stopping other services.

Akira

@Robbie-McCue yes this worked thank you so much Robbie!!

Hi @Riccardo-Benedetti and @paul-foley ,

This issue is not common. There is a potential condition (which we are going to look into) when a MPA client crashes and does not close the pipes properly, the MPA server side will keep the allocated resources open. If the client crashes repeatedly, eventually there will be no more memory for the Kernel to allocate for the new pipes.

Please check to make sure that you have no client processes that are subscribing to image streams and are crashing and restarting (perhaps restarting automatically by systemd). It is possible that a process that is not your test app is misbehaving for some reason and is causing this memory leak by continuous crashing and re-starting.

Also, what if you just use voxl-inspect-cam to inspect the single camera stream and no other camera clients running, does the same issue happen?

Alex

@tom Thank you @tom

@tom Thank you very much for your information.

@Alex-Kushleyev The IMU is being configured with an 8K ODR so by increasing IMU_GYRO_RATEMAX you are reading the FIFO more often but reading less samples each time. So you are mainly increasing the overhead of context switching. Can you characterize how much the load increases just by increasing IMU_GYRO_RATEMAX and not doing any of the extra UART IO? Unfortunately we don't have a lot of control over the low level implementation of the IO drivers that are in the Qualcomm code. And there is no DMA that could help lower IO overhead. One idea would be to lower the ODR to 1K so that you are only reading one sample from the FIFO at each interrupt.

Thank you @Alex-Kushleyev for the clarification. Currently I just redefined the magic numbers on my own and voxl-inspect-pose works as usual. I am hoping that this breaking change only affects a small number of use cases. If anyone else faces the same issue with magic numbers theres at least the discussion that might help them as well 🙂

Hello @LV-Office-Holder,

The M0138 racing ESC only has two I/O pins and they are used for aux PWM output. PWM input is disabled for this ESC due to lack of PWM input for each ESC channel.

The ESC protocol example can be found here : https://gitlab.com/voxl-public/support/esc-driver as well as part of PX4 implementation : https://github.com/modalai/px4-firmware/tree/voxl-dev/src/drivers/actuators/voxl_esc . I would suggest referencing the PX4 implementation since it has the latest updates.

Additionally, we have voxl-esc test tools (python) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc . The test tools allow you to spin motors, plot data, perform firmware and parameter updates.

Please let me know if you have any other questions.

Alex

Hey @dvz, thanks for your query

We’re currently in the process of updating the voxl-tag-detector to support additional AprilTag families beyond just the 36h11.

If you’d like to try this yourself in the meantime, the following line in main.cpp creates the detector for the 36h11 family: here

To add support for the tagCustom48h12 family, you can:

Add the include:

#include <tagCustom48h12.h>

Replace the detector creation line with:

tf = tagCustom48h12_create();

Please note that this change may affect the current functionality, you’ll likely need to make additional modifications in main.cpp to ensure it builds and runs correctly.
As mentioned, we’re actively working on making this a much smoother process in the future. But if you’d like to get started now, the above steps should point you in the right direction.

Hello,
could anyone please help me with my question? The data cannot be found in your documentation. But it can be found in your documentation for other cameras.

@nickrobbins I would take at stinger as a place to start: https://www.modalai.com/products/stinger-vision-fpv?variant=48373207695664

It is on the Blue UAS list: https://www.diu.mil/blue-uas-cleared-list (Stinger Vision FPV)

@cguzikowski these had been marked NRND (not recommended for new designs) for a while and we removed them due to lack of demand.

We may still have some on hand if there is something specific you are looking for. Please reach out to modalai.com/contact and we can see what we can enable

@Rishi-gnanasegar There is not going to be an easy way to install after we have built the drone. It is not meant to be plug and play as the plastics are different based on which sensors have been ordered when the drone is ordered.

@crowley stinger is our FPV drone solution: https://www.modalai.com/products/stinger-vision-fpv?variant=48373207695664

We offer various levels of kit that can include goggles, transmitter, etc.

Hi @SKA
Apologies no one responded promptly.
From what I gather, these are best to be sent back as an RMA and we can try to recover them.

D1 (green) is an indication of the local 3.3V power being Good. So, that implies you have 3.8V input, and the 3.3V reg is OK.
DS2 (RGB) is controlled by Qty-3 GPIOs from the SoC. This can briefly blink on boot until the GPIOs are configured by apps software.
D2 (green) is the 5V USB VBUS USB1 (10-pin) port power indicator, which only comes ON after the QRB5165 boots and Apps controls the GPIO to turn the VBUS ON.

On failed SW loads, it is common to diagnose that by seeing DS2 or D2 blink, which indicates boot loops. D1 should NEVER go off, if so, something is wrong in HW or cabling.

We do caution any customer that sets up their own CI or internal validation automation to include a nice pause before repeated power cycles. A common 5 second rule is good to let the large caps discharge, or certain ICs will never fully reset. This is the most common cause of "bricking" devices.

The RMA is your best bet here and we can try to recover them for you, or diagnose for any other issues: https://www.modalai.com/pages/rma

@Allister-Lim ,

If you are not monitoring the battery voltage while working with your battery-powered VOXL, it is possible that you are over-discharging the batteries to the point of failure. Especially with LiPo batteries, it is unsafe to over-discharge them, so please be careful. (It seems that you are also using LiPo batteries, in addition to ModalAI Li-Ion batteries also shown (green)). There is nothing wrong with using LiPo batteries, but you have to be more careful with those. Over-discharged batteries lose capacity and Lipo Batteries may become dangerous.

It is a good idea to use an appropriate DC power supply when working with VOXL2 while it is powered on continuously. 12V 3-5A Power supply, connected to the APM (which will provide 5V for VOXL) should be sufficient. You should have no problem finding one, but in case you need, here is a link to the AC adapter that we sell : https://www.modalai.com/collections/accessories/products/ps-xt60

Alex

Hi @isaac,

We only have two variants of the kernel for VOXL2. The default (original) kernel and one that supports M0173. (mach. var 1.0.0 and 1.0.1 respectively, which you can see in output of voxl-version).

If you are using M0135 camera interposer board, you would have to use the first kernel. However, this kernel is set up for a stereo setup in J8, so J8U is not available for regular cameras. If you are using J6 and J7 for cameras, then using M0135 in J8 to enable J8U, is not really possible, even with a kernel modification (due to some shared reset lines that will affect several cameras, if enabled). I would need to know exactly what cameras are connected where in order to provide more details.

Now, if you use the second kernel in combination with M0173, you can also use other adapters such as M0181, M0172. Enabling a hi-res camera in J8U has been discussed in the following thread, with images and instructions : https://forum.modalai.com/topic/4757/connecting-2-boson-cameras-and-2-mipi-cameras-4-cameras-total . Please note that you can use the smaller boards such as M0181 and M0172 instead of M0173 with the second kernel.

I would strongly suggest going the second route, but if you have an issue with this, let me know. I don't have the full understanding based on your brief question.

Alex

@Karthik-Bharadwaj You'll need to insert this into the unused XT30 connector: https://www.modalai.com/products/mcbl-00109?_pos=1&_sid=cc83b4694&_ss=r

3A is more then enough to power the drone on the bench, just make sure never to spin motors on wall power! (You can damage the drone and will not be able to RMA it)

In order to disable arming you'd have to look through the PX4 parameters