January 2010 Archives

ROS 1.0

| No Comments | No TrackBacks

ROS

ROS 1.0 has been released!

We also released pr2_simulator 1.0 today, which completes our 1.0 release cycle.

To put this all in context, getting to 1.0 meant completing:

  • 203 ROS software tutorials
  • 29 ROS Stacks at 1.0 status, which contain a total of 186 ROS Packages
  • 21 Use Cases, requiring well over a hundred user studies

We also launched the ROS.org community site, including revamped wiki, blog, and faster SVN servers.

Development on ROS began a little over two years ago. There have been many changes since those early days, and what started as a little project with a couple of developers has blossomed into a vibrant community supporting a wide variety of robots, big and small, academia and industry.

We hope that this 1.0 release will help the community even more and that you all will continue to participate and contribute.

While ROS 1.0 is an important step, we're even more excited by the many other libraries that have reached 1.0, including:

We look forward to your feedback and improvements on these building blocks.

-- your friendly neighborhood ROS 1.0 team

Changes

The focus of changes for this release was on bug fixes, cleanup, and resolving any remaining API issues.

There was one deprecated API removed in this final release, and will require migration for code not yet updated: * roscpp: Removed deprecated 3-argument versions of param::get() and NodeHandle::getParam()

rospy now also warns on illegal names. We have been introducing more name strictness in ROS. ROS auto-generates source code of messages and services. The name strictness ensures that source code can be validly generated for these types. There are also potential features in our roadmap that will require name strictness as well.

For a complete list of changes in this release, please see the change list.

Thursday 1.0 Release: pr2_controllers

| No Comments | No TrackBacks

pr2_controllers.png

Today we released pr2_controllers 1.0. This stack contains our realtime controllers for the PR2, as well as actionlib interfaces for invoking these controllers.

As you can tell, the pace of our 1.0 releases is slowing down... because we're almost done! If you're waiting for ROS 1.0, don't worry -- the ROS team happens to like releasing on Fridays.

There were several other releases today. These were mostly for stacks that are under development, but provide useful functionality to PR2 users. We'll be releasing videos showing what the future has in store for these stacks. We also released a minor update to pr2_common.

Change lists:

Wednesday 1.0 Releases: pr2_gui

| No Comments | No TrackBacks

pr2_gui.png

Today we released pr2_gui 1.0. pr2_gui provides the pr2_dashboard, which is an integral tool we use for understanding the state of our PR2 robots.

We are busy putting the final touches on our remaining 1.0 releases. We releases several more stack updates today, including two new stacks: robot_calibration and pr2_calibration. Although these calibration stacks are not mature, yet, they are already proving very useful in calibrating our new PR2 Beta robots.

Change lists:

laser_drivers.png driver_common.png pr2_ethercat_drivers.png pr2_power_drivers.png pr2_common.png

Today was a big day for releasing drivers. Our 1.0 releases today were:

We are nearly finished with our 1.0 release cycle. With today's releases, most commonly used functionality with ROS has been released as 1.0, which means that non-PR2 robots using navigation and perception capabilities have a solid base to build on top of.

We also wanted to note that ROS 1.0 is in final testing. You can preview our release candidate at:

https://code.ros.org/svn/ros/stacks/ros/tags/rc/

driver_common provides common driver capabilities that we use in our laser and camera drivers, such as dynamic reconfiguration of parameters. Our laser_drivers stack provides drivers for common Hokuyo and SICK laser rangefinders. We also released pr2_ethercat_drivers and pr2_power_drivers, which support PR2-specific hardware.

Our non-driver release of the day was pr2_common 1.0, which contains description of the PR2 Beta robot, PR2-specific messages, and other common PR2 data.

We also released several other stacks today, including the new web_interface and pr2_web_apps stacks, which provide a user-friendly, browser-based environment for performing common robot tasks and monitoring.

Change lists:

pr2_mechanism.png image_pipeline.png

Today we released two more stacks as 1.0, including the first of our PR2-related stacks as 1.0:

Several other PR2-related stacks have hit release candidate status for 1.0 and will be released in the coming days.

diagnostics has been updated 1.0.1 to patch a problem seen on Ubuntu distributions prior to Karmic. We also put out updates of several other stacks, including:

Change lists:

Arduino and cmucam3 support for ROS

| No Comments | No TrackBacks

Andrew Harris just announced support for the Arduino and cmucam3 with ROS packages in his own ajh-ros-pkg repository. The announcement is below.*

Hello, I have released the source code to my ROS packages for communicating with the Arduino and the cmucam3.

pmad (Arduino)

You can get the code from:

https://ajh-ros-pkg.svn.sourceforge.net/svnroot/ajh-ros-pkg/trunk/pmad/

There is a subdirectory in there called "arduino" that contains a sketch.txt file. This is the sketch you must load into the GUI and upload to the Arduino. Once you do that, you can start the PMAD service:

rosrun pmad pmad_service.py

Note that you'll have to have a "tty" ROS parameter set up if the USB does not connect as /dev/ttyUSB0. You might have to set tty to "/dev/ttyUSB1" for example. Once you set up the service, you can toggle the digital pins with:

rosservice call pmad_switch_control 4 0

This for example will set digital pin 4 to LOW. Note the status packet below only returns the state of digital pins 4, ..., 7.

In addition to this, there is a service status that returns the current A/D outputs on analog pins 0, ..., 3, digital pins 4, ..., 7, and a count of the number of commands executed.

If you want to get the status to be a "topic", there is an application

rosrun pmad pmad_status_publisher.py

That will publish the status data once per second. The status message is defined in msg/Status.msg.

BTW pmad stands for power management and distribution, I use solid state relays on the outputs of the digital pins.

cmucam_png (cmucam3)

In terms of the cmucam_png node, it acquires a png file from the cmucam about once every twenty seconds and publishes it as a compressed image. To be honest I haven't used it in a while as I've switched to a firewire USB camera. The image is a PNG file. It takes ~20 seconds per image because they come over a 115,200 bps serial line. They are 352x287 pixels in size.

https://ajh-ros-pkg.svn.sourceforge.net/svnroot/ajh-ros-pkg/trunk/cmucam_png/

Right now for some reason I get compiler errors compiling image_view so I can't try the image_view to make sure the image is getting pushed around. However I have recently tested that I can receive an image from the cmucam and save it to disk as a png by just adding a couple lines to save the received png to disk. I am just having trouble pushing the image around ROS, but it might just be my setup. (It worked in the past ;) )

For the cmucam application, there is also a binary that must be downloaded to the camera. The source, etc, for this is in the directory "png-robin". In order to get this working you should have a working installation of the cmucam3 development environment, and be able to compile the examples in the cc3/projects directory. Once you can do this, and download these examples to the camera, you can make a new directory in that examples directory called png-robin and copy the contents of this directory into that one. The makefile will then work and compile the application. I have also checked in a hex file that you can use if you don't want to compile the application yourself. But you'll still have to download the hex file with lpc21isp.

Hopefully I have made the packages correctly, but these are the first ones I've tried to make. If you have any questions on either of these nodes, of if they don't seem to work, let me know!

thanks, -andrew

diagnostics.png joystick_drivers.png imu_drivers.png

Today, three of our driver-related stack reached 1.0 status:

These stacks provide drivers and diagnostic capability for the Microstrain 3DM-GX2 IMU, PS3 joystick, and the Linux joystick. There is also experimental support for the Wiimote and 3Dconnexion SpaceNavigator. The diagnostics stack also provides GUIs for viewing diagnostic information from these and other drivers.

We also had several more releases today to test features and bug fixes for coming 1.0 releases:

Next week, we will start to transition towards 1.0 releases of PR2-related components -- we hope you enjoyed today's unveiling of the PR2 Beta robots!

Change lists:

navigation.png slam_gmapping.png simulator_gazebo.png

Today we released three more stacks with 1.0 status:

This set of releases, combined with our previous release, provides the complete ROS navigation stack, including SLAM, with stable APIs and support. The navigation stack is in use on a wide variety of robots, and we're excited that this fundamental and robust capability has reached this milestone.

Additionally, the release of simulator_gazebo, which wraps the open-source Gazebo simulator, lays the groundwork for our upcoming release of the pr2_simulator stack.

Several stacks were released today to test functionality prior to 1.0 release. Many of our driver stacks are nearing 1.0 release, with both joystick_drivers and imu_drivers already in 1.0 release candidate status.

Change lists:

navigation 0.8.1 released

| No Comments | No TrackBacks

navigation.png

navigation 0.8.1 has just been released. The primary purpose of this release is to move visualization topics into the namespace of the node instead of having them clutter the global namespace. This means that instead of rviz subscribing to local_costmap/obstacles to display obstacle information, it will instead subscribe to move_base_node_name/local_costmap/obstacles. For most people using the navigation stack, you won't have to change a thing, there are, however, a few exceptions to this:

  1. If you subscribe to any of the visualization topics that move_base publishes, and your code lives outside the patched WG repository, you'll have to prepend the name of the move_base node onto those subscriptions. If you're using launch files from the Willow Garage repositories, that name will be "move_base_node." If you're using launch files from your own repositories that will be whatever name you decided to give the move_base node.

  2. If you use the "make_plan" service provided by move_base, and your code lives outside the patched WG repository, you'll instead have to call "move_base_node/make_plan."

  3. If you command the local version of move_base that operates in the odometric frame (found in 2dnav_pr2/move_base_local), and your code lives outside of the patched WG repository, you'll need to change from using local_navigation/move_base_simple/goal> to move_base_local_simple/goal.

I apologize in advance for any pain that these changes cause, but the global namespace was just getting too cluttered on our robots here at WG, and I don't expect that these changes will affect too many people. If you have any questions, concerns, or problems with the migration please don't hesitate to let me know.

Ok, that's the annoying part of this release. The exciting part of this release is its inclusion of SLAM support for the navigation stack. The costmaps now subscribe to the map as a latched topic instead of using a service call and support dynamic updates. This means, running SLAM with the navigation stack is easy, to see things in action follow these three steps:

  1. Make sure you're running on the latest versions of the navigation and slam_gmapping stacks, and update in wg-ros-pkg
  2. rosmake 2dnav_slam_stage
  3. roslaunch 2dnav_slam_stage move_base_slam_5cm.launch (it may take a few seconds for the map to show up)

That's it, you should be able to send the robot goals in unknown space and it should build a map as it goes.

Hopefully, this release will just become navigation 1.0, but I'm going to give it the rest of the day to get some more testing in.

As always, let me know if you have any issues, questions, comments, concerns, etc.

Also, for those of you on OSX, nav_view has been patched so it should build and run correctly now.

Hope all is well, Eitan

robot_model.png visualization.png

Today we added two more 1.0 releases:

These releases mean that the rviz 3D visualization tool has officially reached 1.0 status. The visualization stack also recently added plugins for the ROS rxbag tool, which you will be able to use with the ROS 0.11 release. The robot_model stack is largely unchanged from its previous release.

Two other stacks also had releases today to do some final integration before they reach 1.0 status:

Change lists:

geometry 1.0 released!

| No Comments | No TrackBacks

geometry.png

We're glad to announce the first full release of geometry. The geometry stack provides important libraries in ROS, including the tf coordinate transform library, as well as ROS wrappers for the popular Bullet physics engine and KDL kinematics and dynamics library.

This release does mark the removal of several previously deprecated functions and methods. However, the APIs that are released are stable and the 1.0 series will be supported with patches in the upcoming ROS "Box Turtle" distribution.

Major Changes

Full changelist

  • Lots of new documentation on the wiki at tf
  • transform_sender has been replaced with static_transform_publisher, which has the same functionality.
  • New helper functions in "tf/transform_datatypes.h" for working around Bullet deprecations
  • New exception tf::InvalidArgument can be thrown for bad arguments. It inherits from tf::TransformException. This is used for things like unnormalized quaternions which would produce nan results.
  • tf::remap() methods have been deprecated. Replace them with tf::resolve() or tf::TransformListener::resolve().
  • Deprecated functions have been removed:
    • All tf::Stamped methods have been removed, there are drop in replacements supporting datatype tf::StampedTransform. This includes variants of lookupTransform(), data converter methods, setTransform(), and sendTransform()
    • tf::Stamped no longer has a child_frame_id field
    • MessageNotifier has been removed.
    • TransformListener::canTransform() with timeout has been removed, use waitForTransform() instead.
    • transformStampedTFToMsg()
    • transformStampedMsgToTF()
  • The topic "/tf_message" is no longer valid. If you are using bag files it is recommended to rebag them remapping the topic to "/tf". Playback can be remapped each time with "/tf_message:=/tf" on the command line. Please see the full changelist for a migration script for bags.

geometry.png laser_pipeline.png simulator_stage.png

Our 1.0 releases continue today with three new stacks hitting 1.0 status:

simulator_stage and laser_pipeline are largely unchanged from previous releases. geometry, in particular tf, has many changes worth noting, so they will be detailed in a separate announcement.

We are now a third of the way through our 1.0 release process and expect several more 1.0 releases this week.

Another major release today was pr2_controllers 0.3.0. That stack is now in our stable release process now that it has cleared user testing.

Several other stacks were released today in order to support the release process. With the exception of pr2_controllers, these were all patch updates. Although these releases contain new functionality and patches, we recommend waiting to update as many of these stacks will soon be reaching 1.0 status.

Change lists

-- your friendly neighborhood ROS distributors

vision_opencv.png image_common.png

To update on our ongoing process of 1.0 releases, two more stacks were released with the 1.0 label today:

  • vision_opencv 1.0
  • image_common 1.0

In order to prepare for upcoming 1.0 releases, many of the ROS stacks have been undergoing release updates to do final integration checks and ensure compatibility across stacks. We expect to see several more of these types of releases as we prepare release candidates for the remaining 1.0 stacks. Although these releases contain new functionality and patches, we recommend waiting to update as many of these stacks will soon be reaching 1.0 status. The new releases include:

  • camera_drivers 0.3.1
  • driver_common 0.2.2
  • imu_drivers 0.3.1
  • joystick_drivers 0.9.4
  • laser_drivers 0.3.0
  • pr2_simulator 0.2.7
  • simulator_stage 0.10.2
  • simulator_gazebo 0.6.10

There was also a minor update to physics_ode to add a dependency on the 'ros' stack:

  • physics_ode 1.0.1

Here are links to the change lists:

diagnostics 0.5.0 released

| No Comments | No TrackBacks

diagnostics.png

We've just released diagnostics 0.5.0. We're moving towards final integration later this week. With this release, we added a few new features to the diagnostic_aggregator, and focused on our documentation and tutorials for the other components. We'd like to see our diagnostic toolchain used on more robots as ROS spreads.

For complete changes, plase see the complete changelist.

Major Changes

  • diagnostic_aggregator
    • Added AnalyzerGroup class to group other Analyzers
    • Can discard stale diagnostic items
    • Analyzer function 'bool match(const string) const' is deprecated, new version is non-const.
  • robot_monitor
    • Reports status of diagnostics_agg topic, helps debug network issues
    • User testing feedback incorporated
  • diagnostic_updater, self_test
    • Deprecated functionality removed
    • Frequency status "errors" went to "warnings"

Download

image_pipeline 0.9.0 released

| No Comments | No TrackBacks

image_pipeline.png

image_pipeline-0.9.0 is now out. image_pipeline fills the gap between camera_drivers and higher-level vision processing. It includes a camera calibration GUI, a lightweight viewer for image topics, and nodes to perform color interpolation, rectification and stereo processing on camera images.

This is a stable release and has passed our user testing requirements. For changes see the changelist below. This release finally removes much long-deprecated code. In particular, the old stereoproc node is gone, as are all of the stereo messages excepting DisparityImage (which has a new definition).

Changes

image_proc:

  • Raw images may now be 8-bit mono, RGB, BGR, or any of the four bayer encodings.
  • Now using OpenCV for bayer interpolation.
  • Now using image_geometry for rectification.
  • Better error reporting when started in global namespace or input topics do not exist.

stereo_image_proc:

  • Inherited improvements from image_proc.
  • Now using OpenCV's block matching implementation to calculate the disparity image.
  • Parameters have changed to more closely follow OpenCV's options.
  • Publishing floating-point disparity image.
  • No longer publishing image_disparity, use stereo_view for visualization instead.
  • REMOVED deprecated stereoproc node and other obsolete files.

image_view:

  • stereo_view shows color-mapped disparity image along with left/right.

stereo_msgs:

  • New definition of DisparityImage. Disparities are now floating-point, not fixed-point. Better comments.
  • REMOVED all deprecated messages (RawStereo, DisparityInfo, StereoInfo).
  • Added split_rawstereo.py script to convert RawStereo bags to Image & CameraInfo bags.

camera_calibration:

  • GUI improvements.

Download

laser_drivers 0.3.0 released

| No Comments | No TrackBacks

laser_drivers.png

laser_drivers 0.3.0 has been released. This release is intended to test final changes in anticipation of an upcoming 1.0 release.

Changes

  • Adjusted messages so that the driver will not spew messages when it manages to open a device but fails to get all the way running.
  • Updated licenses and package/stack descriptions.
  • Removed the node description from doxygen.

Download

visualization 0.5.0

| No Comments | No TrackBacks

visualization.png

visualization 0.5.0 has been released. This release includes the new rxbag_plugins package, which provides visualization plugins for the new-in-ROS-0.11 rxbag tool, as well as a number of rviz bugfixes.

Changes

  • Fixed crash when loading old configs that had a top-down orthographic view (r26030, #3358)
  • Fixed Marker display memory leak which caused rviz to constantly increase in memory usage in certain situations (r26166, #3364)
  • Now validates input messages and discards those with nans/infs (r26286, #3360)
  • Fixed "Panels" menu checkboxes to be correct at startup instead of all-checked (r26611)
  • Fixed crash caused by laser scans/point clouds arriving in their separate thread and accidentally causing a GUI change in that thread instead of the GUI thread (r26639, #3422)
  • Added rxbag_plugins which contains message viewer plugins for the rxbag visualization tool

Download

Stack 1.0 Releases and Distributions

| No Comments | No TrackBacks

Box Turtle

In the coming weeks, there will be a flurry of 1.0 stack releases. The first of these are common 1.0, common_msgs 1.0, physics_ode, sound_drivers 1.0 and visualization_common 1.0.

We are making these releases in advance of our first ROS "Distribution" (Box Turtle), which will package our stable stacks together. Much like a Linux distribution (e.g. Ubuntu's Karmic Koala), the software stacks in the distribution will have a stable set of APIs for developers to build upon. We will release patch updates into the distribution, but otherwise keep these stacks stable. We've heard the needs from the community for a stable version of libraries to build upon, whether it be for research lab setups or classroom teaching, and we hope that these well-documented and well-tested distributions will fit that need. We will separately continue work on development of new features so that subsequent distributions will have exciting new capabilities to try out.

We're very excited to be nearing the end of our milestone 3 process. These 1.0 releases represent several months of coding, user testing, and documentation, so that the ROS community can use a broad set of stable robotics libraries to build upon. We appreciate the many contributions the community has made to these releases, from code, to bug reports, to participating in user tests. These releases also build upon many thirdparty robotics-related open source libraries.

For these releases, you will find links to "releases" and "change list", where you can find information about downloading these releases as well as information on what has changed:

Links to download/SVN tags

Change Lists

In most cases, the 1.0 releases will only contain minor updates from previous releases.

NOTE: not every stack in the final distribution will attain 1.0 status. We are reserving the 1.0 label for libraries that we believe to be the most mature and stable.

-- your friendly neighborhood ROS team

ROS 0.11 Released

| No Comments | No TrackBacks

ROS 0.11

ROS 0.11 has been released! ROS 0.11 includes many of the final features and API modifications that we wish to have in place for ROS 1.0. Our focus with this release was on improving consistency, better performance, and bug fixes. We are also removing much of the deprecated functionality with this release so that ROS 1.0 will have minimal deprecated functionality.

Some of the major updates in this release include new "wait for message" API routines in roscpp and rospy, bash tab-completion for most command-line tools, improvement in Python-related startup latency, and streamlining of the service API in rospy.

There were many other changes with this release as we work to improve and finalize the ROS feature set. You can find a complete list in the changelist.

You can download a tarball of the release, though we recommend that you start with the ROS installation instructions instead.

Notes on Updating from 0.10 or earlier in SVN: There are a number of previously installed programs which are now versioned scripts. SVN will error when updating and not delete the installed programs to add the scripts in their place. You will need to delete the program and svn up again. The error will read:

svn: Failed to add file 'FILENAME': an unversioned file of the same name already exists

The solution is to rm FILENAME && svn up again.

Find this blog and more at planet.ros.org.


Please submit content to be reviewed by emailing ros-news@googlegroups.com.

About this Archive

This page is an archive of entries from January 2010 listed from newest to oldest.

December 2009 is the previous archive.

February 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.