@Namho Hello. Have you found a solution to this issue?

@Alex-Kushleyev

Alex,

I've had some more luck this week. I am able to get motors spinning with the newer M0065 board. The SDK 1.1.2/voxl-suite/voxl-px4 package did not have the parameter VOXL2_IO_PWM, so I could not set it via QGroundControl and px4-param set would fail too (although I could set VOXL2_IO_FUNC1/2/3/4). After reinstalling the SDK a few times, the missing parameter finally appeared. Also, I assumed that in the voxl-px4.conf file that setting ESC=VOXL2_IO_PWM_ESC would set everything up, but VOXL_ESC_FUNC1/2/3/4 parameters were still left as 101/2/3/4 and causing issues as well.

Based on your last reply, a solid orange LED seems to not be a problem, since I'm using an SBUS receiver, and it is probably sending data at a high rate to the flight controller.

The ESC calibration process fully completes, actuator test is functional, and the motors spin-up after arming now. I believe the solid orange LED was a non-issue, but the missing parameter and VOXL_ESC_FUNC unconfigured parameters were. Thanks for the help.

One thing that is worrisome is that the chip on the bottom of the board is searing hot and must be cooled.

v/r,

Julius Marshall

@Eric-Katzfey Thanks for your reply. In the screenshot of the original post, no GPS unit was attached. After reading your reply, I attached an M8N GPS Unit to J19 and got this response from the px4 shell when the variable "GPS" is set to "AUTODETECT" in voxl_px4.conf (I'm indoors so no satellites are detected; cannot go outside w/ this UAS):

When I set "GPS" to "NONE" in voxl_px4.conf I get this output from the px4 shell:

I imagine setting GPS to NONE with or without the M8N attached yields this result.

In either case, the VOXL 2 IO still shines a solid orange LED. When I arm and increase throttle, no motors spin.

Primary Issue: Motors will not spin after arming.
Hardware: VOXL 2
Configuration: Custom
SDK: v1.1.2

Hello,

I received five M0065 VOXL 2 IO boards this week. I have a custom multirotor with VOXL 2 running SDK v1.1.2 (I'm assuming these new M0065 boards come with the latest firmware and bootloader). After connecting the M0065 boards to the VOXL 2 and powering on, all five M0065 boards first show the boot up pattern shown here for about 1 second, then the orange LED shines solid. The green LED is solid as well. I'm not sure if the legacy M0065 firmware and current M0065 firmware have the same modes and LED patterns listed here.

I have the system wired as such, with the VOXL 2 J18 connected to the VOXL 2 IO J4 connector. I have PWM output (M0022) connected to J1. I have ESCs connected with signal and ground wires only. I have RC input connected to J3. Regardless if J1 or J3 or both are connected, the orange LED shines solid.

With J1/J3 both connected, in QGroundControl I see radio channels and am able to arm/disarm, change flight mode, enable/disable kill switch etc from my RC transmitter.

When I arm, and increase the throttle, the motors are not spinning.

I notice a three other things that may indicate problems. First, when I calibrated the ESCs (following the instructions here) the final chime was not made (the last two long dings in the sequence).

Second, in the top left corner of QGroundControl's display next to the flight mode, "Ready" and "Not Ready" switch every 1 second or so with no warning message appearing in QGroundControl. I decided to run voxl-px4 not as a service but in the shell so I could see the info. (Third) After inital configuration this appears repeatedly:

We have older M0065 boards (with the older firmware/bootloader) and other VOXL 2s with SDK 0.9.5 that do not experience the issues above. However, we would like to use the latest SDK on our VOXL 2s on our custom drones.

Any advice would be appreciated. Also, if necessary, we can send these "newer" M0065 boards back alongside our older ones which would need the updated firmware and bootloader.

Thanks!

Julius

I downloaded the "CenterNet MobileNetV2 FPN Keypoints 512x512" model from the TF2 Object Detection Zoo and customized the voxl-tflite-server software to load this model and run inference on a set of images. In this model, there are a few operations which are not supported; however, 120 operations are delegated to the GPU, and the remaining are delegated to the CPU. The model runs inference on the input images with no issues.

My problem: I have retrained the "CenterNet MobileNetV2 FPN Keypoints 512x512" to detect a new class's bounding box and keypoints. I modified voxl-tflite-server to use this model and updated the voxl-tflite-server.conf file with the model's name. When I try to load the model, the GPU delegate fails to apply as shown below

The NNAPI delegate fails as well with the same "error" as above. I looked into the meaning of tfLiteStatus = 3: kTfLiteApplicationError : Delegation failed to be applied due to the incompatibility with the TfLite runtime, e.g., the model graph is already immutable when applying the delegate. However, the interpreter could still be invoked.

The only thing I could muster from this error message is that the model graph is immutable, but the subgraphs can still be used; and for some reason this prevents the GPU delegate from being applied.

The model was retrained using the Object Detection API. After performing model analysis (using the Python API) it is apparent that the networks are slightly different; in the retrained model there are new layers in the list, but I'm not sure if/why that would cause the GPU delegate to fail.

Things I've tried:

• Post-training quantization (float16),
• Other models (CenterNet HourGlass104 Keypoints 512x512 from TF2 Detection Zoo),
• Specific input sizing prior to conversion from Tensorflow to TFLite (input can be [1,?,?,3], tried specifying as [1,256,256,3] or [1,512,512,3]),
• Representative dataset during conversion (images are a [1,height,width,3] uint8),
• Other versions of Tensorflow; tried 2.13, 2.10, 2.8 for both training and conversion.

I'm asking for advice on how to mitigate compatibility issues with the GPU on the VOXL 2. I suspect that the object detection API used for retraining is the culprit; does anyone know how to train in a way that the resulting model is compatible with the VOXL 2 GPU, or of a comprehensive guide for retraining a model without the object detection API?

Hardware Specs:

• Board: VOXL 2
• OS: Ubuntu 18.04
• SDK: 0.95beta (for dual IMX412 camera capability)

@Eric-Katzfey We are not using SDK 1.0.0 on account of the M0065 support (https://forum.modalai.com/topic/2429/voxl2-io-m0065-support-on-px4-1-14-in-sdk-1-0-0/2?_=1690933572791), we will in the future when the feature is available. We are using a custom drone.

Thanks!

We have been having trouble getting the M8N GPS module working on the VOXL 2. I tried the fixes suggested here https://forum.modalai.com/topic/2201/gps-not-ok-with-voxl2-px4, no dice. The LED on the M8N module lights up, but does not get a GPS-lock and there is no heading.

On the other hand, we were able to get a Here+ GPS module somewhat working (https://ardupilot.org/copter/docs/common-here-plus-gps.html). We were able to get a GPS-lock. However, the magnetometer readings were not coming though on the VOXL 2. We modified the connector so that the GPS (lat, lon, alt, etc) could connect to the VOXL 2 in the usual way, and used the additional two cables to connect the magnetometer to a Pixhawk which receives magnetometer readings (so we know the Here+ mag is not faulty).

Looking for suggestions about how to get the M8N module working and advice on how to get magnetometer readings to come through on the VOXL 2 using the Here+ module!

Thanks!

I had the exact same problem on my Ubuntu 18.04 machine with the VOXL 2.

To fix this, I had to restart the adb server with sudoers permissions. Maybe this will help:

adb kill-server
sudo adb start-server

@kp-ng Do you recall the steps you took to fix your issue?

Okay, thank you. Will follow up if/when I get something working.