Robot Development Platforms Part 1: Frameworks and Libraries

New industrial, personal, enterprise, and toy robots are being announced pretty much daily. If you’re a developer looking to start coding for our shiny friends, it’s a lot to take in. You may find yourself plowing through links to entirely unfamiliar software stacks and wondering where to start.

There are no simple answers, but a quick overview may help. We can break down the complexity of developing for robots as a platform in a few ways:

• Frameworks/Libraries/Services
• Architectures/Operating Systems
• APIs/SDKs
• Devices/Hardware

For this first post, we’ll start with frameworks.

Why Robot Frameworks?

If you write code, you’ve probably used a framework. From AngularJS to OpenCV, software frameworks are reusable, (typically) extensible environments that solve specific programming problems so you don’t have to.

Admittedly, starting with frameworks is a weird way to look at robot development platforms. After all, you don’t need to talk about AngularJS in order to discuss programming for the web.

But in the case of robots, we need to begin with frameworks because… Robot Operating System. “ROS” is the heavyweight contender of robotic programming, and its very name conflates operating systems with frameworks, so we have to get that sorted first thing.

Robot Operating System

Despite “OS” being part of its name, ROS itself is not an operating system. The first step to getting started with ROS, in fact, is to install the OS it runs on: Ubuntu Linux.

So what is ROS? ROS is a framework providing an abstraction layer that sits on top of the specifics of any particular robot’s hardware. Along with the specific capabilities you can get from ROS’ many packages, the benefits of the framework include:

• Hardware abstraction
• Low-level device control
• Support for process-based message passing
• Package management

There are downsides with ROS, however. One is that it’s complicated. The robotics world is full of passionate ROS advocates, but their message overall is that the ROS learning curve is steep. Another issue is that a significant number of ROS packages are created and maintained by non-professionals for very specific use cases, so their cross-robot applicability can be limited. A third issue is that ROS was not designed for good performance in real-time embedded systems.

Nevertheless, for custom, specialty, or academic robots, using ROS has traditionally been worth it. Faced with coordinating the complexities of sensors, motors, and controllers in situations where performance isn’t an issue, ROS could be a big help. Going forward, in today’s world of commercial robot platforms with modern high-level SDKs, the requirement for most robot developers to learn ROS is less clear.

That said, ROS2 is in active development. System performance improvements are a major focus area, although the amount of progress the ROS2 architecture has made in this area is under review. Still, ROS2 is a big bet with industry heavyweights:

• Microsoft recently announced that it is joining the ROS Industrial Consortium.
• More of interest to non-industrial developers, Amazon just publicly released their ROS-based cloud libraries for robot development: AWS RoboMaker.

ROS continues to have a large influence in the field, so we’ll definitely explore it further in upcoming posts.

Language-Specific Frameworks

If you’re looking for something simpler than ROS, one way to get started is with a framework designed for a specific programming language:

• Johnny-Five is a JavaScript robotics and IoT framework. A favorite of makers (with its strong Arduino support) and custom robot builders, there’s a strong community of “Nodebot” developers using Johnny-Five, as well as support from Johnny-Five kits and books. Together these have eased the learning curve for bridging Arduino-based robots and JavaScript. Additional plug-ins are available that extend Johnny-Five’s reach to non-Arduino-based hardware, as well.
• Another JavaScript framework, Cylon.js supports 43 different physical computing platforms, ranging from IoT devices to drones to toy robots. For JavaScript developers, this breadth of platform support right “out of the box” is very attractive.
• The increasingly popular Gobot is based on the Go programming language. Gobot provides out-of-box support for 35 different physical computing platforms that cover a similar range to that of Cylon.js.

Use-Specific Frameworks

Non-ROS-based robot frameworks span a wide range of audiences — from academic to hobbyist to pro—and use cases:

• Nowhere near as widely used as ROS, but with an even longer history and quite active developer community, YARP specifically is not interested in providing package management. Instead YARP’s value is as a flexible control system for interconnecting sensors, processors, and actuators.
• Rock — “Robot Construction Kit” — provides open source drivers and modules for use in robotic systems. It’s in active development and is based on another very long-lived framework: Orocos (Open Robot Control Software).
• A middleware system for mobile robotics platforms — including cars and underwater autonomous vehicles — MOOS is very actively maintained by the Oxford Mobile Robotics Group and is being used by quite a variety of robotic vehicles.

• Another framework that seeks to optimize for mobility, Fawkes is self-described as supporting “fast information exchange and efficient combination and coordination of different components to suit the needs of mobile robots”. Currently its primary users are hobbyists and robot competition teams.
• Older frameworks that you can still grab online include Player and LCM. Player is an abstraction layer for robot sensor systems. For a long time the Player network server environment was one of the most commonly used frameworks for robotics research and post-secondary education. The LCM library’s focus is supporting low-latency message passing in real-time systems (including robots), and it continues to be updated.
• Along different lines, they may not be perfect models for the messiness of the real world, but simulators remain a key tool for expediting robotic software development. However, writing a good simulator from the ground up requires significant physics and graphics modeling knowledge. This is the value of robot simulation frameworks such as Gazebo and Simbad. They allow you to model your robot and its behaviors, without all the (metaphorical) heavy lifting.

• Finally, I can’t not mention the confusingly named Robot Framework, which is not a framework for robots but is instead a tool for automated software acceptance testing. :)

What’s Next?

Moving one step lower from frameworks, in our next post, we’ll look at the various architectures and operating systems being used by robots today.

In the meantime, if you know about a currently-available robot development framework that got missed, please speak up in the comments section!