Flashing boards through "companion computer"

[lucasdemarchi]

On the Intel Aero RTF we have a WiFi and usb-ethernet connection to the drone. There's a microcontroller inside that runs the flight stack. The current approach to update the flight stack is to run this script:

https://github.com/PX4/Firmware/blob/master/Tools/aero_upload.sh

Details on how it works:

• It copies (px_uploader.py)[https://github.com/PX4/Firmware/blob/master/Tools/px_uploader.py], and the .px4 firmware to Aero via scp
• ssh into Aero; stops the bridge between flight controller and aero, run the update script with the correct parameters and then start the bridge again (if it was in fact running).

It would be nice to have this working with QGC. I'm not sure how it would work. My idea was to add an entry in the .px4 containing the necessary scripts embedded there. However I imagine this would not be compatible with Windows / Android / iOS (I actually don't know, just guessing).

Another option would be to have this script inside QGC and implement it for each target. However this would be a pain to keep up to date.

Thoughts?

[lucasdemarchi]

btw it uses the link local address by default intel-aero.local

[dagar]

I'm wondering if there's a more general solution. A new mavlink message for updating firmware (transfer, verify, flash), then in this case mavlink-routerd would be responsible for implementing the message appropriately.

Could also work for updating via esp8266 on other boards?

Then all QGC would need to know is if it's flashing hardware directly or over mavlink.

[dogmaphobic]

A new mavlink message for updating firmware (transfer, verify, flash), then in this case mavlink-routerd would be responsible for implementing the message appropriately.

Preferably with an option to have the transfer portion on a different protocol. The link is already TCP/IP, it makes little sense to break the transfer down further into small chunks.

[dagar]

Sure, should we spec it out?

I was thinking about simplicity and having the same thing work over any Mavlink connection (TCP, UDP, serial, USB, etc).

How common are the esp8266s with enough memory to hold a firmware image (1-2MB)?

[dogmaphobic]

How common are the esp8266s with enough memory to hold a firmware image (1-2MB)?

Memory not so much but flash size, which you can use like a file system is usually 4MB. You wouldn't necessarily keep the entire image in memory. Just buffer it while flashing through the serial port.

[dagar]

Right, I wasn't sure how risky that would be. I suppose it depends if the flashing device (companion computer, esp8266, etc) is able to get the board back in a state for flashing.

[lucasdemarchi]

Problem with all this is that it makes some assumptions:

1) There's software on the other end that is capable of flashing. In my case there's software there that can flash it, but it's often out of date and doesn't have something we need. For example, we needed to a) update px_uploader to allow different baudrate between flight stack and bootloader; b) allow testing multiple baudrates since we needed to change the baudrate;

2) It doesn't solve the case of allowing to flash for the first time, since you will need the software on the other end installed

I'm not against having it, but it doesn't solve the problem I'm trying to solve now. It could be used in future though.

[dagar]

I understand, I just really don't like the idea of QGC 1) using ssh for updates and 2) having such a specific update mechanism for one board. If possible I was hoping the effort could be directed towards something better and generalized.

[DonLakeFlyer]

Yeah, this seems really specific to be part of QGC.

[lucasdemarchi]

Yeah, this seems really specific to be part of QGC.

The idea here would be to make QGC compatible with vehicles when you don't control what goes in the other end. The solution would be to execute the script that does everything, so it would not really be so specific.

I understand, I just really don't like the idea of QGC 1) using ssh for updates and 2) having such a specific update mechanism for one board. If possible

that's only possible if you control both ends.

I was hoping the effort could be directed towards something better and generalized.

I'll take a look on it soon if no ones beats me to it.

[jaxxzer]

We want a similar feature for our ROVs.

In order to address this in a generalized manner on the QGC side, we could have an 'upload' option and a field to enter the url to send the firmware to. On the companion side, those who want to implement this feature just need to make a simple webserver that receives the firmware via HTTP PUT or POST and then runs a flashing script that is more application/implementation specific.

For example, our flashing script stops mavproxy first, flashes the board, then starts mavproxy again.

[jaxxzer]

What we ended up doing was a web interface on the companion computer to update the firmware. http://www.ardusub.com/operators-manual/companion-web.html#system

This works well enough sense and makes sense as a responsibility of the companion computer, rather than QGC needing to implement some remote flash mechanism.

Doesn't QGC need some information about the usb id or from the bootloader to determine which firmware to download anyway?