Hi @Alex-Kushleyev,

Now it's working!

Thank you so much for your help and quick answers.

Best,
Luca

@Daniel-Rincon Yes, please start a new post for the VIO question

@constantines Unfortunately, the PX4 Mavlink module is only running on the applications processor (Linux) and not on the DSP side. Mavlink would have to be added to the DSP PX4 build.

@Hector-Gutierrez thanks for the suggestion. However, I have now seen this unstable behavior in all modes (manual, altitude, position and offboard), both indoor and outdoors. I suspect that qvio is failing and trying to reset mid flight (Error: Not stationary was observed multiple times on the qvio_overlay page on VOXL portal). I don't think the GPS is even being used (QGC reports 100 HDOP and 0 satellites). The only mode where the UAV is controllable is Manual, but the qvio error is still present.

@Alex-Kushleyev would you be able to share some insight into what could be happening? How can we resolve this issue?

Thanks,
George

@h3robotics ,

Yes you should be able to test the Hadron on J8 using the instructions from the docs page (https://docs.modalai.com/voxl2-hadron/) -- just make sure you use Boson sensormodule 4 and ov64b sensormodule 5 (and camera IDs will still be 0 and 1 respectively, if there are no other cameras attached / detected).

At this point you do not need to build a custom kernel, just need to use kernel variant 1 because it enables independent camera support on J8 which is needed for Hadron. Please note that you would not be able to use our standard ucoax camera on J8U because the camera reset signal is still not correctly patched through to J8 (which would require a kernel modificaiton). But in Hadron use case, camera reset is not used (both the IR and RGB camera are always on, so it happens to work out 🙂 ).

I agree, it may be more convenient for you to switch to using the M0173 camera front end, so you can use a single kernel variant and also this would be a more future-proof approach.

Alex

@tonygurney , I am assuming that you are using the ESC hardware version M0134 (you can confirm using voxl-esc scan tool.

Here is the datasheet for M0134.
https://docs.modalai.com/modal-esc-datasheet/

This ESC has an option (via installing a 0 ohm resistor) to provide 3.3V to pin 1 of J3. This is the same voltage that is used for the MCUs that run on the ESC and should be used with caution (if this voltage rail is brought down by overloading, the ESC will shut down). Please see image below that shows where 0 ohm resistor should be (carefully) installed to enable 3.3V on pin1 of J3 (marked in red)

m0134-diagram.jpg

If you actually wanted 5V (VAUX), that is available on the other side of the board via two test points at the edge of the board. This voltage rail is provided by a separate switching regulator. See the following section : https://docs.modalai.com/modal-esc-datasheet/#neopixel-led-support

If you REALLY need 5V to be present on pin1 of J3, then you can add a small wire jumper from the VAUX test point directly to the pin1 of J3 (which is marked with a white dot). This pin 1 of J3 is normally disconnected. Please only do this if you are comfortable performing this type of soldering and we cannot guarantee the results :).

Alex

@Avery-Cuevas Yes, the VOXL powers up and I've tried using different USBs and still no result. I even tried reflashing the system, but it won't detect fastboot and adb devices

@Inverse-AJ @rogerli
Hi, I also struggled with the OBSTACLE_DISTANCE MAVLink message not appearing in the MAVLink Inspector. Moreover, obstacle avoidance was not functioning after I upgraded v1.3.5 to ModalAI SDK v1.5.0. If you're experiencing this issue, ensure the following:

Set MPC_POS_MODE to 0 (Simple Position Control) or 3 (Smooth Position Control). The default value (4, Acceleration-based Input) is incompatible with ModalAI’s VOXL platform.
Set COM_OBS_AVOID to 1. This enables obstacle avoidance in PX4.
Set CP_DIST to a value greater than 0. This specifies the critical distance for collision prevention.
Ensure your drone has a valid home position or local position from QVIO. This is required for proper navigation.
Ensure your drone is in Position Hold mode. Obstacle avoidance requires this flight mode.

Although the OBSTACLE_DISTANCE message does not appear in the MAVLink Inspector, QGroundControl displays the obstacle distance overlay in its telemetry view, and the drone successfully performs obstacle avoidance. Note: This applies to ModalAI SDK v1.5.0; check for updates in newer versions.

f0d0fe9f-61ff-4287-9210-186dafc0879a-Untitled.jpg

@garret Here's the source code for our branch of Gazebo: https://github.com/modalai/PX4-SITL_gazebo-classic/tree/voxl-dev

@Alex-Kushleyev Thanks again for the help. Unfortunately as it turns out, even though I have a Boson 640+ FLIR told me that the version I have is right before they started providing the MIPI output. I can still use the UVC interface, but it doesn't look like the Boson+ that I have can use the MIPI adapter after all. I don't know that many others will have my problem, but you guys might want to note that only the newest version of the Boson camera will support the MIPI adapter kit (https://flir.custhelp.com/app/answers/detail/a_id/6245/~/flir-oem---boson-software-versions).

Matt

Sorry If i have asked the wrong question. I don't have much experience. Any help is appreciated.

@Alex-Kushleyev Hey Alex, thanks for your reply, I managed to run the model by adding a specific helper, also converting my model several times to achieve the necessary parameters, the only problem I have now is performance, it runs at about 5fps, it is trained with yolovo8M, I think that may be a factor.

@Alex-Kushleyev I'm unfortunately still seeing the same result with no cameras being detected from voxl-camera-server -l. I've tried J6 with the Lower slot on M0084 and the appropriate camera config which loads the correct .bin file to /usr/lib/camera/. I get the same result with both the AR0144 and the OV7251. Though I do hear the OV7251 when it's connected. Any other ideas you have to try other than replacing the M0084 connection cable?

After some additional investigation I was able to resolve this by replacing the include:

#include <c_library_v2/common/mavlink.h>

with:

#include <c_library_v2/development/mavlink.h>

in actuator_test.cpp