The firmware downloads from the internet OK, and I believe there’s a message that flashes by about seeing a heartbeat. But the process fails at this screen:
I finally got it to upload. I was wondering if there was something weird about the USB connection. This is the copter I’m using with the new CubePilot carrier board. It brings the Cube’s USB connection out to a clear space on the board. I thought maybe the connectivity might be problematic.
I (with some difficulty) connected a USB cable directly to the Cube. The firmware failed to install again - but it succeeded on a second try.
I have a faint recollection about procedure you mention - I’ve never done it that way.
Is the process documented somewhere?
What are the advantages?
Nine times our of ten, the firmware uploads without a hitch. Not sure why it balked this time.
Most often this is because the PX4 compatible bootloader that comes pre-installed is not good at recognising the reboot - I always would recommend to upgrade the bootloader to AP
I hadn’t heard of this issue before. And I hadn’t realized there were these two boot loaders. Thank you for mentioning it.
I guess this means that if I really wanted to, I could use QGC and load PX4 on my Cubes. That might be a good rainy day project.
In the mean time, I’d like to know more about the ArduPilot boot loader. I like the idea of using the more appropriate boot loader, but I’d like to see some documentation about it, and about updating it. I’d be concerned about bricking a Cube if I did it wrong,
Also - I recall one issue related to the boot loader. When a Cube boots, the GPIO relays momentarily go high. If you have one triggering a camera shutter, it causes it to trigger at boot. When I first came across this a couple of years ago, I think it was @rmackay9 who mentioned that since this issue was caused by the boot loader, it couldn’t be fixed in the ArduPilot code.
I’m wondering now that if I switch to the ArduPilot boot loader, will this problem might go away? Or at least it might be able to be fixed by the ArduPilot Devs?
Re the GPIO pins momentarily going high, I imagine that a bootloader change could remove this behaviour but I’m not confident enough personally to change the bootloader.
The $64 question is - if there’s an ArduPilot specific bootloader I can use, might this other bootloader not have the GPIO problem?
I guess I could be the guinea pig - but I hate to tinker with the bootloader without good documentation - to protect against messing it up and bricking the Cube.
The issue is mostly if the camera is set to video record. The camera will start recording video when the flight controller boots. In picture mode, it just snaps a photo.
My Foxtech Map-02 is a bit tricky on startup. This camera has the guts from a Sony a5100 in a “naked” lightweight shell. It has odd start up requirements - that aren’t a problem as long as you do it right. I’m wondering now if it might be a bit simpler without the GPIO pins going high.
Not sure where you’re getting the guinea pig mentality from. If you update the bootloader using the procedure in the wiki, you are performing a normal operation that SHOULD likely be done after an initial firmware flash or significant release (i.e., 4.5 to 4.6). It carries less risk now than it used to with older boards, and the warnings on the wiki might be a bit heavy handed.
I’m so confident in my assertion here that I will send you one of my personal Orange+ autopilots if you follow Randy’s video linked below and end up with a bricked board.