Hello all. I’m pretty sure you technically only support APM and Mission Planner, but I’m hoping you can still help.
I’m running PX4 and QGroundControl, and on my most recent order of Cubes (Blue Cube, if that matters) I cannot upload the firmware from QGroundControl. I am able to do it from the command line, but when I try to upload through QGroundControl it kicks out of the bootloader before I have a chance to load the firmware.
I also noticed that the cubes take longer to boot than previous versions that didn’t have this issue.
When I run dmesg -w and plug in the device, it looks like my computer first sees it as a CubeBlack made by CubePilot, and then disconnects and reconnects viewing it as a PX4 FMU v2.x made by 3D Rogbotics.
[664522.631018] usb 1-1.4: new full-speed USB device number 49 using xhci_hcd
[664522.733000] usb 1-1.4: New USB device found, idVendor=2dae, idProduct=1001
[664522.733007] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[664522.733012] usb 1-1.4: Product: CubeBlack-BL
[664522.733016] usb 1-1.4: Manufacturer: CubePilot
[664522.733021] usb 1-1.4: SerialNumber: 3B0023001251383037393430
[664522.734339] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[664527.527407] usb 1-1.4: USB disconnect, device number 49
[664529.030896] usb 1-1.4: new full-speed USB device number 50 using xhci_hcd
[664529.133822] usb 1-1.4: New USB device found, idVendor=26ac, idProduct=0011
[664529.133831] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[664529.133836] usb 1-1.4: Product: PX4 FMU v2.x
[664529.133841] usb 1-1.4: Manufacturer: 3D Robotics
[664529.133846] usb 1-1.4: SerialNumber: 0
[664529.137767] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Is there a different bootloader I could use? Any help is appreciated.
Another thing that may be related is I don’t think the new Cubes respond to the USB reboot commands the same way. The command line tool that I use (the px_uploader.py python script in the PX4 repo) used to work more robustly:
On older cubes and other flight controllers, I can have the flight controller plugged into the computer prior to running the upload script and it would reboot the vehicle to the boot loader and upload the firmware just fine.
Now, with the newer cubes that have the upload issue in QGC, I must have the flight controller disconnected when I run the script, and then plug in the flight controller once the script is sitting there waiting for the boot loader. This is the only way it is successful now.
If this is on Windows the first thing I would do is make sure you have installed new PX4 drivers. A re-install of QGC Stable should give you that option.
I had tested firmware upload with the Blue Cube and ArduPilot bootloader. But let me try that again.
Actually now that I say that trying on Windows would be useful. I don’t have native Ubunutu only a VM and flashing on that generally doesn’t work. So I can’t really verify that directly.
OK, I will try Windows in a little bit and let you know what happens.
I do know the dmesg output is different now from what it used to be on the older cubes that work. On the older ones, only the second portion shows up. I never see the CubePilot part, only the 3DR part.
That’s because of the new bootloader. Old bootloader would have transitioned from “Product: PX4 FMU-BL v2.x” to “Product: PX4 FMU v2.x” if I remember correctly.
I’ve verified to OSX is working fine with this combination which is the closest I can get o Ubuntu flash.
Also can you try a daily build on Ubuntu. Daily should be equal to stable with respect to ArduPilot bootloader support. But maybe I missed carrying something across.
Also wait on trying new Windows Stable. I just realized that it’s not updating the drivers correctly.
It happens too fast for me to get a screenshot, but it says it’s normal “detected …” and then it rapidly says “upgrade cancelled” and then the parameters load and it goes to the Summary tab.
Ok. Can you create a QGC Github issue for this with details. Forum is a crappy place to try to figure this out from. Then from there I’ll point you at next steps.
I mentioned in that post, but I did just try the latest daily build. There was new behavior. It looked like it was working (it didn’t immediately kick out into a normal boot) but right when I hit the last “OK” it seg faulted and crashed the program.
I’m trying to load the latest firmware to a “new” (just back from the reseller “Fixed”) Pixhawk 2.1 Cube Black. Mission planner says an update is available, but when I try to get it there is a Hash not matched failure. This has happened repeatedly yesterday and today. Any ideas?
For anyone following along this thread, but not the GitHub issue. The latest QGC daily build works correctly. I may or may not be able to backport whatever fixes are in there to a new Stable.