New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flashing boards through "companion computer" #4698

Open
lucasdemarchi opened this Issue Mar 3, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@lucasdemarchi
Contributor

lucasdemarchi commented Mar 3, 2017

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

This comment has been minimized.

Contributor

lucasdemarchi commented Mar 3, 2017

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

@dagar

This comment has been minimized.

Member

dagar commented Mar 3, 2017

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

This comment has been minimized.

Contributor

dogmaphobic commented Mar 3, 2017

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

This comment has been minimized.

Member

dagar commented Mar 3, 2017

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

This comment has been minimized.

Contributor

dogmaphobic commented Mar 3, 2017

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

This comment has been minimized.

Member

dagar commented Mar 3, 2017

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

This comment has been minimized.

Contributor

lucasdemarchi commented Mar 3, 2017

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

This comment has been minimized.

Member

dagar commented Mar 3, 2017

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

This comment has been minimized.

Contributor

DonLakeFlyer commented Mar 5, 2017

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

@lucasdemarchi

This comment has been minimized.

Contributor

lucasdemarchi commented Mar 14, 2017

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

This comment has been minimized.

Contributor

jaxxzer commented Jul 24, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment