Update golden image to 3DR's final 2.4.2 FW and current ArduCopter

[Pedals2Paddles]

Issue

The solo's stock golden image is a deliberately unflyable and non-functional file system. The 3DR Solo app then prompts the user to do a preflight update. This downloads firmware from 3DR's servers, copied it down to the solo and controller, and executes the installation routines. The most current and final from 3DR is version 2.4.2 of the file system, Linux kernel, STM32, etc. It also includes ArduCopter-Solo v1.3.1.

This stock golden image is not compatible with the Pixhawk 2.1 or ArduCopter 3.5. Therefor you cannot do a factory reset after installing the Green Cube. The requirement for an over the internet update is also very limiting. If you have a problem in the field without an internet connection, you're grounded. And finally it relies on 3DRs firmware servers to provide that update, and they may not be there forever.

Requirements

We need to replace this with a modern and operational golden image.

• Must not require 3DR servers. We cannot rely on those always being around and we cannot build or modify the solo moving forward depending on them being there. This new golden image must cut that requirement out.
• Must be immediately flyable after pairing and calibrating. Must not require immediately going online to do updates. Sure, it may not be the latest and greatest as things advance over time. But it needs to be a stable and flyable file system. If someone has to factory reset in the field with no internet, they can still fly.
• Must be fully compatible with the Pixhawk 2.1 (Green Cube) and ArduCopter 3.5.x.

To Do:

1. Create a new golden image for the Solo that contains the current 3DR 2.4.2 firmware

• Include the modified python files needed for Green Cube / AC35 compatibility
• Include a solo build of ArduCopter 3.5.x

2. Create a new golden image for the controller (Artoo) that contains the current 3DR 2.4.2. At this time, nothing else is modified on the controller. But if anything does get modified in the meantime, it should be included.

3. Create deployment package(s) to install this update via the Solex app.

• Solex currently can only deploy to Solo. Need to add ability to deploy to controller
• Matt already has a rough process and package made for Solo. Needs fine tuning.

4. Document the deployment process for users to follow once alpha and beta testing is done. Add to ArduPilot solo wiki.

[Pedals2Paddles]

@kellyschrock for Solex to push updates to the controller too.

[kellyschrock]

@Pedals2Paddles How about a flag in an update package specifying which device it goes to. Something like this in package.properties:

device=(vehicle | controller)

[Pedals2Paddles]

That's pretty much what I was thinking too. It would be cool package them both together but might be more complicated than it's worth. Solo updates come much more frequently than the controller updates anyway.

[Pedals2Paddles]

Oh, also @kellyschrock, I think the FW updates menu/functions need to work even if there is no heartbeat or connection from the pixhawk. We can still install stuff without the pixhawk, so it shouldn't rely on that like the other app functions do.

[kellyschrock]

Oh, you mean like if we can still hit the IP and copy files to it even without being connected to the AP? Good point, and good idea.

…

On Mon, Jul 31, 2017 at 1:12 PM, Matt ***@***.***> wrote: Oh, also @kellyschrock <https://github.com/kellyschrock>, I think the FW updates menu/functions need to work even if there is no heartbeat or connection from the pixhawk. We can still install stuff without the pixhawk, so it shouldn't rely on that like the other app functions do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADmhzXbpxI9B9PZ0AM8ABON-GM6id21qks5sThj_gaJpZM4Oondq> .

[Pedals2Paddles]

Exactly. The controller and apps are historically misleading in that respect. They all say "waiting for solo" and/or "not connected". When in reality they are connected and talking. It's just not seeing the autopilot. It leads people to believe they've become unpaired or otherwise broken.

[kellyschrock]

GCS apps are only able to do 99% of what they do when they're connected to the autopilot, which is a discrete action that takes time to complete. Hence the "waiting for Solo" and "not connected" when no such connection exists. Not misleading at all. A GCS app and a Solo or controller on the same wifi network aren't connected and talking, until some connection (eg an SSH connection) between them is made, which is another discrete action that takes time. In this case, it's appropriate to make that non-autopilot connection to copy some files, so I see what you're saying.

…

On Tue, Aug 1, 2017 at 10:15 AM, Matt ***@***.***> wrote: Exactly. The controller and apps are historically misleading in that respect. They all say "waiting for solo" and/or "not connected". When in reality they are connected and talking. It's just not seeing the autopilot. It leads people to believe they've become unpaired or otherwise broken. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADmhzaSpvKo3sNngphxR-niBjYWqaoOKks5sT0EagaJpZM4Oondq> .

[Pedals2Paddles]

Done