Good day

I have a Sentinal drone and working on operating it with RS via MAVROS, but for starters I am working on getting the Gazebo simulator working first on a separate machine running Ubuntu 18.04 LTS and ROS1 Noetic.

Working through the MAVROS tutorial, I noticed 2 things:

1. The MAVROS Offboard Control C++ tutorial (https://docs.px4.io/main/en/ros/mavros_offboard_cpp.html) seems incomplete. Unlike the Python tutorial on the next page, the C++ tutorial does not explain the process of adding the launch file and adapting the CMakeLists.txt file to the project to get the simulator to run as depicted.

2. Something seems amiss when I try working through the tutorial on Sending a Custom Message from MAVROS to PX4 (https://docs.px4.io/main/en/ros/mavros_custom_messages.html). I add the custom lines to both common.xml files in the PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0 and workspace/src/mavlink/message_definitions/v1.0, but I notice that when I build the project, the custom lines in the PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/common.xml are removed, and an error is generated with the mavlink_receiver.cpp (in PX4-Autopilot/src/modules/mavlink) where MAVLINK_MSG_ID_KEY_COMMAND is not declared in this scope.
   Could I be running the tutorial incorrectly?

We'll have to take a look on our side then. Could we receive the schematics of the board and perhaps the source code for the qualcomm so we can test?

We flew the drone and had a semi-hard landing (I say semi-hard because we've had harder landings but the drone got back to flying easily). When we went in to check the drone, nothing was physically damaged. We just noticed that the WiFi was off.

We thought cycling the power would work, as it usually did, but this was not the case now. When trying to connect via ADB and noticed it didn't work, that's when we knew something was wrong.

We tried fastbooting the board, and that also was not working. So we realized that this problem is deeper than just a bricked board.

The add-on board we have connected is the WiFi board with its Fastboot button. The only SW2 I have spotted is the one depicted on https://docs.modalai.com/voxl2-qdl/.

Before the system image got corrupted, everything worked fine and no buttons or switches were engaged. I am finding it weird that it seems that the board went into EDL mode upon corruption with no changes made to the hardware.

Our setup is similar to that on https://docs.modalai.com/voxl2-d0006/. All of this is on a Sentinel drone.

@TPSetati I am just realizing that the VOXL2 board was already in QDL mode before I switched SW2 to the ON position. Even if I switch it back to off, it remains in QDL mode. Is there another switch that could be causing this?

I ran thesudo apt remove --purge modemmanager command to uninstall it, but there was nothing to uninstall according to the output

When the board is disconnected, the qdl command can detect that nothing is connected

Good day

Thank you for your response and for showing me another solution to try. I am trying the QDL route, but have hit a speed bump.

SW2 has been switched to on and the host PC recognizes that the VOXL2 is in QDL mode

I downloaded the system image on the QDL page and unzipped it. When running the sudo qdl command, nothing happens.

What could the issue be here?

Apologies, I realized the error on my part. Here is the correct output

Re: VOXL2 bricked

Good day

I am facing the bricked VOXL2 issue and forcing fastboot is not working.
After following the instruction to force a fastboot, I connect the USB cable to the host PC. Running dmesg -wH shows:

lsusb also confirms the Qualcomm device is connected

Unfortunately fastboot devices still gives no output