@teddy-zaremba We were able to pull your suggested version and the deserialization errors are gone. Thank you for your help.

@Zachary-Lowell-0 If you won't be able to help here, is there someone that can? Thanks

Hi @Zachary-Lowell-0 I'm working with @GlennTee on his capstone project as an advisor. We are hoping to use Starlings as infrastructure for algorithm research and development in our labs. In order to sell the idea to our sponsors we'll need basic (working) examples for researchers to get started with that don't require weeks of work to sort through just to establish a baseline. I've seen other posts with similar deserialization errors so I'm hoping that you can help to resolve this easily. We very much appreciate your help and eagerly await direction.
Best Regards,
Bill

@teddy-zaremba Your help is very much appreciated.

Ok, so some of the confusion was related to editing the Python example, but it's actually running the cpp code. With that corrected, it shows all of the expected topics in the "ros2 topic list" and the code sends the arm command to the correct topic according to "ros2 topic echo /uav_4/fmu/in/vehicle_command", however, the Starling doesn't arm. We're trusting the example code as to the data structure that is actually populated and sent to that topic. Is there a reference as to what that should be?

@Kessie Great. Thank you for your help.

@Kessie The good news is that removing the prefix allows the px4 to see the messages and arm. Thank you! The bad news is that we weren't sure this would work so the drone wasn't in our flying lab and we had to physically grab it and disconnect the battery.

We tried powering on the RC controller to push the kill switch, but even though it connected to the receiver, the drone didn't respond to any of the RC controls including the mode and motor disable switches.

How do we operate in offboard mode while preserving the ability to take over manually? Would it have worked if we powered on the drone in manual or position hold and then switched to offboard? Do we launch our code before or after the mode change?

@claw said in unbrick proceedure not finding flat build:

@Nathan-Raras

I bought a high-speed cable and the flat build passed. Thank you for your help. I need to install both the SDK now and migrate to ROS2. Are there plans to update the SDK with ROS2 as the default so that the extra step isn't required?

@Nathan-Raras That's fantastic! Thank you. I will try it tomorrow when I'm back in the lab and let you know how it goes.

@Nathan-Raras BTW, the terminal window displays a "500 internal server error"

Thank you for that. You're correct that it unarchived with an extra level of folders. I corrected that and retried the process. This time it ran "flash flat build" for several minutes before returning the failure message. I tried starting from the first step, different cables etc but it failed each time - it runs for 10 minutes or so and then prints the fail message. Is there a log file that gives more information to troubleshoot why it fails?