Open-source hardware

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Open-source_hardware 

 

The "open source hardware" logo proposed by OSHWA, one of the main defining organizations

 

The RepRap Mendel general-purpose 3D printer with the ability to make copies of most of its own structural parts

Open-source hardware (OSH) consists of physical artifacts of technology designed and offered by the open-design movement. Both free and open-source software (FOSS) and open-source hardware are created by this open-source culture movement and apply a like concept to a variety of components. It is sometimes, thus, referred to as FOSH (free and open-source hardware). The term usually means that information about the hardware is easily discerned so that others can make it – coupling it closely to the maker movement. Hardware design (i.e. mechanical drawings, schematics, bills of material, PCB layout data, HDL source code and integrated circuit layout data), in addition to the software that drives the hardware, are all released under free/libre terms. The original sharer gains feedback and potentially improvements on the design from the FOSH community. There is now significant evidence that such sharing can drive a high return on investment for the scientific community.

It is not enough to merely use an open-source license; an open source product or project will follow open source principles, such as modular design and community collaboration.

Since the rise of reconfigurable programmable logic devices, sharing of logic designs has been a form of open-source hardware. Instead of the schematics, hardware description language (HDL) code is shared. HDL descriptions are commonly used to set up system-on-a-chip systems either in field-programmable gate arrays (FPGA) or directly in application-specific integrated circuit (ASIC) designs. HDL modules, when distributed, are called semiconductor intellectual property cores, also known as IP cores.

Open-source hardware also helps alleviate the issue of proprietary device drivers for the free and open-source software community, however, it is not a pre-requisite for it, and should not be confused with the concept of open documentation for proprietary hardware, which is already sufficient for writing FLOSS device drivers and complete operating systems. The difference between the two concepts is that OSH includes both the instructions on how to replicate the hardware itself as well as the information on communication protocols that the software (usually in the form of device drivers) must use in order to communicate with the hardware (often called register documentation, or open documentation for hardware), whereas open-source-friendly proprietary hardware would only include the latter without including the former.

History

openhardware.org logo (2013)

 

OSHWA logo

The first hardware-focused "open source" activities were started around 1997 by Bruce Perens, creator of the Open Source Definition, co-founder of the Open Source Initiative, and a ham radio operator. He launched the Open Hardware Certification Program, which had the goal of allowing hardware manufacturers to self-certify their products as open.

Shortly after the launch of the Open Hardware Certification Program, David Freeman announced the Open Hardware Specification Project (OHSpec), another attempt at licensing hardware components whose interfaces are available publicly and of creating an entirely new computing platform as an alternative to proprietary computing systems. In early 1999, Sepehr Kiani, Ryan Vallance and Samir Nayfeh joined efforts to apply the open-source philosophy to machine design applications. Together they established the Open Design Foundation (ODF)  as a non-profit corporation and set out to develop an Open Design Definition. However, most of these activities faded out after a few years.

A "Free Hardware" organization, known as FreeIO, was started in the late 1990s by Diehl Martin, who also launched a FreeIO website in early 2000. In the early to mid 2000s, FreeIO was a focus of free/open hardware designs released under the GNU General Public License. The FreeIO project advocated the concept of Free Hardware and proposed four freedoms that such hardware provided to users, based on the similar freedoms provided by free software licenses. The designs gained some notoriety due to Martin's naming scheme in which each free hardware project was given the name of a breakfast food such as Donut, Flapjack, Toast, etc. Martin's projects attracted a variety of hardware and software developers as well as other volunteers. Development of new open hardware designs at FreeIO ended in 2007 when Martin died of pancreatic cancer but the existing designs remain available from the organization's website.

By the mid 2000s open-source hardware again became a hub of activity due to the emergence of several major open-source hardware projects and companies, such as OpenCores, RepRap (3D printing), Arduino, Adafruit and SparkFun. In 2007, Perens reactivated the openhardware.org website.

Following the Open Graphics Project, an effort to design, implement, and manufacture a free and open 3D graphics chip set and reference graphics card, Timothy Miller suggested the creation of an organization to safeguard the interests of the Open Graphics Project community. Thus, Patrick McNamara founded the Open Hardware Foundation (OHF) in 2007.

The Tucson Amateur Packet Radio Corporation (TAPR), founded in 1982 as a non-profit organization of amateur radio operators with the goals of supporting R&D efforts in the area of amateur digital communications, created in 2007 the first open hardware license, the TAPR Open Hardware License. The OSI president Eric S. Raymond expressed some concerns about certain aspects of the OHL and decided to not review the license.

Around 2010 in context of the Freedom Defined project, the Open Hardware Definition was created as collaborative work of many and is accepted as of 2016 by dozens of organizations and companies.

In July 2011, CERN (European Organization for Nuclear Research) released an open-source hardware license, CERN OHL. Javier Serrano, an engineer at CERN's Beams Department and the founder of the Open Hardware Repository, explained: "By sharing designs openly, CERN expects to improve the quality of designs through peer review and to guarantee their users – including commercial companies – the freedom to study, modify and manufacture them, leading to better hardware and less duplication of efforts". While initially drafted to address CERN-specific concerns, such as tracing the impact of the organization's research, in its current form it can be used by anyone developing open-source hardware.

Following the 2011 Open Hardware Summit, and after heated debates on licenses and what constitutes open-source hardware, Bruce Perens abandoned the OSHW Definition and the concerted efforts of those involved with it. Openhardware.org, led by Bruce Perens, promotes and identifies practices that meet all the combined requirements of the Open Source Hardware Definition, the Open Source Definition, and the Four Freedoms of the Free Software Foundation Since 2014 openhardware.org is not online and seems to have ceased activity.

The Open Source Hardware Association (OSHWA) at oshwa.org acts as hub of open-source hardware activity of all genres, while cooperating with other entities such as TAPR, CERN, and OSI. The OSHWA was established as an organization in June 2012 in Delaware and filed for tax exemption status in July 2013. After some debates about trademark interferences with the OSI, in 2012 the OSHWA and the OSI signed a co-existence agreement.

FSF's Replicant project suggested in 2016 an alternative "free hardware" definition, derived from the FSF's four freedoms.

Forms of open-source hardware

The term hardware in open-source hardware has been historically used in opposition to the term software of open-source software. That is, to refer to the electronic hardware on which the software runs (see previous section). However, as more and more non-electronic hardware products are made open source (for example WikiHouse, OpenBeam or Hovalin), this term tends to be used back in its broader sense of "physical product". The field of open-source hardware has been shown to go beyond electronic hardware and to cover a larger range of product categories such as machine tools, vehicles and medical equipment. In that sense, hardware refers to any form of tangible product, be it electronic hardware, mechanical hardware, textile or even construction hardware. The Open Source Hardware (OSHW) Definition 1.0 defines hardware as "tangible artifacts — machines, devices, or other physical things".

Computers

Due to a mixture of privacy, security, and environmental concerns, a number of projects have started that aim to deliver a variety of open-source computing devices. Examples include the EOMA68 (SBC in a PCMCIA form-factor, intended to be plugged into a laptop or desktop chassis), Novena (bare motherboard with optional laptop chassis), and GnuBee (series of Network Attached Storage devices).

Several retrocomputing hobby groups have created numerous recreations or adaptations of the early home computers of the 1970s and 80s, some of which include improved functionality and more modern components (such as surface-mount ICs and SD card readers). Some hobbyists have also developed add-on cards (such as drive controllers, memory expansion, and sound cards) to improve the functionality of older computers. Miniaturised recreations of vintage computers have also been created.

Electronics

Electronics is one of the most popular types of open-source hardware. There are many companies that provide large varieties of open-source electronics such as Sparkfun, Adafruit and Seeed. In addition, there are NPOs and companies that provide a specific open-source electronic component such as the Arduino electronics prototyping platform. There are many examples of specialty open-source electronics such as low-cost voltage and current GMAW open-source 3-D printer monitor and a robotics-assisted mass spectrometry assay platform. Open-source electronics finds various uses, including automation of chemical procedures.

Mecha(tro)nics

A large range of open-source mechatronic products have been developed, including mechanical components, machine tools, vehicles, musical instruments, and medical equipment.

Examples of open-source machine tools include 3D printers such as RepRap, Prusa, and Ultimaker, 3D printer filament extruders such as polystruder XR3 and as well as the laser cutter Lasersaur. Open-source vehicles have also been developed including bicycles like XYZ Space Frame Vehicles and cars such as the Tabby OSVehicle. Examples of open source medical equipment include open-source ventilators, the echostethoscope echOpen, and a wide range of prosthetic hands listed in the review study by Ten Kate et.al. (e.g. OpenBionics’ Prosthetic Hands).

Other

Examples of open-source hardware products can also be found to a lesser extent in construction (Wikihouse), textile (Kit Zéro Kilomètres), and firearms (3D printed firearm, Defense Distributed).

Licenses

Rather than creating a new license, some open-source hardware projects use existing, free and open-source software licenses. These licenses may not accord well with patent law.

Later, several new licenses were proposed, designed to address issues specific to hardware design. In these licenses, many of the fundamental principles expressed in open-source software (OSS) licenses have been "ported" to their counterpart hardware projects. New hardware licenses are often explained as the "hardware equivalent" of a well-known OSS license, such as the GPL, LGPL, or BSD license.

Despite superficial similarities to software licenses, most hardware licenses are fundamentally different: by nature, they typically rely more heavily on patent law than on copyright law, as many hardware designs are not copyrightable. Whereas a copyright license may control the distribution of the source code or design documents, a patent license may control the use and manufacturing of the physical device built from the design documents. This distinction is explicitly mentioned in the preamble of the TAPR Open Hardware License:

"... those who benefit from an OHL design may not bring lawsuits claiming that design infringes their patents or other intellectual property."

— TAPR Open Hardware License

Noteworthy licenses include:

• The TAPR Open Hardware License: drafted by attorney John Ackermann, reviewed by OSS community leaders Bruce Perens and Eric S. Raymond, and discussed by hundreds of volunteers in an open community discussion
• Balloon Open Hardware License: used by all projects in the Balloon Project
• Although originally a software license, OpenCores encourages the LGPL
• Hardware Design Public License: written by Graham Seaman, admin of Opencollector.org
• In March 2011 CERN released the CERN Open Hardware License (OHL) intended for use with the Open Hardware Repository and other projects.
• The Solderpad License is a version of the Apache License version 2.0, amended by lawyer Andrew Katz to render it more appropriate for hardware use.

The Open Source Hardware Association recommends seven licenses which follow their open-source hardware definition. From the general copyleft licenses the GNU General Public License (GPL) and Creative Commons Attribution-ShareAlike license, from the hardware-specific copyleft licenses the CERN Open Hardware License (OHL) and TAPR Open Hardware License (OHL) and from the permissive licenses the FreeBSD license, the MIT license, and the Creative Commons Attribution license.^[54] Openhardware.org recommended in 2012 the TAPR Open Hardware License, Creative Commons BY-SA 3.0 and GPL 3.0 license.

Organizations tend to rally around a shared license. For example, OpenCores prefers the LGPL or a Modified BSD License, FreeCores insists on the GPL, Open Hardware Foundation promotes "copyleft or other permissive licenses", the Open Graphics Project uses a variety of licenses, including the MIT license, GPL, and a proprietary license, and the Balloon Project wrote their own license.

Development

The OSHW (Open Source Hardware) logo silkscreened on an unpopulated PCB

The adjective "open-source" not only refers to a specific set of freedoms applying to a product, but also generally presupposes that the product is the object or the result of a "process that relies on the contributions of geographically dispersed developers via the Internet." In practice however, in both fields of open-source hardware and open-source software, products may either be the result of a development process performed by a closed team in a private setting or by a community in a public environment, the first case being more frequent than the second which is more challenging. Establishing a community-based product development process faces several challenges such as: to find appropriate product data management tools, document not only the product but also the development process itself, accepting losing ubiquitous control over the project, ensure continuity in a context of fickle participation of voluntary project members, among others.

The Arduino Diecimila, another popular and early open source hardware design.

One of the major differences between developing open-source software and developing open-source hardware is that hardware results in tangible outputs, which cost money to prototype and manufacture. As a result, the phrase "free as in speech, not as in beer", more formally known as Gratis versus Libre, distinguishes between the idea of zero cost and the freedom to use and modify information. While open-source hardware faces challenges in minimizing cost and reducing financial risks for individual project developers, some community members have proposed models to address these needs Given this, there are initiatives to develop sustainable community funding mechanisms, such as the Open Source Hardware Central Bank.

Extensive discussion has taken place on ways to make open-source hardware as accessible as open-source software. Providing clear and detailed product documentation is an essential factor facilitating product replication and collaboration in hardware development projects. Practical guides have been developed to help practitioners to do so. Another option is to design products so they are easy to replicate, as exemplified in the concept of open-source appropriate technology.

The process of developing open-source hardware in a community-based setting is alternatively called open design, open source development or open source product development. All these terms are examples of the open-source model applicable for the development of any product, including software, hardware, cultural and educational. Does open design and open-source hardware design process involves new design practices, or raises requirements for new tools? is the question of openness really key in OSH?

A major contributor to the production of open-source hardware product designs is the scientific community. There has been considerable work to produce open-source hardware for scientific hardware using a combination of open-source electronics and 3-D printing. Other sources of open-source hardware production are vendors of chips and other electronic components sponsoring contests with the provision that the participants and winners must share their designs. Circuit Cellar magazine organizes some of these contests.

Open-source labs

A guide has been published (Open-Source Lab (book) by Joshua Pearce) on using open-source electronics and 3D printing to make open-source labs. Today, scientists are creating many such labs. Examples include:

• Boston Open Source Science Laboratory, Somerville, Massachusetts
• BYU Open Source Lab, Brigham Young University
• Michigan Tech
• National Tsing Hua University
• OSU Open Source Lab, Oregon State University
• Open Source Research Lab, University of Texas at El Paso

Business models

Open hardware companies are experimenting with business models. For example, littleBits implements open-source business models by making available the circuit designs in each electronics module, in accordance with the CERN Open Hardware License Version 1.2. Another example is Arduino, which registered its name as a trademark; others may manufacture products from Arduino designs but cannot call the products Arduino products. There are many applicable business models for implementing some open-source hardware even in traditional firms. For example, to accelerate development and technical innovation, the photovoltaic industry has experimented with partnerships, franchises, secondary supplier and completely open-source models.

Recently, many open-source hardware projects have been funded via crowdfunding on platforms such as Indiegogo, Kickstarter, or Crowd Supply.

Reception and impact

Richard Stallman, the founder of the free software movement, was in 1999 skeptical on the idea and relevance of free hardware (his terminology for what is now known as open-source hardware). In a 2015 article in Wired Magazine, he modified this attitude; he acknowledged the importance of free hardware, he still saw no ethical parallel with free software. Also, Stallman prefers the term free hardware design over open source hardware, a request which is consistent with his earlier rejection of the term open source software (see also Alternative terms for free software).

Other authors, such as Professor Joshua Pearce have argued there is an ethical imperative for open-source hardware – specifically with respect to open-source appropriate technology for sustainable development. In 2014, he also wrote the book Open-Source Lab: How to Build Your Own Hardware and Reduce Research Costs, which details the development of free and open-source hardware primarily for scientists and university faculty. Pearce in partnership with Elsevier introduced a scientific journal HardwareX. It has featured many examples of applications of open-source hardware for scientific purposes.

Robot Operating System

From Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Robot_Operating_System

Robot Operating System

Robot Operating System Logo
Cart pushing simulation in RVIZ
Original author(s)	Willow Garage Stanford Artificial Intelligence Laboratory Open Robotics
Initial release	2007; 15 years ago
Stable release	Galactic Geochelone (ROS 2) / 23 May 2021; 17 months ago
Preview release	Humble Hawksbill (ROS 2)
Repository	github.com/ros
Written in	C++, Python, or Lisp
Operating system	Linux, macOS (experimental), Windows 10 (experimental)
Type	Robotics suite, OS, library
License	Apache 2.0
Website	www.ros.org

Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. Running sets of ROS-based processes are represented in a graph architecture where processing takes place in nodes that may receive, post, and multiplex sensor data, control, state, planning, actuator, and other messages. Despite the importance of reactivity and low latency in robot control, ROS is not a real-time operating system (RTOS). However, it is possible to integrate ROS with real-time code. The lack of support for real-time systems has been addressed in the creation of ROS 2, a major revision of the ROS API which will take advantage of modern libraries and technologies for core ROS functions and add support for real-time code and embedded system hardware.

Software in the ROS Ecosystem can be separated into three groups:

• language-and platform-independent tools used for building and distributing ROS-based software;
• ROS client library implementations such as roscpp, rospy, and roslisp;
• packages containing application-related code which uses one or more ROS client libraries.

Both the language-independent tools and the main client libraries (C++, Python, and Lisp) are released under the terms of the BSD license, and as such are open-source software and free for both commercial and research use. The majority of other packages are licensed under a variety of open-source licenses. These other packages implement commonly used functionality and applications such as hardware drivers, robot models, datatypes, planning, perception, simultaneous localization and mapping, simulation tools, and other algorithms.

The main ROS client libraries are geared toward a Unix-like system, primarily because of their dependence on large collections of open-source software dependencies. For these client libraries, Ubuntu Linux is listed as "Supported" while other variants such as Fedora Linux, macOS, and Microsoft Windows are designated "experimental" and are supported by the community. The native Java ROS client library, rosjava, however, does not share these limitations and has enabled ROS-based software to be written for the Android OS. rosjava has also enabled ROS to be integrated into an officially supported MATLAB toolbox which can be used on Linux, macOS, and Microsoft Windows. A JavaScript client library, roslibjs has also been developed which enables integration of software into a ROS system via any standards-compliant web browser.

History

Early days at Stanford (2007 and earlier)

Sometime before 2007, the first pieces of what eventually would become ROS began coalescing at Stanford University. Eric Berger and Keenan Wyrobek, PhD students working in Kenneth Salisbury's robotics laboratory at Stanford, were leading the Personal Robotics Program. While working on robots to do manipulation tasks in human environments, the two students noticed that many of their colleagues were held back by the diverse nature of robotics: an excellent software developer might not have the hardware knowledge required, someone developing state of the art path planning might not know how to do the computer vision required. In an attempt to remedy this situation, the two students set out to make a baseline system that would provide a starting place for others in academia to build upon. In the words of Eric Berger, "something that didn’t suck, in all of those different dimensions".

In their first steps towards this unifying system, the two built the PR1 as a hardware prototype and began to work on software from it, borrowing the best practices from other early open-source robotic software frameworks, particularly switchyard, a system that Morgan Quigley, another Stanford PhD student, had been working on in support of the STanford Artificial Intelligence Robot (STAIR) by the Stanford Artificial Intelligence Laboratory. Early funding of US$50,000 was provided by Joanna Hoffman and Alain Rossmann, which supported the development of the PR1. While seeking funding for further development, Eric Berger and Keenan Wyrobek met Scott Hassan, the founder of Willow Garage, a technology incubator which was working on an autonomous SUV and a solar autonomous boat. Hassan shared Berger and Wyrobek's vision of a "Linux for robotics", and invited them to come and work at Willow Garage. Willow Garage was started in January 2007, and the first commit of ROS code was made to SourceForge on 7 November 2007.

Willow Garage (2007-2013)

Willow Garage began developing the PR2 robot as a follow-up to the PR1, and ROS as the software to run it. Groups from more than twenty institutions made contributions to ROS, both the core software and the growing number of packages which worked with ROS to form a greater software ecosystem. That people outside of Willow were contributing to ROS (especially from Stanford's STAIR project) meant that ROS was a multi-robot platform from the start. While Willow Garage had originally had other projects in progress, they were scrapped in favor of the Personal Robotics Program: focused on producing the PR2 as a research platform for academia and ROS as the open-source robotics stack that would underlie both academic research and tech startups, much like the LAMP stack did for web-based startups.

In December 2008, Willow Garage met the first of their three internal milestones: continuous navigation for the PR2 over a period of two days and a distance of pi kilometers. Soon after, an early version of ROS (0.4 Mango Tango) was released, followed by the first RVIZ documentation and the first paper on ROS. In early summer, the second internal milestone: having the PR2 navigate the office, open doors, and plug itself it in, was reached. This was followed in August by the initiation of the ROS.org website. Early tutorials on ROS were posted in December, preparing for the release of ROS 1.0, in January 2010. This was Milestone 3: producing tons of documentation and tutorials for the enormous abilities that Willow Garage's engineers had developed over the preceding 3 years.

Following this, Willow Garage achieved one of its longest held goals: giving away 10 PR2 robots to worthy academic institutions. This had long been a goal of the founders, as they felt that the PR2 could kick-start robotics research around the world. They ended up awarding eleven PR2s to different institutions, including University of Freiburg (Germany), Robert Bosch GmbH, Georgia Institute of Technology, KU Leuven (Belgium), Massachusetts Institute of Technology (MIT), Stanford University, Technical University of Munich (Germany), University of California, Berkeley, University of Pennsylvania, University of Southern California (USC), and University of Tokyo (Japan). This, combined with Willow Garage's highly successful internship program (run from 2008 to 2010 by Melonee Wise), helped to spread the word about ROS throughout the robotics world. The first official ROS distribution release: ROS Box Turtle, was released on 2 March 2010, marking the first time that ROS was officially distributed with a set of versioned packages for public use. These developments led to the first drone running ROS, the first autonomous car running ROS, and the adaption of ROS for Lego Mindstorms. With the PR2 Beta program well underway, the PR2 robot was officially released for commercial purchase on 9 September 2010.

An image of Robot Operating System (ROS) running in Antarctica.

2011 was a banner year for ROS with the launch of ROS Answers, a Q/A forum for ROS users, on 15 February; the introduction of the highly successful TurtleBot robot kit on 18 April; and the total number of ROS repositories passing 100 on 5 May. Willow Garage began 2012 by creating the Open Source Robotics Foundation (OSRF) in April. The OSRF was immediately awarded a software contract by the Defense Advanced Research Projects Agency (DARPA). Later that year, the first ROSCon was held in St. Paul, Minnesota, the first book on ROS, ROS By Example, was published, and Baxter, the first commercial robot to run ROS, was announced by Rethink Robotics. Soon after passing its fifth anniversary in November, ROS began running on every continent on 3 December 2012.

In February 2013, the OSRF became the primary software maintainers for ROS, foreshadowing the announcement in August that Willow Garage would be absorbed by its founders, Suitable Technologies. At this point, ROS had released seven major versions (up to ROS Groovy), and had users all over the globe. This chapter of ROS development would be finalized when Clearpath Robotics took over support responsibilities for the PR2 in early 2014.

OSRF and Open Robotics (2013–present)

In the years since OSRF took over primary development of ROS, a new version has been released every year, while interest in ROS continues to grow. ROSCons have occurred every year since 2012, co-located with either ICRA or IROS, two flagship robotics conferences. Meetups of ROS developers have been organized in a variety of countries, a number of ROS books have been published, and many educational programs initiated. On 1 September 2014, NASA announced the first robot to run ROS in space: Robotnaut 2, on the International Space Station. In 2017, the OSRF changed its name to Open Robotics. Tech giants Amazon and Microsoft began to take an interest in ROS during this time, with Microsoft porting core ROS to Windows in September 2018, followed by Amazon Web Services releasing RoboMaker in November 2018.

Perhaps the most important development of the OSRF/Open Robotics years thus far (not to discount the explosion of robot platforms which began to support ROS or the enormous improvements in each ROS version) was the proposal of ROS 2, a significant API change to ROS which is intended to support real time programming, a wider variety of computing environments, and utilize more modern technology. ROS 2 was announced at ROSCon 2014, the first commits to the ros2 repository were made in February 2015, followed by alpha releases in August 2015. The first distribution release of ROS 2, Ardent Apalone, was released on 8 December 2017, ushering in a new era of next-generation ROS development.

Design

Philosophy

An image depicting the ROS equation: Plumbing + Tools + Capabilities + Ecosystem = ROS!

ROS was designed to be open source, intending that users would be able to choose the configuration of tools and libraries which interacted with the core of ROS so that users could shift their software stacks to fit their robot and application area. As such, there is very little which is core to ROS, beyond the general structure within which programs must exist and communicate. In one sense, ROS is the underlying plumbing behind nodes and message passing. However, in reality, ROS is not only that plumbing, but a rich and mature set of tools, a wide-ranging set of robot-agnostic abilities provided by packages, and a greater ecosystem of additions to ROS.

Computation graph model

ROS processes are represented as nodes in a graph structure, connected by edges called topics. ROS nodes can pass messages to one another through topics, make service calls to other nodes, provide a service for other nodes, or set or retrieve shared data from a communal database called the parameter server. A process called the ROS Master makes all of this possible by registering nodes to itself, setting up node-to-node communication for topics, and controlling parameter server updates. Messages and service calls do not pass through the master, rather the master sets up peer-to-peer communication between all node processes after they register themselves with the master. This decentralized architecture lends itself well to robots, which often consist of a subset of networked computer hardware, and may communicate with off-board computers for heavy computing or commands.

Nodes

A node represents one process running the ROS graph. Every node has a name, which it registers with the ROS master before it can take any other actions. Multiple nodes with different names can exist under different namespaces, or a node can be defined as anonymous, in which case it will randomly generate an additional identifier to add to its given name. Nodes are at the center of ROS programming, as most ROS client code is in the form of a ROS node which takes actions based on information received from other nodes, sends information to other nodes, or sends and receives requests for actions to and from other nodes.

Topics

Topics are named buses over which nodes send and receive messages. Topic names must be unique within their namespace as well. To send messages to a topic, a node must publish to said topic, while to receive messages it must subscribe. The publish/subscribe model is anonymous: no node knows which nodes are sending or receiving on a topic, only that it is sending/receiving on that topic. The types of messages passed on a topic vary widely and can be user-defined. The content of these messages can be sensor data, motor control commands, state information, actuator commands, or anything else.

Services

A node may also advertise services. A service represents an action that a node can take which will have a single result. As such, services are often used for actions which have a defined start and end, such as capturing a one-frame image, rather than processing velocity commands to a wheel motor or odometer data from a wheel encoder. Nodes advertise services and call services from one another.

Parameter server

The parameter server is a database shared between nodes which allows for communal access to static or semi-static information. Data which does not change frequently and as such will be infrequently accessed, such as the distance between two fixed points in the environment, or the weight of the robot, are good candidates for storage in the parameter server.

Tools

ROS's core functionality is augmented by a variety of tools which allow developers to visualize and record data, easily navigate the ROS package structures, and create scripts automating complex configuration and setup processes. The addition of these tools greatly increases the abilities of systems using ROS by simplifying and providing solutions to a number of common robotics development problems. These tools are provided in packages like any other algorithm, but rather than providing implementations of hardware drivers or algorithms for various robotic tasks, these packages provide task and robot-agnostic tools which come with the core of most modern ROS installations.

rviz

rviz^[69] is a three-dimensional visualizer used to visualize robots, the environments they work in, and sensor data. It is a highly configurable tool, with many different types of visualizations and plugins.

rosbag

rosbag is a command line tool used to record and playback ROS message data. rosbag uses a file format called bags, which log ROS messages by listening to topics and recording messages as they come in. Playing messages back from a bag is largely the same as having the original nodes which produced the data in the ROS computation graph, making bags a useful tool for recording data to be used in later development. While rosbag is a command line only tool, rqt_bag provides a GUI interface to rosbag.

catkin

catkin is the ROS build system, having replaced rosbuild as of ROS Groovy. catkin is based on CMake, and is similarly cross-platform, open-source, and language-independent.

rosbash

The rosbash package provides a suite of tools which augment the functionality of the bash shell. These tools include rosls, roscd, and roscp, which replicate the functionalities of ls, cd, and cp respectively. The ROS versions of these tools allow users to use ros package names in place of the file path where the package is located. The package also adds tab-completion to most ROS utilities, and includes rosed, which edits a given file with the chosen default text editor, as well rosrun, which runs executables in ROS packages. rosbash supports the same functionalities for zsh and tcsh, to a lesser extent.

roslaunch

roslaunch is a tool used to launch multiple ROS nodes both locally and remotely, as well as setting parameters on the ROS parameter server. roslaunch configuration files, which are written using XML can easily automate a complex startup and configuration process into a single command. roslaunch scripts can include other roslaunch scripts, launch nodes on specific machines, and even restart processes which die during execution.

Packages of note

ROS contains many open-source implementations of common robotics functionality and algorithms. These open-source implementations are organized into packages. Many packages are included as part of ROS distributions, while others may be developed by individuals and distributed through code sharing sites such as github. Some packages of note include:

Systems and tools

• actionlib provides a standardized interface for interfacing with preemptable tasks.
• nodelet provides a way to run multiple algorithms in a single process.
• rosbridge provides a JSON API to ROS functionalities for non-ROS programs.

Mapping and localization

• slam toolbox provides full 2D SLAM and localization system.
• gmapping provides a wrapper for OpenSlam's Gmapping algorithm for simultaneous localization and mapping.
• cartographer provides real time 2D and 3D SLAM algorithms developed at Google.
• amcl provides an implementation of adaptive Monte-Carlo localization.

Navigation

• navigation provides the capability of navigating a mobile robot in a planar environment.

Perception

• vision_opencv is a meta-package which provides packages for integrating ROS with OpenCV.

Coordinate frame representation

• tf provided a system for representing, tracking and transforming coordinate frames until ROS Hydro, when it was deprecated in favor of tf2.
• tf2 is the second generation of the tf library, and provides the same abilities for ROS versions after Hydro.

Simulation

• gazebo_ros_pkgs is a meta-package which provides packages for integrating ROS with the Gazebo simulator.
• stage provides an interface for the 2D Stage simulator.

Versions and releases

ROS releases may be incompatible with other releases and are often referred to by code name rather than version number. ROS currently releases a version every year in May, following the release of Ubuntu LTS versions. ROS 2 currently releases a new version every six months (in December and July). These releases are supported for a single year. There are currently two active major versions seeing releases: ROS 1 and ROS 2. Aside to this there is the ROS-Industrial or ROS-I derivate project since at least 2012.

ROS 1

ROS 1 Distribution Releases 

Distribution	Release date	Poster	EOL date	Support duration
Noetic Ninjemys (last ROS 1 release)	23 May 2020		May 2025	5 years
Melodic Morenia	23 May 2018		2023-05-30	5 years
Lunar Loggerhead	23 May 2017		2019-05-30	2 years
Kinetic Kame	23 May 2016		2021-05-30	5 years
Jade Turtle	23 May 2015		2017-05-30	2 years
Indigo Igloo	22 July 2014		2019-04-30	5 years
Hydro Medusa	4 September 2013		2014-05-31	0.5 years
Groovy Galapagos	31 December 2012		2014-07-31	2 years
Fuerte Turtle	23 April 2012		--
Electric Emys	30 August 2011		--
Diamondback	2 March 2011		--
C Turtle	2 August 2010		--
Box Turtle	2 March 2010		--
(Initial Release)	2007	n/a	--	n/a
Old version Older version, still maintained Latest version Future release

ROS 2

ROS 2 Distribution Releases 

Distribution	Release date	Poster	EOL date	Support duration
Rolling Ridley (rolling release with latest features)	progressing since June 2020	(unknown)	N/A	N/A
(J Turtle)	May 2024	t.b.d.	EST. May 2029	5 years
(I Turtle)	May 2023	t.b.d.	EST. November 2024	1.5 years
Humble Hawksbill	May 2022		EST. May 2027	5 years
Galactic Geochelone	23 May 2021		November 2022	1.5 years
Foxy Fitzroy	5 June 2020		May 2023	2 years
Eloquent Elusor	22 November 2019		November 2020	1 year
Dashing Diademata	31 May 2019		May 2021	2 years
Crystal Clemmys	14 December 2018		December 2019	1 year
Bouncy Bolson	2 July 2018		July 2019	1 year
Ardent Apalone	8 December 2017		December 2018	1 year
beta3	13 September 2017	N/A	December 2017	4 months
beta2	5 July 2017	N/A	September 2017	2 months
(ROS 2 real-time proposal)	7 January 2016	N/A	N/A	N/A
beta1	19 December 2016	N/A	July 2017	7 months
alpha1 (Anchor) - alpha8 (Hook-and-Loop)	31 August 2015 - 5 October 2016	N/A	December 2016	total: 16 months
("Why ROS 2?")	20 July 2015	N/A	N/A	N/A
(batch CI jobs for ROS 2 and http://design.ros2.org)	referenced in Q&A 6 May 2015	N/A	N/A	N/A
(first commits to ROS 2 repository)	February 2015	N/A	N/A	N/A
ROSCon 2014: "Next-generation ROS: Building on DDS", "ROS 2.0: Developer preview"	12 September 2014	N/A	N/A	N/A
Old version Older version, still maintained Latest version Future release

ROS-Industrial

ROS-Industrial is an open-source project (BSD (legacy)/Apache 2.0 (preferred) license) that extends the advanced abilities of ROS to manufacturing automation and robotics. In the industrial environment, there are two different approaches to programming a robot: either through an external proprietary controller, typically implemented using ROS, or via the respective native programming language of the robot. ROS can therefore be seen as the software-based approach to program industrial robots instead of the classic robot controller-based approach.

The ROS-Industrial repository includes interfaces for common industrial manipulators, grippers, sensors, and device networks. It also provides software libraries for automatic 2D/3D sensor calibration, process path/motion planning, applications like Scan-N-Plan, developer tools like the Qt Creator ROS Plugin, and training curriculum that is specific to the needs of manufacturers. ROS-I is supported by an international Consortium of industry and research members. The project began as a collaborative endeavor between Yaskawa Motoman Robotics, Southwest Research Institute, and Willow Garage to support the use of ROS for manufacturing automation, with the GitHub repository being founded in January 2012 by Shaun Edwards (SwRI). Currently, the Consortium is divided into three groups; the ROS-Industrial Consortium Americas (led by SwRI and located in San Antonio, Texas), the ROS-Industrial Consortium Europe (led by Fraunhofer IPA and located in Stuttgart, Germany) and the ROS-Industrial Consortium Asia Pacific (led by Advanced Remanufacturing and Technology Centre (ARTC) and Nanyang Technological University (NTU) and located in Singapore).

The Consortia supports the global ROS-Industrial community by conducting ROS-I training, providing technical support and setting the future roadmap for ROS-I, as well as conducting precompetitive joint industry projects to develop new ROS-I abilities.

Real-time operating system

From Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Real-time_operating_system

A real-time operating system (RTOS) is an operating system (OS) for real-time applications that processes data and events that have critically defined time constraints. A RTOS is distinct from a time-sharing operating system, such as Unix, which manages the sharing of system resources with a scheduler, data buffers, or fixed task prioritization in a multitasking or multiprogramming environment. Processing time requirements need to be fully understood and bound rather than just kept as a minimum. All processing must occur within the defined constraints. Real-time operating systems are event-driven and preemptive, meaning the OS is capable of monitoring the relevant priority of competing tasks, and make changes to the task priority. Event-driven systems switch between tasks based on their priorities, while time-sharing systems switch the task based on clock interrupts.

Characteristics

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is 'jitter'. A 'hard' real-time operating system (hard RTOS) has less jitter than a 'soft' real-time operating system (soft RTOS). A late answer is a wrong answer in a hard RTOS while a late answer is acceptable in a soft RTOS. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. An RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.

An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

See the comparison of real-time operating systems for a comprehensive list. Also, see the list of operating systems for all types of operating systems.

Design philosophies

An RTOS is an operating system in which the time taken to process an input stimulus is less than the time lapsed until the next input stimulus of the same type.

The most common designs are:

• Event-driven – switches tasks only when an event of higher priority needs servicing; called preemptive priority, or priority scheduling.
• Time-sharing – switches tasks on a regular clocked interrupt, and on events; called round robin.

Time sharing designs switch tasks more often than strictly needed, but give smoother multitasking, giving the illusion that a process or user has sole use of a machine.

Early CPU designs needed many cycles to switch tasks during which the CPU could do nothing else useful. Because switching took so long, early OSes tried to minimize wasting CPU time by avoiding unnecessary task switching.

Scheduling

In typical designs, a task has three states:

1. Running (executing on the CPU);
2. Ready (ready to be executed);
3. Blocked (waiting for an event, I/O for example).

Most tasks are blocked or ready most of the time because generally only one task can run at a time per CPU. The number of items in the ready queue can vary greatly, depending on the number of tasks the system needs to perform and the type of scheduler that the system uses. On simpler non-preemptive but still multitasking systems, a task has to give up its time on the CPU to other tasks, which can cause the ready queue to have a greater number of overall tasks in the ready to be executed state (resource starvation).

Usually, the data structure of the ready list in the scheduler is designed to minimize the worst-case length of time spent in the scheduler's critical section, during which preemption is inhibited, and, in some cases, all interrupts are disabled, but the choice of data structure depends also on the maximum number of tasks that can be on the ready list.

If there are never more than a few tasks on the ready list, then a doubly linked list of ready tasks is likely optimal. If the ready list usually contains only a few tasks but occasionally contains more, then the list should be sorted by priority. That way, finding the highest priority task to run does not require iterating through the entire list. Inserting a task then requires walking the ready list until reaching either the end of the list, or a task of lower priority than that of the task being inserted.

Care must be taken not to inhibit preemption during this search. Longer critical sections should be divided into small pieces. If an interrupt occurs that makes a high priority task ready during the insertion of a low priority task, that high priority task can be inserted and run immediately before the low priority task is inserted.

The critical response time, sometimes called the flyback time, is the time it takes to queue a new ready task and restore the state of the highest priority task to running. In a well-designed RTOS, readying a new task will take 3 to 20 instructions per ready-queue entry, and restoration of the highest-priority ready task will take 5 to 30 instructions.

In more advanced systems, real-time tasks share computing resources with many non-real-time tasks, and the ready list can be arbitrarily long. In such systems, a scheduler ready list implemented as a linked list would be inadequate.

Algorithms

Some commonly used RTOS scheduling algorithms are:

• Cooperative scheduling
• Preemptive scheduling
  • Rate-monotonic scheduling
  • Round-robin scheduling
  • Fixed priority pre-emptive scheduling, an implementation of preemptive time slicing
  • Fixed-Priority Scheduling with Deferred Preemption
  • Fixed-Priority Non-preemptive Scheduling
  • Critical section preemptive scheduling
  • Static time scheduling
• Earliest Deadline First approach
• Stochastic digraphs with multi-threaded graph traversal

Intertask communication and resource sharing

A multitasking operating system like Unix is poor at real-time tasks. The scheduler gives the highest priority to jobs with the lowest demand on the computer, so there is no way to ensure that a time-critical job will have access to enough resources. Multitasking systems must manage sharing data and hardware resources among multiple tasks. It is usually unsafe for two tasks to access the same specific data or hardware resource simultaneously. There are three common approaches to resolve this problem:

Temporarily masking/disabling interrupts

General-purpose operating systems usually do not allow user programs to mask (disable) interrupts, because the user program could control the CPU for as long as it wishes. Some modern CPUs do not allow user mode code to disable interrupts as such control is considered a key operating system resource. Many embedded systems and RTOSs, however, allow the application itself to run in kernel mode for greater system call efficiency and also to permit the application to have greater control of the operating environment without requiring OS intervention.

On single-processor systems, an application running in kernel mode and masking interrupts is the lowest overhead method to prevent simultaneous access to a shared resource. While interrupts are masked and the current task does not make a blocking OS call, the current task has exclusive use of the CPU since no other task or interrupt can take control, so the critical section is protected. When the task exits its critical section, it must unmask interrupts; pending interrupts, if any, will then execute. Temporarily masking interrupts should only be done when the longest path through the critical section is shorter than the desired maximum interrupt latency. Typically this method of protection is used only when the critical section is just a few instructions and contains no loops. This method is ideal for protecting hardware bit-mapped registers when the bits are controlled by different tasks.

Mutexes

When the shared resource must be reserved without blocking all other tasks (such as waiting for Flash memory to be written), it is better to use mechanisms also available on general-purpose operating systems, such as a mutex and OS-supervised interprocess messaging. Such mechanisms involve system calls, and usually invoke the OS's dispatcher code on exit, so they typically take hundreds of CPU instructions to execute, while masking interrupts may take as few as one instruction on some processors.

A (non-recursive) mutex is either locked or unlocked. When a task has locked the mutex, all other tasks must wait for the mutex to be unlocked by its owner - the original thread. A task may set a timeout on its wait for a mutex. There are several well-known problems with mutex based designs such as priority inversion and deadlocks.

In priority inversion a high priority task waits because a low priority task has a mutex, but the lower priority task is not given CPU time to finish its work. A typical solution is to have the task that owns a mutex 'inherit' the priority of the highest waiting task. But this simple approach gets more complex when there are multiple levels of waiting: task A waits for a mutex locked by task B, which waits for a mutex locked by task C. Handling multiple levels of inheritance causes other code to run in high priority context and thus can cause starvation of medium-priority threads.

In a deadlock, two or more tasks lock mutex without timeouts and then wait forever for the other task's mutex, creating a cyclic dependency. The simplest deadlock scenario occurs when two tasks alternately lock two mutex, but in the opposite order. Deadlock is prevented by careful design.

Message passing

The other approach to resource sharing is for tasks to send messages in an organized message passing scheme. In this paradigm, the resource is managed directly by only one task. When another task wants to interrogate or manipulate the resource, it sends a message to the managing task. Although their real-time behavior is less crisp than semaphore systems, simple message-based systems avoid most protocol deadlock hazards, and are generally better-behaved than semaphore systems. However, problems like those of semaphores are possible. Priority inversion can occur when a task is working on a low-priority message and ignores a higher-priority message (or a message originating indirectly from a high priority task) in its incoming message queue. Protocol deadlocks can occur when two or more tasks wait for each other to send response messages.

Interrupt handlers and the scheduler

Since an interrupt handler blocks the highest priority task from running, and since real-time operating systems are designed to keep thread latency to a minimum, interrupt handlers are typically kept as short as possible. The interrupt handler defers all interaction with the hardware if possible; typically all that is necessary is to acknowledge or disable the interrupt (so that it won't occur again when the interrupt handler returns) and notify a task that work needs to be done. This can be done by unblocking a driver task through releasing a semaphore, setting a flag or sending a message. A scheduler often provides the ability to unblock a task from interrupt handler context.

An OS maintains catalogues of objects it manages such as threads, mutexes, memory, and so on. Updates to this catalogue must be strictly controlled. For this reason, it can be problematic when an interrupt handler calls an OS function while the application is in the act of also doing so. The OS function called from an interrupt handler could find the object database to be in an inconsistent state because of the application's update. There are two major approaches to deal with this problem: the unified architecture and the segmented architecture. RTOSs implementing the unified architecture solve the problem by simply disabling interrupts while the internal catalogue is updated. The downside of this is that interrupt latency increases, potentially losing interrupts. The segmented architecture does not make direct OS calls but delegates the OS related work to a separate handler. This handler runs at a higher priority than any thread but lower than the interrupt handlers. The advantage of this architecture is that it adds very few cycles to interrupt latency. As a result, OSes which implement the segmented architecture are more predictable and can deal with higher interrupt rates compared to the unified architecture.

Similarly, the System Management Mode on x86 compatible Hardware can take a lot of time before it returns control to the operating system.

Memory allocation

Memory allocation is more critical in a real-time operating system than in other operating systems.

First, for stability there cannot be memory leaks (memory that is allocated but not freed after use). The device should work indefinitely, without ever needing a reboot. For this reason, dynamic memory allocation is frowned upon. Whenever possible, all required memory allocation is specified statically at compile time.

Another reason to avoid dynamic memory allocation is memory fragmentation. With frequent allocation and releasing of small chunks of memory, a situation may occur where available memory is divided into several sections and the RTOS is incapable of allocating a large enough continuous block of memory, although there is enough free memory. Secondly, speed of allocation is important. A standard memory allocation scheme scans a linked list of indeterminate length to find a suitable free memory block, which is unacceptable in an RTOS since memory allocation has to occur within a certain amount of time.

Because mechanical disks have much longer and more unpredictable response times, swapping to disk files is not used for the same reasons as RAM allocation discussed above.

The simple fixed-size-blocks algorithm works quite well for simple embedded systems because of its low overhead.