0

We are shipping a robot and hybrid laptop to a client, which will use it on its site. The laptop serves as a remote for the robot, or multiple robot. We want to be able to deploy software and system updates to the laptop and the robot. Both are running Ubuntu (at least for now). However, there are some challenges:

  • The robot is not connected to internet.
  • The laptop will be connected to internet regularly.
  • The laptop will be connected to a robot (by a Wi-Fi hotspot provided by the robot), but unlikely at the same time it is connected to the internet.

I would like the laptop to download the latest version of the software when it is connected to internet, install the software update and potentially system updates, and transfer the software and system updates to the robot when connected to it.

I can think about some solutions, which seems a bit hacky:

  • The laptop can use a package manager (APT or whatever) to download the latest version of the software, and Ansible rules to update itself.
  • The laptop can detect when it is connected to the robot and send it the package somehow.
  • Because the robot is not connected to internet, I would have to package the necessary DEB files (or whatever) for the system update.
  • I could also use docker to make it easier to manage the system updates, although docker containers are a bit heavy to download.

But what I would like to know is: are there some solutions out there for this case of figure?

Hugal31
  • 99
  • 3
  • In your question you use the terms "tablet" and "laptop". It is not clear whether both meant the same device. It should be possible to configure the laptop to act as an APT proxy for the robot(s). – pefu May 28 '20 at 11:33
  • It is a hybrid laptop, so it can be converted to a tablet, kind-of. I replaced the word tablet by laptop anyway. Regarding the APT proxy: it would work if the tablet would be connected to internet at the same time it is connected to the robot, which is not guaranteed. In fact, it is very unlikely, since the tablet connects to the robot Wi-Fi AP, and has only one network card. – Hugal31 May 28 '20 at 11:36
  • This is more for software engineering https://softwareengineering.stackexchange.com/help/on-topic than ServerFault IMHO - but in general people seem to use the user interface and manual operator intervention with the client on the laptop polling both the vendor for updates and generating a pop-up “*new firmware version available, download now?*” whenever a new release becomes available as well as polling the firmware version on the peripheral (your robot) whenever it is connected and offering a pop up “*new version of the firmware available. Upgrade peripheral from version X to Y now?”* – Bob May 29 '20 at 07:54
  • Yes, on the user point of view, a popup asking if he wants to download the upgrade is the goal. What I am asking is "what are the tools that can I myself transferring and installing the updates in a secure and robust fashion, and is this part of a standard that can help me" – Hugal31 May 29 '20 at 09:18

1 Answers1

0

So, I still don't have a perfect solution, but here what we tried:

  • Guix has the ability to download and copy packages easily for as I wanted. If I understand correctly, one can design a system as a scheme file, download/build all the required packages and apply it to a distant system. That would have been the solution if Guix would package ROS, one of our dependency that is hard to package by ourselves. I might take the time to do a script to package it with Guix, one day.
  • Snap + Ubuntu Core are designed to work on embedded system and IoT. We didn't dig a lot into it, because we missed time to investigate how to have the tablet system based onto Ubuntu Core, but that seems like a solution.
  • Docker: I know docker a lot more, and it is handy, but we cannot update the kernel with it. Do we really need the ability to upgrade the kernel? Good question.
  • APT + apt-offline: this one was easy to set up, but apt-offline has a flaw: you have to make two round-trips to upgrade the offline system: one for the apt update, one for the apt upgrade. I managed to reduce it to one round-trip by making a local mirror of the APT state of the robot on the tablet to emulate an apt update, and fetch the upgrade files just after.
Hugal31
  • 99
  • 3