ROS is a middleware for robotics that provides tools for interprocess communication, build systems, and an ecosystem of open source robot software. It was originally developed at Stanford in 2007 and is now maintained by OSRF. ROS uses nodes that communicate over topics. It has support for C++ and Python and tools for simulation, visualization, documentation and more. ROS makes research easier through its architecture of distributed processes that communicate asynchronously.
ROS is a middleware for robotics that provides tools for interprocess communication, build systems, and an ecosystem of open source robot software. It was originally developed at Stanford in 2007 and is now maintained by OSRF. ROS uses nodes that communicate over topics. It has support for C++ and Python and tools for simulation, visualization, documentation and more. ROS makes research easier through its architecture of distributed processes that communicate asynchronously.
ROS is a middleware for robotics that provides tools for interprocess communication, build systems, and an ecosystem of open source robot software. It was originally developed at Stanford in 2007 and is now maintained by OSRF. ROS uses nodes that communicate over topics. It has support for C++ and Python and tools for simulation, visualization, documentation and more. ROS makes research easier through its architecture of distributed processes that communicate asynchronously.
ROS is a middleware for robotics that provides tools for interprocess communication, build systems, and an ecosystem of open source robot software. It was originally developed at Stanford in 2007 and is now maintained by OSRF. ROS uses nodes that communicate over topics. It has support for C++ and Python and tools for simulation, visualization, documentation and more. ROS makes research easier through its architecture of distributed processes that communicate asynchronously.
Robotics Research Make your research easier with ROS and other tools What is ROS? ROS - the Robot Operating System
a middleware
for interprocess communication and management
a build system / toolchain
an ecosystem of open source robotics software
your friend! A brief history Originally developed for class software at Stanford (c. 2007) First pub ICRA 2009
Big boost in being used on the PR2 at Willow
Garage (Started with Box turtle, now Jade)
OSRF created to keep ROS going after Willow
Garage closed
ROS 2.0 coming soon, standardized transports
with QOS, better support for other OSes, lighter weight embedded support,... The Ecosystem Kinematics and Dynamics Kinematic transforms and frames Orocos / KDL - Forward and inverse kinematics and dynamics Control and Planning Standardized control interfaces OMPL - Open Motion Planning Library Motion planning libraries (MoveIt!) Lots of robot drivers / controllers already built Perception OpenCV & PCL - Point Cloud Library integration Mapping and localization Camera calibration Stereo image matching Laser data processing ... The Ecosystem Kinematics and Dynamics Control and Planning Perception Simulation Gazebo now with multiple physics engines! Visualization RVIZ Getting / Installing and Using Full support currently only on Ubuntu Linux
Important to match releases of ROS with appropriate Linux releases
ROS 2.0 should fix some of these issues
Current setup for our robots is using Ubuntu 14.04 LTS with ROS Indigo
Can easily install through the package manager (apt)
but installing from source is not too hard, particularly if its only a few packages you need to hack on
and is SIGNIFICANTLY easier than 5 or 6 years ago
Code Implementation First class support for two languages: C++ Python
Somewhat supported: Matlab / Octave (with help from MathWorks now) Java lisp Issues Native real-time support is poor
Can be a lot of infrastructure for small projects
particularly with limited system resources
Constrained on system choices
Sometimes you get what you pay for
...but you are always free to fix it yourself!
Developing Releasing Code for Research All your code is in a backed up in a repository, right? If not you need to do that today! Bitbucket and github offer free private repositories for academics (.edu email address)
When you submit a paper, tag your code in your
repository! can easily replicate your results New collaborators will know exactly what you did when it worked! Also easy to make a "demo" branch Documentation Structured information in package.xml files
Gets scraped from registered repositories and updated on wiki:
http://wiki.ros.org
Can automatically generate documentation from doxygen too
Other People's Code Lots of sources When should you use it, when should you write your own? Labmates' code
Other labs
code from class
Why you may want it
To compare to your method
To help you build your system
The Architecture ROS Architecture First, there are really good tutorials on this you can check out here:
http://wiki.ros.org/ROS/Tutorials
And there are a list of more resources on the course website:
http://www.coe.utah.edu/~cs7939/ros_tips.html ROS Components: interprocess communication (IPC) Nodes - processes on the system (registered with the ROS master node) Topics - publish-subscribe communication (TCP/IP usually...)
cam_image arm_pose Camera Arm Tracker Control Node Node Policy Node
joint_cmd cur_joint_state
Joint Arm Encoder Controller Node Node Nodes Primary construct in ROS
Each node is a separate executable
Creates distributed processes for performing some "atomic" processing
Can range from
very simple (e.g repackage some data stream into a more useful data type)
to very complex (e.g. take visual data, extract features, plan a desired task space trajectory, perform feedback control to track the trajectory) Topics and Messages Topics transport strongly-typed messages between nodes publishers publish to a named topic (e.g. joint_state) subscribers subscribe to a topic can have multiple publishers or subscribers on the same topic Beer Detector Node
Camera cam_image Node Obstacle Avoidance Node Messages Messages typed structures (specified in a txt file) built from primitive types hierarchical structure can get complicated standard header: time, seq, frame_id
Standard Message types
geometry - Point, Pose, PoseStamped,... perception - PointCloud2, Image, Camera, control - JointState, Defining a New Message Easily defined in text files Example.msg Accessing data in python:
string object_name int object_height geometry_msgs/Pose object_pose
Also supports arrays (fixed and variable length)
Services Services are request-reply blocking communications between nodes: node_1 sends a request message to node_2 node_1 waits node_2 performs some computation based on the request and sends a response message back to node_1 node_1 receives the result and continues processing E.g. exp1_node sets up all necessary conditions to run an experiment exp1_node sends a service request to move the robot spine to the correct height exp1_node then sends a request to start the experiment using your feedback controller Service files *.srv instead of *.msg
Format:
field1 req1 field2 req2 --- field3 res1 field4 res2 Parameter Server Shared dictionary of variables between all nodes
Nodes can store and retrieve parameter values at runtime
Primarily used for static value parameter setting
Not optimized for real-time or large data performance
ROS Master Node "The ROS Master provides naming and registration services to the rest of the nodes in the ROS system. It tracks publishers and subscribers to topics as well as services. The role of the Master is to enable individual ROS nodes to locate one another. Once these nodes have located each other they communicate with each other peer-to-peer.
The Master also provides the Parameter Server."
Actionlib More advanced Finite State Machine interactions Gives more control than simple services ...but requires much more specification and care in implementing. Gives feedback during execution (can track progress to goal) Can update input during execution as well Review Nodes - processes for performing computation
Topics - send messages between nodes
Publishers and Subscribers - communicate over common topics
Services - message passing which blocks until the receiving node finishes and returns a result
Parameters - can be got or set at anytime from the parameter server
Launch files - files for organizing complicated structures of the above
Review: ROS Components Nodes - processes on the system (registered with the ROS master node) Topics - publish-subscribe communication (TCP/IP usually...)
cam_image arm_pose Camera Arm Tracker Control Node Node Policy Node
joint_cmd cur_joint_state Parameter Server: "jakes_g" = 9.7 Joint Arm "/left_arm/joint0/init_pos" = Encoder Controller 0.2 Node Node ... Using ROS Setting up an environment Can easily install packages in Ubuntu via apt
Need to set certain environmental variables to access command line tools and navigate the ROS system easily.
These environment variables can get complicated for large projects or many projects that are switched between. Some tools to help with this, but can get confusing quickly.
This is where the tutorials & documentation online are better than what I can offer Command line tools Has many tools for interacting with the system: roscd - easily navigate to different ros packages > roscd beer_detector_pkg rosrun - run ROS nodes in other directories from an arbitrary path > rosrun beer_detector_pkg beer_detector_node.py roscore - creates the ROS master as well as parameter server and ros output aggregator NEEDS TO BE RUN BEFORE RUNNING ROS NODES! rostopic - get info on current topics running rosmsg - look up information about available ROS messages (e.g. hz, echo, ) And many others... Launch Files...make your life easier! XML files for specifying:
nodes to launch and their unique names
topic names and who subscribes and publishes to them
parameter values to set on the parameter server
Automatically launches roscore, so you don't have to
Can include other launch files
Are your best friend in setting up complicated systems
TF Transform Library
Gives easy access to kinematic and
dynamic transformations between different reference frames
Just need to specify robot & environment
structure and publish / update joint states
Remember all sensor messages should be
stamped with frame and time, so can easily reproduce URDF - Universal Robot Description Format XML file describing robot links, joints, motors
Geometry: Can define separate visual and (simpler) collision geometries URDF: Example rosbag: Logging and Replaying Data Collects data published over different topics
By default you can log everything
Can also just log some data (e.g. camera info and joint states)
Can then playback data as if they are publishers
Helpful in developing and tuning code that requires data to perform
Can be used for diagnostic data collection
Helpful in debugging strange behavior on robots
Conclusions 1. Backup your code in a structured way 2. Document your code 3. Write modular, reusable software 4. Leverage existing software
MATLAB and Simulink In-Depth: Model-based Design with Simulink and Stateflow, User Interface, Scripting, Simulation, Visualization and Debugging (English Edition)
MATLAB and Simulink In-Depth: Model-based Design with Simulink and Stateflow, User Interface, Scripting, Simulation, Visualization and Debugging (English Edition)
