Freedom Robotics Introducing: Single Line Install for Robotics

Hans Lee (CTO)
Hans Lee (CTO) | 4 min read
Jul 25, 2019 |

Product Announcement

One of the most frustrating parts of robotics is finding a new library that you are excited to use, only to spend hours on installation and setup before you can get started. A 3-line install script to test out a new SLAM library can easily grow into an 8-hour project that requires and OS rebuild to actually get the library to work.

Because of the complexity of OS versions, frameworks such as ROS, different sensors that don’t function stably together, and the customization of software environments to link them all together, the probability that a new library works out of the box is basically zero.

At Freedom, we have worked very hard to create a stable, understandable, and clean install of our on-device agent and libraries. For anyone who has developed robotic applications, you will know how difficult this is.

With Freedom, you can install onto 95% of robotics environments in 1 line of code and be up and running in 5 minutes.

 

Freedom Single Line Curl Command

Curl and a single line of code installs Freedom with both interactive and headless installs.

 

Freedom Installs In A Line

  • Curl and Python (2.7 or 3.6+) are the only initial dependencies
  • Every feature of Freedom can be enabled, disabled, or not installed
  • Template installs allow you to add credentials later
  • Installs on all OS’s

 

There Are No Clean Robotics Environments

Here is a list of some of the many installation challenges we’ve heard from our customers:

  • Differing user permissions that don’t allow access to key elements of the system
  • Legacy OS’s that lack dependency libraries and may be unpatched from 5+ years ago, but in deployment
  • The need to talk fully with hardware within the user’s security policy
  • Different versions of the user’s core frameworks (ROS, Protobuf, Python) that are not interdependent
  • Customer deploy processes that are always custom and include docker, GIT, Debians, Pip, Dropbox sync to the robot (yes, we have seen it… ouch), FTP, custom build scripts, and snaps
  • Some people who don’t trust any frameworks and wrote their own from the ground up
  • Broken or unique environment and python paths
  • Python virtual environments
  • Corrupted installs and OS’s
  • HIPAA and other compliance requirements for data, software, etc.
  • Faulty hardware, USB busses, or resource limits that make installs unstable
  • Limited compute (think ARM processors)
  • Bare metal installs that lack basic libraries
  • And more...

I could go on from here. The key is that there is not a clean environment in robotics. This presents special challenges that most other software systems do not encounter.

Below are some of our key learnings from building a clean install.

 

Minimize Install Dependencies

The first prototype of our agent was closely linked to ROS and was a Debian install. However, we very quickly realized that any install that has version dependencies for a specific framework cannot scale to be universal. We rebuilt the agent to only depend, at its core, on Python and a few standard libraries that all OS’s have.

This increased the installability of the agent massively and even allows interoperability on Linux, Mac, and Windows out of the box across x86, ARM, etc.

 

Degrade Gracefully Based On Your Environment

A core premise of good software design is that software should always work in a safe manner with the maximum set of features available.

What this means in practice is that some users work in extremely minimal environments, such as RTOS manipulators on a microprocessor, while others have an 8-core, 32GB processor. Therefore, Freedom allows a cascade of support based on the requirements of each application. For OSs like Linux, it is fully featured, but for the lowest level applications, it provides a simple python library or even direct API access for people to rebuild on bare metal in whichever language they want.

  1. Full OS support, link and agent
  2. Link and agent separate from OS
  3. Just Link as a python library
  4. REST interfaces when no library is feasible

 

Help Users Solve Common Issues

In the beginning, the goal of the installer was to be 100% automated across all environments. It turns out this was not actually an optimal approach. The reason for this is that there are some dependencies or system requirements that have cumbersome installs or may influence core functionality. In those cases, a user should understand this before the install is implemented.

An example of this is unpatched Ubuntu 14.03 systems that have the Heartbleed bug. We have seen systems in the wild that still have this. Because our agent enforces strong security, it will not install on a system like this, as it cannot safely talk with the APIs. Instead, the install provides the user with a list of 4 lines of code that will correctly patch their OS, but allows the user to decide if they want to do it.

The outcome of this is a clear install that users understand and that allows them to decide in a methodical way how they want to proceed.

 

Design For Both Headless Deploys And First Users

Many systems that have verbose installers do not work well at scale because they require so much user interaction that it isn’t possible to stably install with a command line over time. The flip side is that other installers are so automated that you have to add 12 command line parameters just to do a stable install (FFMPEG comes to mind…). The time to understand what -vrk means can be on the order of days, and there can be strange side-effects between parameters.

For a developer to understand and trust a framework, they need to get a feel for how it installs, how stable it is, and how it interacts with the rest of their system. By allowing this in the first few minutes, developers can make more informed decisions about how adding the new library will affect their system’s overall performance and capabilities.

 

Allow Everything To Be Turned Off

This may seem counterintuitive, but one of the most important features of a good install is the ability to only install the minimal footprint of features. An example of this is disabling remote SSH logins. This is actually one of Freedom’s most-used features for developers - but when companies go to production, a subset of them make the decision to disable SSH as they no longer need it. By adding one parameter, they can toggle it off. The same for every other core feature of the system.

Additionally, every single feature can be disabled remotely after install, or even fully re-installed remotely, so that you are not stuck with your initial install later on.

 

You Are Never Done. Support Your Install Well.

While our team has built a very robust install, there are always edge-cases that will not fully function. For this, you need to keep iterating, simplifying, and understanding users, domains they install into, and what is changing across development processes.

 

Final Thoughts

Robotics is hard, but you shouldn’t have to fight just to install things. The whole industry needs to invest more in building sane, safe, and easy installation and bring-ups for the core libraries and frameworks - not just “Hello World”, but actual, fully functional systems.

If you have any issues installing Freedom, please reach out, as we are always working to improve and increase the coverage of the installer.

Try it for free for 14 days