Posts made by swickliff

@Vinny It is possible that there are a few M0054-2's in the mix. Majority of the Voxl2's giving us issues at the moment are M0054-1's.

@Moderator

We have a daisy chain of M0076 to M0036 to M0025
and another chain with a M0084-1 with a M0149-1 and M0107-2 on it

Thank you for mentioning the limited cycles of insertions/removals. I will keep that in mind going forward.

@swickliff I am using Ubuntu 20.04 on both the VM and Linux PC

I'm trying to unbrick a VOXL 2 that has gone into EDL mode (Reading as QUAL_BULK). I've got the system into QDL mode and it is being read as (QDL MODE). No issues provisioning or flashing CDT.

Once I get to the Flash Flat Build stage, the system immediately sends the following failure {"message": "Flash flat build failed\n"}. I've tried on a Virtual Machine and on a dedicated Linux PC. Any thoughts as to why it may be failing?

Flash Flat Build: 2024-06-17-1.7.4-M0054-1

VOXL2: QRB 5165M

We have experience this issue with several Voxl2s configured the same way. I with 3 cameras on J7L, J7U, and J8L.

We first notice the issue when the camera streams are not coming up on our GCS.
We go into the voxl2 to investigate. Sometimes you cannot adb shell or detect the voxl2 through USB. Sometimes it allows you to adb shell but voxl-camera-server does not detect all the cameras.

Power cycling immediately typically results in the cameras still not being detected and/or the voxl2 not being detected as a USB device.
Power cycling and waiting ~5min or unplugging and re-plugging in all the cameras typically solves the issue.

Any idea why this might be the case? Is there a capacitor on the voxl2 that may take several minutes to drain fully?

The cameras and associated cables don't have any visible damage and will work on other voxl2 boards that don't have this issue.
We have had this happen to probably 5 or 6 different sets of Voxl2 and cameras.

We are at a loss for what could be causing this issue.
Any advice on how to investigate this further?

@Alex-Kushleyev , I believe we are not receiving any frames.

I disabled the hires and the same buffer error occurs.

Here is the readout from the dmesg -w command when I run voxl-camera-server in another terminal. I don't see any SOF or EOF messages:

@Alex-Kushleyev

voxl-camera-server -l detected both cameras

voxl-camera-server threw a few warnings and Error: Received "Buffer" error from camera: tracking

The whole read out is below:

We had a M0014 Tracking Camera and a M0107 Hires, configured correctly for camera group 1 on MIPI J7. We had done some test flights of this aircraft, Hires camera looked great, tracking camera was working perfect. The aircraft was not involved in any crashes.

While performing a stationary range test, the cameras stopped working. Running voxl-inspect-cam -a results in this error:

Voxl-inspect-services show that the voxl-camera-server is enabled but not running. Trying to restart the camera-server does nothing.

I tried all new cameras and cables, and it produced the same error.

Is something corrupted in the camera driver? Would reflashing the SDK potentially solve it?

Reconfiguring the cameras in group 2 shows the cameras working fine again. But as far as I know VIO tracking can only be set up in camera group 1. Is it possible to set up the VIO pipeline through a different camera group?

Final note, we conformal coated the Voxl2 prior to flight testing, but the MIPI ports are free from conformal coating or any other visible damage.

@Alex-Kushleyev It looks like I am having the same issue as Jacob. We've added a brand new Voxl2 to our drone, this one is running on SDK 1.1.3 and we cannot get it to connect to PX4. Our prior build used Voxl2s with SDK 1.1.2 and worked fine for us, so we tried downgrading the SDK but that did not work either.

We re-updated the SDK to 1.1.3 and I stopped and disabled voxl-px4 service and rebooted the Voxl2 and started px4 manually. Want me to share a text file with the output?

@Alex-Kushleyev Thanks for all the info! I'll keep those things in mind when soldering to the pads.

The technical docs for the 4-in-1 ESCs mention an Aux Power Output of "1x5.0V (adjustable) 500mA" for the M0134 ESC.

What is the pin out for this? I assume it is the AUX IO pads from the data sheet on the bottom side of the PCB. I am unable to locate the what the pin out for these to groups of 4 pads in the technical doc.

@tom That worked! thanks for the help

@tom yes, I used ./install.sh from the voxl2_SDK_1.1.2 dir

@tom

The SDK install failed to locate the voxl-suite-offline-packages. I used the 1.1.2 release because that is what we currently have on our other Voxl2 boards at the moment. If you think the 1.1.3 release will produce different results I can try that.

Here's a screenshot of the errors:

This board was originally bricked by accident and went through the unbricking guide but had some warnings or errors pop up when the Image was re-flashed. I believe the Image reflash was attempted again but failed.

When I try to ADB shell, it accesses root@m0054:/# instead of voxl2:/$
This root interface does not have any of the voxl bash commands. For instance I couldn't use voxl-inspect-services.

I've tried killing and restarting the ADB server, but that did nothing

lsusb is reading the device as Qualcomm, Inc. KONA-QRD _SN:3C6BFAA2

A previous forum post had the same issue, they said it was a permissions issue.
I am not sure what permissions I should try to change. How can I change what ADB shell connects to?

@Alex-Kushleyev
It's sad to hear it's probably a broken connection, but thanks for helping me figure that out.

I have a second ESC with LED issues. Only 1 LED blinks, but no ESCs are detected when trying to upload params. Today I tried re-uploading the param at a baud rate of 57600 to see if the prams previously failed to upload correctly, but that didn't work.

I know this ESC has never flown bc the motors didn't spin when we did a test spin with "voxl-esc spin". There is no visible damage to any channels on the board.

Do you think this could also be a MCU connection issue? Or is there something else I can try to detect the ESCs?

@Alex-Kushleyev I have just learned that this drone was involved in a minor crash and then it started whistling after the crash. It was caught underneath a chair and landed on it's landing gear on the ground, about a 1ft fall. We have several other drones with these ESCs that have been through much worse crashes that are still flying fine.

The LED never turns on, even right after power on (the other 3 flash quickly for 1 second).

There is a small chip on a mosfet on the ESC channel. That is the only visible damage I can see on either side of the board.

We have an ESC that has been giving us a motor whistling issue only on one motor. After confirming props were tightened correctly, then swapping the motor and verifying the ESC parameters, we decided to replace the ESC and that solved our whistling motor issue.

The only indication that something is wrong with the board is that the status LED associated with the ESC driving "whistling" motor does not light up.

The ESCs are all detected and the parameters upload correctly.

Is there anything else we can try to reset the ESC?

@Alex-Kushleyev This was very helpful thank you. I was able to reset a "sad beep" ESC with no problems

I ordered several Stand Alone Modem boards to set up several radio pairs. Most of them work properly and had no issues with setup.

One Stand Alone Modem seems to be stuck in a "boot" state. The board is detected by the PC but the modem is unable to be reached.

I tried swapping to a new pMDDL microhard and the same issue occurred.

The CPU LED on the board seems to flash irregularly.

Is there a way to "re-flash" the Stand Alone Modem Board or is there something else I could try?