July 20, 2017
[Meetup] An intro to ROS programming for robots in Cambridge

@YUHONG_LIN wrote:

[Meetup] An introduction to ROS programming for robots in Cambridge

Join here: http://meetu.ps/3bX2MP

Date: Tuesday, August 8, 2017
Time: 6:30 PM
Venue: Caffe Nero (11 Market St, Cambridge CB2 3PA, Cambridge)
Free Event

Dear Roboticists,

If you like robots and you want to learn how to program them, that is your Meetup!

ROS is becoming the standard in robot programming. So you must master ROS if you want to work in robotics in the close future.

Come to this MeetUp and find a very fast way to learn ROS!

You will need to bring your laptop since this is going to be a hands up tutorial. But don’t worry, you can bring any type of laptop. No installations required for the tutorial. All the programming will be done online.

Please come 10-15 minutes earlier to connect on the Internet and grab a nice Coffee!

================
If you cannot attend to this event you have the option to attend the course online: http://www.robotigniteacademy.com/ or watch the free video tutorials in YouTube.

================
For more info send an email to the host (Angelos) at a.plastropoulos@gmail.com

Posts: 1

Participants: 1

Read full topic

by @YUHONG_LIN on July 20, 2017 08:22 AM

July 19, 2017
Jade EOL Announcement

@wjwwood wrote:

Now that ROS Lunar is out, it’s time for us to start shutting down our services for ROS Jade.

We’re already past the EOL date for Jade, but we’ve been busy with the Lunar release and other projects so we wanted to wait for things to settle down before starting to shutdown Jade.

What this means for everyone:

  • There will only be one more chance to release packages into Jade
    • This will happen in about two weeks unless we run into regressions or someone asks for more time
  • After we shutdown the Jade part of the build farm there will be no additional updates to Jade

Some other details of interest:

  • We will only do more Jade syncs after that iff critical bugs are discovered before we shutdown the Jade part of the build farm
    • There will be a short period between the last sync and shutting down the build farm where we can test Jade and make sure there are no blocking issues
  • After the last sync we will also:
    • stop taking new releases in ros/rosdistro for jade
    • stop building new binary packages for Jade
    • stop running devel jobs, pr jobs, and doc jobs for Jade
  • The existing Jade binaries and documentation will continue to be available

If you’re still using Jade you need to consider moving to one of the other ROS releases:

  • ROS Lunar (latest)
  • ROS Kinetic (latest LTS)
  • ROS Indigo (older LTS, older than Jade)

After this post, I’ll be making announcements and updates in the “Release and Package Maintenance” category here on discourse:

So be sure to check that out if you’re interested in updates on this.

Posts: 1

Participants: 1

Read full topic

by @wjwwood William Woodall on July 19, 2017 02:11 AM

July 12, 2017
A Dummy’s Guide to Debugging ROS Systems.

So you’ve written the ultimate ROS program: after thousands of lines of code your robot will finally achieve sentience and bring about the singularity!

One by one you launch your nodes. Each one bringing the Apocalypse ever closer. You hit enter on the last command. And. And, nothing happens. What went wrong? How will you find, and forever squash that bug that prevented your moment of triumph? This blog attempts to answer those questions, and more*.

At BLUEsat we’ve had our share of complicated ROS debugging problems. The best ones happen when you are half-way through a competition task, with time ticking on the clock. Although this article will also look at the more common situation of debugging in a less time pressured, and fire prone environment**.

Below are several tools and techniques that we have successfully deployed to debug our ROS environment.

Keep Calm And … FIRE!

You’ve probably heard this before but its very important when debugging to not jump to conclusions or apply fixes you haven’t tested properly. Google for example has a policy of rolling back changes on its services rather than trying to push a fix. A similar idea applies in a competition or time pressured situation: make sure you have thought through that patch that removes the “don’t kill humans” safety from your robot!  That being said, unfortunately a roll back is unlikely to be applicable in a competition situation, nor is it likely to be able to put out that fire you just started on your robot. So we can’t just copy Google, but we should think about what we are doing before we do it.

Basically any patches or configuration fixes you apply during such a situation is a calculated risk, and you should make sure you understand those risks before you do something. During the European Rover Challenge last year I found it was possible to tweak small settings, restart certain nodes, and re-calibrate systems; but it was too risky to power cycle the rover during a task due to the time it took to establish communication. Likewise restarting our drive systems or cameras was very disruptive to our pilot, so could only be done in certain situations where the damage done by not fixing the system could be worse. That being said, after a critical camera failed we did attempt to programmatically power cycle that device – the decision being that the camera was important enough to attempt such a risky move. (In the end we weren’t able to do this during the task, and our pilot managed to navigate the rover without the camera in question.)

In a non time pressured situation you can be more flexible. It is possible to test different options and see if they work. That is provided they don’t damage your robot. However a structured approach is often beneficial for those more complicated bugs. I often find that when I’m debugging an intermittent or difficult to detect problem that it is easy to end up lose track of what I’ve tried, or get results mixed up. A technique I’ve found to be very useful was to record what I was doing as I did it, especially if the problem includes sensor data. We had a number of problems with our Rover’s steering system when we first implemented our swerve drive and I found writing down ADC values and rotation readings in different situations really helped debug it (You can read more about how we use ADC’s in our steering system in one of our previous articles).

Basically the main point is too keep your head clear, and think through the consequences before you act. Know the risks and have your E-Stop button ready! Now lets look at some tools you can use to aid you in your debugging.

The BLUEtongue 2.0 Rover being debugged during the 2016 ERC, with Team Members Assisting. (LTR): Timothy Chin, Sebastian Holzapfel, Simon Ireland, Nuno Das Neves, Harry J.E Day.Debugging is often a team effort.

Grab Your RQT

The handy “rqt” tool is a ROS debugger’s Swiss Army Knife. It’s saved me many times during both time pressured, and non time pressured debugging. During the 2016 European Rover Challenge it was my constant companion at the debugging station, providing many useful insights and a lot of useful diagnostic data. (A standard BLUEsat rover driving crew consists of a pilot – who drives the rover; a co-pilot – who keeps track of task goals, the rovers position, and manages communication to the pilot; and a debugger who monitors the state of the rover’s software and manages the different running ROS nodes).

RQT is run using the “rqt” command in the terminal, and contains a range of widgets that can be loaded through the Plugins menu. Below I’ll give a brief tutorial on some of it’s must useful widgets.

The Node Graph

The first tool in RQT’s arsenal is the Node Graph.  This widget depicts all the nodes in your ROS graph as ovals and all of your topics as squares. Directional arrows indicate which nodes are advertising or subscribing to a topic. You can also choose to only show topics that are currently connected to both a publisher and subscriber (active), or to only display nodes without displaying topic information.

Picture display's RQT's graph view displays all the active nodes with lines connection topics to nodes.RQT’s graph view displays all the active nodes and the topics that connect them.

 

When I start debugging a ROS problem the node graph is one of the first things I look at. With a glance I can see which nodes are running, and if two nodes are connected correctly. Its amazing how often a ROS problem can be as simple as a node that isn’t running (or is running when it shouldn’t be). The graph also allows us to see if nodes are connected correctly – a misspelled topic name certainly doesn’t jump out at you in code, but its immediately obvious as a missing link in the graph.

The Topic Monitor

If we can’t find our problem using the Node Graph than this next widget will often help. The Topic Monitor is the younger, better organised sibling of the rostopic echo command line tool. It displays a list of all currently advertised topics, and allows you to monitor them. Besides each topic is a checkbox, which when checked subscribe’s us to that topic, displaying its full output as well as the bandwidth it’s using and the frequency it’s being published at.

The RQT Topic Monitor displaying output from the /diagnostics topic.RQT’s Topic Monitor Widget: You can see the list of topics, as well as output from selected topics.

 

This is extremely useful for checking that the correct information is travelling through your ROS network without having to add ROS_INFO debugs in all your nodes. On the BLUEtongue Rover we publish a lot of diagnostic information as ROS topics (a bit more about that here). Some of it is used to provide information to our pilot via the GUI, but if we need to get into the nitty gritty details then RQT can provide a massive wealth of information.

In addition to diagnostic information the topic monitor can be used to find problems in your network. A common case of this is a node that isn’t actually publishing any messages – in which case it may not be connected properly and you should take a look at the ROSWTF section. You can also see if a node is publishing the wrong message type, or if any values are incorrect.

Finally you can also use the topic monitor to identify potential bandwidth problems, although you should remember when doing this that rqt will subscribe to the topic itself, which may exacerbate the issue.

The Message Publisher

The RQT Message Publisher is the Topic Monitor’s evil twin. As the name implies it allows you to publish messages, providing very similar functionality to the command line rostopic pub command – you can select a topic, message type and frequency and then enter the data you want to send. However it also provides some additional visual aids that speed up the debugging process.

The ROS Message Publisher, with examples of a number of different expression types.The ROS Message Publisher, with examples of a number of different expression types

 

Firstly it pre-populates a list of topics and a corresponding list of types, allowing you to very quickly publish to any subscriber currently in the network. This can be a life saver under stress, and prevents you from having to constantly remind yourself if that cmd_vel message is a geometry_msgs/Twist  or a geometry_msgs/TwistStamped. 

Once you have selected the message type, it will also display the fields of that message, making it much simpler to fill out those more complicated messages. It also remembers messages you have previously sent, allowing you to quickly resend them. This can be great if you need to do something like send a specific set of messages, or quickly enable a message after an event has occurred.

Finally, if you are a power user or need to send a more complicated message you can enter valid python expressions into the “expression” field, rather than actual values. This includes any method in the time, math or random modules. In addition it provides you with an automatic counter i (see the above image for examples).

The TF Tree

The final tool I’m going to talk about in our RQT debugging arsenal is the TF Tree. The tool is useful if you are using ROS’s transform system, if not you may want to skip over this section.

The TF tree displays the connection structure of your transforms, as well as which node is publishing a given frame, the last time it was updated, and the oldest transform in the system.

The RQT TF Tree, displaying the link between base_footprint and base_link.The TF Tree shows the relation between different frames in the ROS Transform Tree.

 

The best use I’ve had for this is detecting gaps in the graph. For example ROS’s robot_state_publisher won’t publish a transform for a non-fixed joint if you haven’t published any information to joint_states about it, which can lead to unreachable transforms. If something like this happens the best approach is often to go back and check to make sure whichever node is supposed to be publishing a transform is functioning correctly. It is also useful for identifying the cause of transform timeouts by looking at the average rate and most recent transform values.

Find Yourself with RViz

RQT is an amazing tool for general day-to-day debugging, however if you are dealing with very visual information such as point clouds or where your software thinks the different parts of your robot are then something more powerful is needed. That is where RViz comes in, it is a 3D scene where you can visualise different types of ROS data. As well as URDF robot models, RViz supports point clouds, occupancy grids, and much more. Basically if the topic you want to visualise is part of ros-desktop, then you can probably see it in RViz.  (Note: if you really want to use RQT for everything you can use RViz as an RQT plugin).

An RViz scene displaying the URDF model of the BLUEtongue Rover. A LIDAR input and an empty occupancy grid.An RViz scene displaying the URDF model of the BLUEtongue Rover, a LIDAR input, and an empty occupancy grid.

 

RViz actually has some reasonable tutorials on the ROS Wiki, so I’m just going to give the Cliff’s Notes here. The key feature of RViz is its ability to load in different ROS messages and visualise them relative to each other. This is useful if you are trying to debug anything to do with localisation or automation as you can quickly work out if you robot thinks it is in the wrong place, or is having problems with sensor data. As an example of RViz’s versatility, we made use of it during the 2016 European Rover Challenge’s “Blind Navigation” task to display a single plane of LIDAR data relative to the rover’s estimated position (camera feeds or full 3D sensor visualisation was forbidden during this task).  We also used it extensively to debug LIDAR sensor input (see below), and various SLAM solutions.

An example of using rviz to display LIDAR, TF and Robot Model Data

 

ROSWTF!

If you are having weird connection issues or nodes that otherwise seem to be functioning properly then the roswtf tool is your guy/gal. Basically ROSWTF is designed to be your one stop shop for identifying issues in your ROS system, although my experience is that it’s not quite there yet. What it is really good for however is detecting any setup or networking issues with your ROS network.

ROSWTF being run in a terminal session where the ROS_IP environment variable is misconfigured. ROSWTF being run in a terminal session where the ROS_IP environment variable is misconfigured.

 

One such issue is machines on your ROS Network not being able to recognise each other’s host names. This can happen if you don’t have something like DHCP or DNS sharing them between machines, or if your machine’s DNS name does not match what local programs think your host name is. This is a difficult problem to detect, because nodes will often connect and run correctly until they try and communicate with a node on a different machine. ROSWTF will detect this hard to find problem.

In most cases there are two ways to fix this, the first is configuring your local machine’s ROS_HOST environment variables to be their IP addresses, and the second is fixing your hostname resolution so that machines can find each other. The latter can be done by adding entries to your /etc/hosts file or updating your local DNS server. At BLUEsat we tend to use the environment variable option as our network setup often means we don’t use DHCP, and having hosts know their own ip means we don’t have to update /etc/hosts on every machine in our network anytime we add a new host.

Other problems that roswtf can detect are: misconfigured ROS_MASTER nodes, actual network problems, and ros launch file configuration problems. If everything looks like it should be working, but isn’t, roswtf is the tool for the job!

Dig Deeper with GDB and Valgrind

Needless to say at this point if you have gone through the other steps and your robot is still on fire, you probably don’t have very much robot left. GDB and Valgrind are tools best left for initial testing and development, however when your robot is not on fire they can be very useful.

Both of these tools are topics in themselves and I recommend that you read full tutorials on the individual tools (gdb, valgrind) to get a good understanding of them. Here we will primarily cover how you use both these tools in a ROS environment.

In order to use either of these tools effectively you must first recompile your code with debugging symbols. This allows the tools to give you information about line numbers, and snippets of code where errors may be occurring. To recompile a catkin workspace with debugging symbols enabled you can run the following command.

$ catkin_make -DCMAKE_BUILD_TYPE=Debug
[Catkin Output Goes Here] 

The second difficulty is actually locating the executable to run it using gdb or valgrind (you can’t just run gdb on rosrun unfortunately). If you are in the root of your catkin workspace then the executable should be located in devel/lib/<ros package name>/<node name>. That means you can run a node with gdb using the following command:

$ gdb devel/lib/[ros_package_name]/[node_name] 

You can then step through your program as you normal would in gdb. Likewise you can run valgrind with the following command:

$ valgrind --leak-check=yes devel/lib/[ros_package_name]/[node_name] 

I find that I tend to use gdb when I am trying to debug segfaults, weird outputs or unexpected behaviour; whilst I use valgrind almost exclusively for finding memory leaks and array overflows. They are certainly key tools for debugging C++ code and I highly recommend you read more about them!

Now Go Get that Singularity!

All these tools have been of great use to me during my time at BLUEsat, especially during the European Rover Challenge tasks. I hope you find them helpful next time you are trying to create the singularity, or even when you are just debugging normal ROS code. If not, what’s here only scrapes the surface of what you can do with many of these tools and I encourage the reader to experiment and dive deeper into all of them!

The BLUEtongue 2.0 Mars Rover during the "Assistance Task" at the European Rover Challenge 2016Once you have finished debugging your robot you can go out and take over the world!

 


* BLUEsat UNSW and its members (mostly) do not endorse the bringing about of the apocalypse, and wave all responsibility for any death or planet-wide calamity that may occur as the result of apocalypse related debugging.

** Debugging techniques in this article not guaranteed to be safe for application during a fire. BLUEsat recommends liberal use of E-Stop systems. 

by Harry J.E Day on July 12, 2017 08:00 AM

July 11, 2017
ROSCon 2017: Program posted

The results are in, and the ROSCon 2017 program has been posted!

This year saw a record response from the community, with 107 proposals submitted. Following discussion and tough decision-making among the Program Committee, we decided to accept 38 proposals for presentation (35.5% acceptance rate).

In recent years we made room in the program for 20-25 presentations, in a mixture of long (~40-minute) and medium (~20-minute) durations. This year, given the large number of high-quality proposals that were submitted, we're trying something new, which is to add a category for short presentations, at 5 minutes each. These slots will allow the presenters to briefly introduce their work and entice the audience to follow up in person to learn more.

To encourage those in-person interactions, we're adding another new feature this year, which is a poster session wherein attendees can find and discuss with the presenters the work that most piqued their interest. The poster session will be held at the end of the first day, during the first half of the reception.

In exchange for these additions to the program, this year we will not be holding the customary birds of a feather (BoF) sessions. While those ad hoc meetings were fun and lively in the early years, as the conference has grown it has become harder to keep them useful to a broad audience, and we've seen participation dropping in recent years. As always, we're experimenting to find the best program mix for the community, and we look forward to getting your feedback on this year's lineup.

We hope to see you in Vancouver for ROSCon in September! As a reminder, the deadline for early registration is August 1. Register today.

-- Your friendly neighborhood ROSCon 2017 Organizing Committee

Thank you to our Platinum Sponsor: Intel! Thank you to our Gold Sponsors: Clearpath, Erle, Fetch, Gaitech, Locus, and Rapyuta!

by Tully Foote on July 11, 2017 06:11 PM

Mirko Bordignon et al. ROS-Industrial turns four and expands worldwide

Looking foward to ROSCon 2017 we're highlighting presentations from last year. The ROSCon 2017 registration is currently open.

presented

Mirko Bordignon (Fraunhofer IPA) Min Ling (ARTC - A*STAR) Shaun Edwards (Southwest Research Institute) present the state of ROS-Industrial as it turns 4 years old and expands to add an Asia-Pacific chapter.

Video

Abstract

Four years after it was first launched by Shaun Edwards, ROS-Industrial is now a worldwide effort to expand and improve ROS adoption in manufacturing environments and industrial equipment. As an initiative, it is supported financially by OEMs and system integrators, whose interests are represented and requests are collected within three ROS-Industrial Consortia managed by non-profit, applied research institutions. As a software platform, it is developed by a free and open community gathering in monthly meetings and operating through a federated development model, much like the ROS developers community. The talk will showcase real-world examples and current efforts to expand the initiative and to continue addressing technical and non-technical concerns.

Slides

View the slides here

by Tully Foote on July 11, 2017 02:05 AM

July 07, 2017
[Meetup] Let's see how a Barista Robot serves coffee

@YUHONG_LIN wrote:

Dear Roboticists,

We are very pleased to invite you to the release conference and demonstration of Barista robot which is the first robot serving coffee to the tables in the world.

Barista Robot website: http://www.theconstructsim.com/robot-barista-serving-coffee/
RSVP: http://meetu.ps/3bFnKZ

The Barista robot was created by two students from the Institut La Guineueta and the company The Construct with the support of Costa Coffee (Barcelona).

In July the 12th, we will share this exciting moment: a release conference and demonstration of Barista robot. The event will be taking place in Barcelona, we sincerely welcome people from all walks of life to come to this event.

Date&Venue

  • Wednesday, 12 July, 2017
  • 5:00 PM
  • Gran Via de les Corts Catalanes, 622, 08007 Barcelona, Spain

Event Schedule

  • 17:00 to 17:10 Presentation of the design idea and construction process
  • 17:10 to 17:30 Demonstration of Barista serving coffee in the coffee shop.
  • 17:30 to 18:00 Question and answer.

--
Contact Us:
You can contact us with questions and doubts here: info@theconstructsim.com

Posts: 1

Participants: 1

Read full topic

by @YUHONG_LIN on July 07, 2017 07:23 AM

July 06, 2017
Visual Studio Code ROS Extension

@ajshort wrote:

Hey all,

I have released the first version of my ROS visual studio code extension. It's still in early stages, but has a few features to help make ROS development easier:

  • Automatic ROS environment configuration.
  • Highlighting for common ROS files.
  • Create catkin packages.
  • Start and stop the master, and view status.
  • Run catkin_make, rosrun and roslaunch from inside the editor.

You can install the extension using ext install ros, or see the README file for more details. Feedback and contributions are very welcome!

Posts: 1

Participants: 1

Read full topic

by @ajshort Andrew Short on July 06, 2017 12:51 AM

July 05, 2017
ROS 2 Beta 2 Released

@dirk-thomas wrote:

We're happy to announce the release of ROS 2 Beta 2, codename R2B2!

Installation instructions and tutorials can be found on the ROS 2 wiki.

To get an idea of what's in (and what's not in) this release, be sure to read the Beta 2 overview page.

One of the features we would like to highlight in this release is the support of the DDS-Security specification in the core of ROS 2 (see the sros2 repo for more information).

In an effort to use ROS 2 on a real robot (to gain real world experience) we have been working on a set of Turtlebot 2 demos which only use ROS 2 on the robot. Please checkout the demo repository.

As the "beta" qualifier suggests, this release of ROS 2 is not complete. However, we consider it to the point now where many things are ready for feedback from a broader audience, hence the label "beta" instead of "alpha". That being said, you should not expect to switch from ROS 1 to ROS 2 right now, nor should you expect to build a complete robot control system with ROS 2. Rather, you should expect to try out some demos, explore the code, participate in online discussions, and perhaps write your own demos.

As always, we invite you to try out the new software, give feedback, report bugs, and suggest features (and contribute code!): https://github.com/ros2/ros2/wiki/Contact

Your friendly neighborhood ROS 2 Team

Posts: 1

Participants: 1

Read full topic

by @dirk-thomas Dirk Thomas on July 05, 2017 11:11 PM

Workshop on Teaching ROS

@YUHONG_LIN wrote:


Workshop on Teaching ROS
21 JULY | Barcelona


Dear Roboticists,

We are very pleased to announce the full day Workshop on Teaching ROS to be held in Barcelona on Friday, July 21, 2017.

Workshop URL: http://www.theconstructsim.com/workshop-on-teaching-ros/

-------------------------------AIMS & SCOPE-------------------------------
ROS is becoming the standard of robot programming, and it is growing faster than ever. But teaching ROS to students can be a daunting process. Even if there are many good tutorials around, the novelty of the concepts makes it hard for students.

The aim of this one-day workshop is to show you how to change your classes from passive listening to active practising. Move away from a slides based teaching method to a notebook based one, where direct interaction with robots is embedded in the method itself.

------------------------Workshop Topics Include-------------------------
- The theory behind the method
- How to manually implement the theory for your own courses
- How to use an already working system online

-----------------------------Who Should Attend-----------------------------
Teachers who may need to prepare a syllabus for a summer ROS course, for a future semester, or for a robotics programming course.
We are not going to teach ROS but how to teach ROS for fast learning

-----------------------------Workshop Schedule-----------------------------
*21 July, 2017
- 09:30 to 11:30: The theory behind the method
- 11:30 to 13:30: How to manually implement the theory for your own courses
- 13:30 to 14:30:Lunch Time
- 14:30 to 16:30: How to use an already working system online

-----------------------------Workshop Organizer----------------------------
RICARDO TÉLLEZ, Ph.D.

To assist us in planning, pre-registration is required.
Pre-registration: http://www.theconstructsim.com/workshop-on-teaching-ros/


Contact Us:
You can contact us with questions and doubts here: info@theconstructsim.com

Posts: 1

Participants: 1

Read full topic

by @YUHONG_LIN on July 05, 2017 05:09 PM

ARIAC Finals results announced

@dhood wrote:

We are happy to announce the final results of the Agile Robotics for Industrial Automation Competition (ARIAC).

ARIAC is a simulation-based competition designed to promote agility in industrial robot systems by utilizing the latest advances in artificial intelligence and robot planning. The goal is to enable industrial robots on the shop floors to be more productive, more autonomous, and more responsive to the needs of shop floor workers. The virtual nature of the competition enabled participation of teams affiliated with companies and research institutions from across three continents.

While autonomously completing pick-and-place kit assembly tasks, teams were presented with various agility challenges developed based on input from industry representatives. These challenges include failing suction grippers, notification of faulty parts, and reception of high-priority orders that would prompt teams to decide whether or not to reuse existing in-progress kits.

Teams had control over their system’s suite of sensors positioned throughout the workcell, made up of laser scanners, intelligent vision sensors, quality control sensors and interruptible photoelectric break-beams. Each team participating in the finals chose a unique sensor configuration with varying associated costs and impact on the team’s strategy.

The diversity in the teams’ strategies and the impact of their sensor configurations can be seen in the video of highlights from the finals:

Scoring was performed based on a combination of performance, efficiency and cost metrics over 15 trials. The overall standings of the top teams are as follows.

First place: Realization of Robotics Systems, Center for Advanced Manufacturing, University of Southern California

Second place: FIGMENT, Pernambuco Federal Institute of Education, Science, and Technology / Federal University of Pernambuco

Third place: TeamCase, Case Western Reserve University

Top-performing teams will be presenting at IROS 2017 in Vancouver, Canada in a workshop held on Sunday, September 24th. Details for interested parties are available at https://www.nist.gov/el/intelligent-systems-division-73500/agile-robotics-industrial-automation-competition-ariac

The IROS workshop is open to all, even those that did not compete. In addition to having presentations about approaches used in the competition, we will also be exploring plans for future competitions. If you would like to give a presentation about agility challenges you would like to see in future competitions, please contact Craig Schlenoff (craig.schlenoff@nist.gov).

Congratulations to all teams that participated in the competition. We look forward to seeing you in Vancouver!

Posts: 1

Participants: 1

Read full topic

by @dhood dhood on July 05, 2017 11:01 AM

July 03, 2017
Alejandro Hernández et al. (Erle Robotics) The robot_blockly package: programming ROS with blocks

Looking foward to ROSCon 2017 we're highlighting presentations from last year. The ROSCon 2017 registration is currently open.

In this session Alejandro presents robot_blockly as an approach to make programming robots more accessible.

Video

Abstract

robot_blockly is a ROS package that allows users to create ROS-based algorithms and behaviors, abstracting its complexity using blocks. The aim of the package is to hide the complexity of programming robots via functional blocks. As a rule of thumb, an average PhD student takes 3 weeks to learn ROS. This makes ROS programming not accessible for the great majority. The robot_blockly package aims to simplify the process of using ROS to the point of putting conceptual blocks together.

Slides

View the slides here

by Tully Foote on July 03, 2017 06:23 PM

ROSCon 2017 Diversity Scholarships

The ROSCon 2017 organizing committee aims for ROSCon to represent the entire ROS community, which is diverse and global. In addition to promoting technology that is open source, we also strive to ensure that our communities themselves are as open and accessible as possible, since we recognize that diversity benefits the ROS ecosystem as a whole.

Whoever you are, whatever you do, and wherever you do it, if you're interested in ROS, then we want you to join us at ROSCon. To help reduce the financial barriers to conference attendance, the ROSCon organizing committee is offering a number of scholarships to members of traditionally underrepresented groups in the tech community. Thanks to the support of the program's sponsors, these scholarships each include a complimentary conference registration pass and three nights' accommodation shared with another recipient*. Limited travel support is available for participants whose travel to the conference would otherwise be infeasible. Please note that all other expenses (including any visa requirements) will be the responsibility of the participant.

*To maximize the impact of the scholarship funds, scholarship recipients will be asked to share a room with another recipient. Under special circumstances alternative arrangements can be accommodated.

Eligibility

We invite applications from members of groups that have been traditionally underrepresented in the tech community (including but not limited to: women, LGBTQ+, people of color, people with disabilities, and people from ethnic minorities in their country of residence), who may not otherwise be able to attend ROSCon. Previous ROSCon Diversity Scholarship recipients are not eligible to re-apply.

Sponsors

The ROSCon 2017 Diversity Program has been made possible with support from the following sponsors:

Fetch.png

nvidia.png

openrobotics-logo-stacked.png

rapyuta.png

If your organization is interested in getting involved in the Diversity Program, please get in contact.

How to apply

To apply, fill out this form by June 25, describing how you are involved with ROS and the robotics community and what you hope to get out of attending ROSCon. Scholarships will be awarded based on a combination of need and impact. Every applicant will be notified of the outcome of their application.

For more information about ROSCon 2017, including the program, code of conduct, and childcare options, please see http://roscon.ros.org/2017

by Tully Foote on July 03, 2017 06:00 PM

GPD: a ROS Package for Grasping Novel Objects

@atenpas wrote:

Dear colleagues,

We have just released our latest grasp detection software as a ROS package:

http://www.ccs.neu.edu/research/helpinghands/code.html

git page: https://github.com/atenpas/gpd

video:

The software is an easy-to-use package for grasping novel objects. Given a point cloud, the package detects 6-DOF grasp poses for a 2-finger grasp (e.g., a parallel jaw gripper). It works both on isolated objects and in densely cluttered scenes, and it has already been deployed on various platforms, including a UR5, Baxter, HSR, ...

Features:

  • No object models required
  • No object segmentation required
  • No training required
  • Grasp poses are 6-DOF (allows a variety of grasp approach directions)
  • Can use any point cloud (better point clouds results in better performance)
  • Visualization in rviz or pcl

Requirements:

  • RGBD camera, Nvidia graphics card with CUDA
  • Caffe, PCL 1.7 or higher, Eigen
  • Ubuntu 14.04 with ROS Indigo or Ubuntu 16.04 with ROS Kinetic

Check it out!

Andreas ten Pas and Rob Platt
Helping Hands Lab
College of Computer and Information Science
Northeastern University

Posts: 1

Participants: 1

Read full topic

by @atenpas Andreas ten Pas on July 03, 2017 03:29 PM

July 02, 2017
New Packages for Lunar 2017-07-02

@marguedas wrote:

We're happy to announce new packages for ROS Lunnar Loggerhead. This includes 79 new packages as well as updates for 71 packages.
As always thanks to all the maintainers and contributors who have made this possible!

Here are the details:

Package Updates for lunar

Added Packages [79]:

  • ros-lunar-actionlib-lisp: 0.2.9-0
  • ros-lunar-cartesian-msgs: 0.0.3-0
  • ros-lunar-cl-tf: 0.2.9-0
  • ros-lunar-cl-tf2: 0.2.9-0
  • ros-lunar-cl-transforms: 0.2.9-0
  • ros-lunar-cl-transforms-stamped: 0.2.9-0
  • ros-lunar-cl-urdf: 0.2.9-0
  • ros-lunar-cl-utils: 0.2.9-0
  • ros-lunar-executive-smach-visualization: 2.0.1-0
  • ros-lunar-graph-msgs: 0.1.0-0
  • ros-lunar-innok-heros-driver: 1.0.3-0
  • ros-lunar-interactive-marker-twist-server: 1.2.0-0
  • ros-lunar-interactive-marker-twist-server-dbgsym: 1.2.0-0
  • ros-lunar-iot-bridge: 0.9.0-0
  • ros-lunar-jsk-common-msgs: 4.2.0-0
  • ros-lunar-jsk-footstep-msgs: 4.2.0-0
  • ros-lunar-jsk-gui-msgs: 4.2.0-0
  • ros-lunar-jsk-hark-msgs: 4.2.0-0
  • ros-lunar-marti-data-structures: 0.3.0-0
  • ros-lunar-moveit-sim-controller: 0.1.0-0
  • ros-lunar-moveit-sim-controller-dbgsym: 0.1.0-0
  • ros-lunar-moveit-visual-tools: 3.3.0-0
  • ros-lunar-moveit-visual-tools-dbgsym: 3.3.0-0
  • ros-lunar-plotjuggler: 1.1.1-0
  • ros-lunar-plotjuggler-dbgsym: 1.1.1-0
  • ros-lunar-posedetection-msgs: 4.2.0-0
  • ros-lunar-posedetection-msgs-dbgsym: 4.2.0-0
  • ros-lunar-ros-control-boilerplate: 0.4.1-0
  • ros-lunar-ros-control-boilerplate-dbgsym: 0.4.1-0
  • ros-lunar-ros-type-introspection: 0.6.3-0
  • ros-lunar-ros-type-introspection-dbgsym: 0.6.3-0
  • ros-lunar-roslisp-common: 0.2.9-0
  • ros-lunar-roslisp-utilities: 0.2.9-0
  • ros-lunar-rosparam-shortcuts: 0.2.1-0
  • ros-lunar-rosparam-shortcuts-dbgsym: 0.2.1-0
  • ros-lunar-rviz-visual-tools: 3.4.1-0
  • ros-lunar-rviz-visual-tools-dbgsym: 3.4.1-0
  • ros-lunar-smach-viewer: 2.0.1-0
  • ros-lunar-speech-recognition-msgs: 4.2.0-0
  • ros-lunar-swri-console-util: 0.3.0-0
  • ros-lunar-swri-console-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-geometry-util: 0.3.0-0
  • ros-lunar-swri-geometry-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-image-util: 0.3.0-0
  • ros-lunar-swri-image-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-math-util: 0.3.0-0
  • ros-lunar-swri-math-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-nodelet: 0.3.0-0
  • ros-lunar-swri-opencv-util: 0.3.0-0
  • ros-lunar-swri-opencv-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-prefix-tools: 0.3.0-0
  • ros-lunar-swri-roscpp: 0.3.0-0
  • ros-lunar-swri-roscpp-dbgsym: 0.3.0-0
  • ros-lunar-swri-rospy: 0.3.0-0
  • ros-lunar-swri-route-util: 0.3.0-0
  • ros-lunar-swri-route-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-serial-util: 0.3.0-0
  • ros-lunar-swri-serial-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-string-util: 0.3.0-0
  • ros-lunar-swri-string-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-system-util: 0.3.0-0
  • ros-lunar-swri-system-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-transform-util: 0.3.0-0
  • ros-lunar-swri-transform-util-dbgsym: 0.3.0-0
  • ros-lunar-swri-yaml-util: 0.3.0-0
  • ros-lunar-swri-yaml-util-dbgsym: 0.3.0-0
  • ros-lunar-vision-visp: 0.10.0-1
  • ros-lunar-visp: 3.0.1-2
  • ros-lunar-visp-auto-tracker: 0.10.0-1
  • ros-lunar-visp-auto-tracker-dbgsym: 0.10.0-1
  • ros-lunar-visp-bridge: 0.10.0-1
  • ros-lunar-visp-bridge-dbgsym: 0.10.0-1
  • ros-lunar-visp-camera-calibration: 0.10.0-1
  • ros-lunar-visp-camera-calibration-dbgsym: 0.10.0-1
  • ros-lunar-visp-dbgsym: 3.0.1-2
  • ros-lunar-visp-hand2eye-calibration: 0.10.0-1
  • ros-lunar-visp-hand2eye-calibration-dbgsym: 0.10.0-1
  • ros-lunar-visp-tracker: 0.10.0-1
  • ros-lunar-visp-tracker-dbgsym: 0.10.0-1

Updated Packages [71]:

  • ros-lunar-collada-parser: 1.12.9-0 -> 1.12.10-2
  • ros-lunar-collada-parser-dbgsym: 1.12.9-0 -> 1.12.10-2
  • ros-lunar-collada-urdf: 1.12.9-0 -> 1.12.10-2
  • ros-lunar-collada-urdf-dbgsym: 1.12.9-0 -> 1.12.10-2
  • ros-lunar-combined-robot-hw: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-combined-robot-hw-dbgsym: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-combined-robot-hw-tests: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-combined-robot-hw-tests-dbgsym: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-interface: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-manager: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-manager-dbgsym: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-manager-msgs: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-manager-tests: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-controller-manager-tests-dbgsym: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-hardware-interface: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-joint-limits-interface: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-joint-state-publisher: 1.12.9-0 -> 1.12.11-0
  • ros-lunar-libphidget21: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-libphidget21-dbgsym: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-moveit-commander: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-controller-manager-example: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-controller-manager-example-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-core: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-core-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-fake-controller-manager: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-fake-controller-manager-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-kinematics: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-kinematics-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-planners: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-planners-ompl: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-planners-ompl-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-plugins: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-benchmarks: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-benchmarks-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-control-interface: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-control-interface-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-manipulation: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-manipulation-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-move-group: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-move-group-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-perception: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-perception-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-planning: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-planning-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-planning-interface: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-planning-interface-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-robot-interaction: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-robot-interaction-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-visualization: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-visualization-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-warehouse: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-ros-warehouse-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-runtime: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-simple-controller-manager: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-moveit-simple-controller-manager-dbgsym: 0.9.7-0 -> 0.9.8-0
  • ros-lunar-phidgets-api: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-phidgets-api-dbgsym: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-phidgets-drivers: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-phidgets-imu: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-phidgets-imu-dbgsym: 0.7.2-0 -> 0.7.3-0
  • ros-lunar-realtime-tools: 1.9.2-0 -> 1.10.0-0
  • ros-lunar-realtime-tools-dbgsym: 1.9.2-0 -> 1.10.0-0
  • ros-lunar-robot-model: 1.12.9-0 -> 1.12.11-0
  • ros-lunar-ros-control: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-rqt-controller-manager: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-transmission-interface: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-transmission-interface-dbgsym: 0.11.4-0 -> 0.11.5-0
  • ros-lunar-urdf: 1.12.9-0 -> 1.12.11-0
  • ros-lunar-urdf-dbgsym: 1.12.9-0 -> 1.12.11-0
  • ros-lunar-urdf-parser-plugin: 1.12.9-0 -> 1.12.11-0

Removed Packages [0]:

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

  • Adolfo Rodriguez Tsouroukdissian
  • Alwin Heerklotz
  • Chris Lalancette
  • Dave Coleman
  • Davide Faconti
  • Ed Venator
  • Elliot Johnson
  • Fabien Spindler
  • Georg Bartels
  • Ioan Sucan
  • Isaac I. Y. Saito
  • Jon Binney
  • Jonathan Bohren
  • KazutoMurase
  • Kei Okada
  • Kelsey Hawkins
  • Kris Kozak
  • Lorenz Moesenlechner
  • Marc Alban
  • Martin Guenther
  • Mathias Lüdtke
  • Michael Ferguson
  • Michael Görner
  • Mike Purvis
  • Ryohei Ueda
  • Shohei Fujii
  • Stuart Glaser
  • Toni Oliver
  • Yuki Furuta
  • mike

Posts: 1

Participants: 1

Read full topic

by @marguedas Mikael Arguedas on July 02, 2017 05:40 PM

Gapter EDU Pre-Order Offer

@Anis_Koubaa wrote:

Gapter EDU Pre-Order Offer

Gaitech is proud to announce a pre-order offer of Gapter EDU 2: a ready-to-fly drone for only 1000 USD with exceptional capabilities. This pre-order offer saves you 200 USD on the cost, and provide you a complete kit to start with.

Gapter EDU is a reliable drone designed for research and education and is a really complete framework to start working with drones in Robot Operating System (ROS) and also using DroneKit from 3DR to develop programs on the Ardupilot autopilot.

For more information and contact, refer to the flyers below:

For documentation and more information about Gapter, please refer to
http://edu.gaitech.hk/gapter/index.html

Posts: 1

Participants: 1

Read full topic

by @Anis_Koubaa Anis Koubaa on July 02, 2017 03:28 PM

July 01, 2017
New Packages for Kinetic 2017-07-01

@tfoote wrote:

We're happy to announce new packages for ROS Kinetic Kame. This includes 47 new packages as well as updates for 98 packages. There are two removed packages and we tracked one Debian Jessie specific regressions during this release cycle.

As always thanks to all the maintainers and contributors who have made this possible!

Here are the details:

Package Updates for kinetic

Added Packages [47]:

  • ros-kinetic-camera-umd: 0.2.5-0
  • ros-kinetic-executive-smach-visualization: 2.0.1-0
  • ros-kinetic-gazebo-dev: 2.5.13-0
  • ros-kinetic-gscam: 0.2.0-0
  • ros-kinetic-innok-heros-driver: 1.0.4-0
  • ros-kinetic-iot-bridge: 0.9.0-0
  • ros-kinetic-jpeg-streamer: 0.2.5-0
  • ros-kinetic-libuvc-camera: 0.0.9-0
  • ros-kinetic-libuvc-ros: 0.0.9-0
  • ros-kinetic-look-at-pose: 0.7.7-0
  • ros-kinetic-magni-bringup: 0.1.0-0
  • ros-kinetic-magni-demos: 0.1.0-0
  • ros-kinetic-magni-description: 0.1.0-0
  • ros-kinetic-magni-nav: 0.1.0-0
  • ros-kinetic-magni-robot: 0.1.0-0
  • ros-kinetic-magni-teleop: 0.1.0-0
  • ros-kinetic-msp: 2.0.2-0
  • ros-kinetic-multiwii: 2.0.0-0
  • ros-kinetic-puma-motor-driver: 0.1.2-0
  • ros-kinetic-puma-motor-msgs: 0.1.2-0
  • ros-kinetic-pyros-common: 0.4.2-1
  • ros-kinetic-python-ftputil: 3.3.0-3
  • ros-kinetic-qb-chain: 1.0.3-0
  • ros-kinetic-qb-chain-control: 1.0.3-0
  • ros-kinetic-qb-chain-description: 1.0.3-0
  • ros-kinetic-qb-device: 1.0.8-0
  • ros-kinetic-qb-device-bringup: 1.0.8-0
  • ros-kinetic-qb-device-control: 1.0.8-0
  • ros-kinetic-qb-device-description: 1.0.8-0
  • ros-kinetic-qb-device-driver: 1.0.8-0
  • ros-kinetic-qb-device-hardware-interface: 1.0.8-0
  • ros-kinetic-qb-device-msgs: 1.0.8-0
  • ros-kinetic-qb-device-srvs: 1.0.8-0
  • ros-kinetic-qb-hand: 1.0.5-0
  • ros-kinetic-qb-hand-control: 1.0.5-0
  • ros-kinetic-qb-hand-description: 1.0.5-0
  • ros-kinetic-qb-hand-hardware-interface: 1.0.5-0
  • ros-kinetic-qb-move: 1.0.5-0
  • ros-kinetic-qb-move-control: 1.0.5-0
  • ros-kinetic-qb-move-description: 1.0.5-0
  • ros-kinetic-qb-move-hardware-interface: 1.0.5-0
  • ros-kinetic-rodi-robot: 0.0.1-0
  • ros-kinetic-rosparam-handler: 0.1.1-0
  • ros-kinetic-smach-viewer: 2.0.1-0
  • ros-kinetic-swri-rospy: 0.3.0-0
  • ros-kinetic-usb-cam: 0.3.5-0
  • ros-kinetic-uvc-camera: 0.2.5-0

Updated Packages [98]:

  • ros-kinetic-actionlib-lisp: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-ar-track-alvar: 0.7.0-1 -> 0.7.1-0
  • ros-kinetic-ar-track-alvar-msgs: 0.7.0-1 -> 0.7.1-0
  • ros-kinetic-bin-pose-emulator: 0.1.1-0 -> 0.1.2-0
  • ros-kinetic-bin-pose-msgs: 0.1.1-0 -> 0.1.2-0
  • ros-kinetic-binpicking-utils: 0.1.1-0 -> 0.1.2-0
  • ros-kinetic-cl-tf: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-cl-tf2: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-cl-transforms: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-cl-transforms-stamped: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-cl-urdf: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-cl-utils: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-combined-robot-hw: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-combined-robot-hw-tests: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-controller-interface: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-controller-manager: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-controller-manager-msgs: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-controller-manager-tests: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-gazebo-msgs: 2.5.12-0 -> 2.5.13-0
  • ros-kinetic-gazebo-plugins: 2.5.12-0 -> 2.5.13-0
  • ros-kinetic-gazebo-ros: 2.5.12-0 -> 2.5.13-0
  • ros-kinetic-gazebo-ros-control: 2.5.12-0 -> 2.5.13-0
  • ros-kinetic-gazebo-ros-pkgs: 2.5.12-0 -> 2.5.13-0
  • ros-kinetic-geneus: 2.2.5-1 -> 2.2.6-0
  • ros-kinetic-hardware-interface: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-interactive-marker-twist-server: 1.1.0-0 -> 1.2.0-0
  • ros-kinetic-joint-limits-interface: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-joint-state-publisher: 1.12.8-0 -> 1.12.11-0
  • ros-kinetic-jsk-common-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-jsk-footstep-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-jsk-gui-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-jsk-hark-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-jsk-roseus: 1.6.1-0 -> 1.6.2-0
  • ros-kinetic-libphidget21: 0.7.2-0 -> 0.7.3-0
  • ros-kinetic-marti-data-structures: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-move-base-to-manip: 1.0.17-0 -> 1.0.18-1
  • ros-kinetic-moveit: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-commander: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-controller-manager-example: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-core: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-fake-controller-manager: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-kinematics: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-planners: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-planners-ompl: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-plugins: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-benchmarks: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-control-interface: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-manipulation: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-move-group: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-perception: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-planning: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-planning-interface: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-robot-interaction: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-visualization: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-ros-warehouse: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-runtime: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-setup-assistant: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-simple-controller-manager: 0.9.7-0 -> 0.9.8-0
  • ros-kinetic-moveit-visual-tools: 3.2.1-0 -> 3.3.0-0
  • ros-kinetic-phidgets-api: 0.7.2-0 -> 0.7.3-0
  • ros-kinetic-phidgets-drivers: 0.7.2-0 -> 0.7.3-0
  • ros-kinetic-phidgets-imu: 0.7.2-0 -> 0.7.3-0
  • ros-kinetic-plotjuggler: 1.0.7-0 -> 1.1.2-0
  • ros-kinetic-posedetection-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-py-trees: 0.5.9-0 -> 0.5.10-0
  • ros-kinetic-realtime-tools: 1.9.2-0 -> 1.10.0-0
  • ros-kinetic-robot-localization: 2.3.1-0 -> 2.4.0-0
  • ros-kinetic-robot-model: 1.12.8-0 -> 1.12.11-0
  • ros-kinetic-ros-control: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-ros-control-boilerplate: 0.4.0-0 -> 0.4.1-0
  • ros-kinetic-ros-type-introspection: 0.5.1-0 -> 0.6.3-0
  • ros-kinetic-roseus: 1.6.1-0 -> 1.6.2-0
  • ros-kinetic-roseus-smach: 1.6.1-0 -> 1.6.2-0
  • ros-kinetic-roseus-tutorials: 1.6.1-0 -> 1.6.2-0
  • ros-kinetic-rosjava-extras: 0.3.2-0 -> 0.3.3-0
  • ros-kinetic-roslisp-common: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-roslisp-utilities: 0.2.8-0 -> 0.2.9-0
  • ros-kinetic-rqt-controller-manager: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-rviz-visual-tools: 3.4.0-0 -> 3.4.1-0
  • ros-kinetic-speech-recognition-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-kinetic-swri-console-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-geometry-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-image-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-math-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-nodelet: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-opencv-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-prefix-tools: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-roscpp: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-route-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-serial-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-string-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-system-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-transform-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-swri-yaml-util: 0.2.4-0 -> 0.3.0-0
  • ros-kinetic-transmission-interface: 0.11.4-0 -> 0.11.5-0
  • ros-kinetic-urdf: 1.12.8-0 -> 1.12.11-0
  • ros-kinetic-urdf-parser-plugin: 1.12.8-0 -> 1.12.11-0

Removed Packages [2]:

  • ros-kinetic-ar-track-alvar-metapkg
  • ros-kinetic-thormang3-wholebody-module-msgs

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

  • Adolfo Rodriguez Tsouroukdissian
  • Alessandro Tondo
  • AlexV
  • Alwin Heerklotz
  • Andy Zelenak
  • Chris Lalancette
  • Christian Rauch
  • Claudio Bandera
  • Daniel Stonier
  • Dave Coleman
  • Davide Faconti
  • Devon Ash
  • Ed Venator
  • Elliot Johnson
  • Frantisek Durovsky
  • Gary Servin
  • Georg Bartels
  • Ioan Sucan
  • Isaac I. Y. Saito
  • John Hsu
  • Jon Binney
  • Jonathan Bohren
  • Jose Luis Rivero
  • KazutoMurase
  • Kei Okada
  • Kelsey Hawkins
  • Ken Tossell
  • Kris Kozak
  • Lorenz Moesenlechner
  • Marc Alban
  • Martin Guenther
  • Mathias Lüdtke
  • Michael Ferguson
  • Michael Görner
  • Mike Purvis
  • Rohan Agrawal
  • Russell Toris
  • Ryohei Ueda
  • Scott Niekum
  • Shohei Fujii
  • Stuart Glaser
  • Tom Moore
  • Toni Oliver
  • Yuki Furuta
  • durovsky
  • mike

Posts: 1

Participants: 1

Read full topic

by @tfoote Tully Foote on July 01, 2017 08:12 PM

NASA Space Robotics End With Awesome Win

@rmerriam wrote:

The NASA Space Robotics Centennial Challenge wrapped up today with the awarding of prizes at Space Center Houston. Nate Keonig was there to help present the award.

The first prize team, Coordinated Robotics scored 739 points out of a possible 855. The second place team scored 384 points. Coordinated also received a bonus prize for completing all 18 checkpoints without stopping during one of the runs.

Teams programmed the NASA R5 / Valkyrie humanoid robot in simulation using ROS and Gazebo. Tasks included realigning a satellite dish, deploying a solar panel, climbing stairs, opening an airlock door, and patching a leak in a habitat. The creators of the challenge, including a lead person who works with the R5, did not expect that all these tasks could be completed.

Posts: 1

Participants: 1

Read full topic

by @rmerriam Rud Merriam on July 01, 2017 01:34 AM

June 30, 2017
New Packages for Indigo 2017-06-30

@tfoote wrote:

We're happy to announce another sync of Indigo packages. It's mostly updates, 147, with 6 new packages and 2 removed.

Thank you to all the contributors and maintainers!

Details are below.

Updates to indigo

Added Packages [6]:

  • ros-indigo-gscam: 0.2.0-0
  • ros-indigo-oculusprime: 0.1.3-0
  • ros-indigo-python-pathtools: 0.1.2-0
  • ros-indigo-python-watchdog: 0.8.3-0
  • ros-indigo-rosparam-handler: 0.1.1-0
  • ros-indigo-surface-perception: 0.1.1-0

Updated Packages [147]:

  • ros-indigo-actionlib-lisp: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-checkerboard-detector: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-cl-tf: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-cl-tf2: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-cl-transforms: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-cl-transforms-stamped: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-cl-urdf: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-cl-utils: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-dynamic-tf-publisher: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-ecl-command-line: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-concepts: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-containers: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-converters: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-core: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-core-apps: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-devices: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-eigen: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-exceptions: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-filesystem: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-formatters: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-geometry: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-ipc: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-linear-algebra: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-math: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-mpl: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-sigslots: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-statistics: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-streams: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-threads: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-time: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-type-traits: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-ecl-utilities: 0.61.17-0 -> 0.61.18-0
  • ros-indigo-executive-smach: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-executive-smach-visualization: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-hironx-calibration: 1.1.24-0 -> 1.1.25-0
  • ros-indigo-hironx-moveit-config: 1.1.24-0 -> 1.1.25-0
  • ros-indigo-hironx-ros-bridge: 1.1.24-0 -> 1.1.25-0
  • ros-indigo-image-view2: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-imagesift: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-common: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-jsk-common-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-jsk-data: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-jsk-footstep-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-jsk-gui-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-jsk-hark-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-jsk-network-tools: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-jsk-pcl-ros: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-pcl-ros-utils: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-perception: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-pr2eus: 0.3.10-0 -> 0.3.11-0
  • ros-indigo-jsk-recognition: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-recognition-msgs: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-recognition-utils: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-jsk-roseus: 1.6.1-0 -> 1.6.2-0
  • ros-indigo-jsk-tilt-laser: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-jsk-tools: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-jsk-topic-tools: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-katana: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-arm-gazebo: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-description: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-driver: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-gazebo-plugins: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-moveit-ikfast-plugin: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-msgs: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-teleop: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-katana-tutorials: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-kni: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-marti-data-structures: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-mongodb-log: 0.1.28-1 -> 0.1.30-1
  • ros-indigo-mongodb-store: 0.1.28-1 -> 0.1.30-1
  • ros-indigo-mongodb-store-msgs: 0.1.28-1 -> 0.1.30-1
  • ros-indigo-moveit: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-commander: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-controller-manager-example: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-core: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-fake-controller-manager: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-full: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-full-pr2: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-kinematics: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-planners: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-planners-ompl: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-plugins: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-pr2: 0.6.2-0 -> 0.6.5-0
  • ros-indigo-moveit-ros: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-benchmarks: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-benchmarks-gui: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-control-interface: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-manipulation: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-move-group: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-perception: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-planning: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-planning-interface: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-robot-interaction: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-visualization: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-ros-warehouse: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-runtime: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-setup-assistant: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-moveit-simple-controller-manager: 0.7.9-0 -> 0.7.11-0
  • ros-indigo-multi-map-server: 2.2.3-0 -> 2.2.5-0
  • ros-indigo-plotjuggler: 1.0.7-0 -> 1.1.2-0
  • ros-indigo-posedetection-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-pr2-moveit-config: 0.6.2-0 -> 0.6.5-0
  • ros-indigo-pr2-moveit-plugins: 0.6.2-0 -> 0.6.5-0
  • ros-indigo-pr2eus: 0.3.10-0 -> 0.3.11-0
  • ros-indigo-pr2eus-moveit: 0.3.10-0 -> 0.3.11-0
  • ros-indigo-pr2eus-tutorials: 0.3.10-0 -> 0.3.11-0
  • ros-indigo-resized-image-transport: 1.1.0-0 -> 1.1.2-0
  • ros-indigo-ridgeback-control: 0.1.9-0 -> 0.1.10-0
  • ros-indigo-ridgeback-description: 0.1.9-0 -> 0.1.10-0
  • ros-indigo-ridgeback-msgs: 0.1.9-0 -> 0.1.10-0
  • ros-indigo-ridgeback-navigation: 0.1.9-0 -> 0.1.10-0
  • ros-indigo-robot-controllers: 0.5.2-0 -> 0.5.3-0
  • ros-indigo-robot-controllers-interface: 0.5.2-0 -> 0.5.3-0
  • ros-indigo-robot-controllers-msgs: 0.5.2-0 -> 0.5.3-0
  • ros-indigo-robot-localization: 2.3.1-0 -> 2.3.2-0
  • ros-indigo-robot-markers: 0.1.0-0 -> 0.1.1-0
  • ros-indigo-ros-type-introspection: 0.5.1-0 -> 0.6.3-0
  • ros-indigo-rosdoc-lite: 0.2.6-0 -> 0.2.7-0
  • ros-indigo-roseus: 1.6.1-0 -> 1.6.2-0
  • ros-indigo-roseus-mongo: 1.6.1-0 -> 1.6.2-0
  • ros-indigo-roseus-smach: 1.6.1-0 -> 1.6.2-0
  • ros-indigo-roseus-tutorials: 1.6.1-0 -> 1.6.2-0
  • ros-indigo-roslisp-common: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-roslisp-utilities: 0.2.8-1 -> 0.2.9-0
  • ros-indigo-rtmros-hironx: 1.1.24-0 -> 1.1.25-0
  • ros-indigo-rviz: 1.11.15-0 -> 1.11.16-0
  • ros-indigo-smach: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-smach-msgs: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-smach-ros: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-smach-viewer: 2.0.0-0 -> 2.0.1-0
  • ros-indigo-speech-recognition-msgs: 4.1.1-0 -> 4.2.0-0
  • ros-indigo-swri-console-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-geometry-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-image-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-math-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-nodelet: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-opencv-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-prefix-tools: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-roscpp: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-rospy: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-route-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-serial-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-string-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-system-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-transform-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-swri-yaml-util: 0.0.14-0 -> 0.3.0-0
  • ros-indigo-virtual-force-publisher: 2.2.3-0 -> 2.2.5-0

Removed Packages [2]:

  • ros-indigo-move-base-to-manip
  • ros-indigo-pr2-moveit-tutorials

Maintainers

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

  • Chris Burbridge
  • Claudio Bandera
  • Daniel Stonier
  • Dave Coleman
  • David Gossow
  • Davide Faconti
  • Ed Venator
  • Elliot Johnson
  • Georg Bartels
  • Henning Deeken
  • Ioan Sucan
  • Isaac I. Y. Saito
  • Jack O'Quin
  • Jonathan Bohren
  • Justin Huang
  • KazutoMurase
  • Kei Okada
  • Kris Kozak
  • Lorenz Moesenlechner
  • Marc Alban
  • Marc Hanheide
  • Martin Günther
  • Mathias Lüdtke
  • Michael Ferguson
  • MoveIt Setup Assistant
  • Nick Hawes
  • Ryohei Ueda
  • Sachin Chitta
  • Shohei Fujii
  • TORK
  • Thomas Kostas
  • Tom Moore
  • Tony Baltovski
  • Xaxxon Technologies
  • Yohei Kakiuchi
  • YoheiKakiuchi
  • Youhei Kakiuchi
  • Yuki Furuta
  • tkostas

Posts: 1

Participants: 1

Read full topic

by @tfoote Tully Foote on June 30, 2017 11:35 PM

Simulated Car Demo

Reposted from the OSRF Blog

We are excited to show off a simulation of a Prius in Mcity using ROS Kinetic and Gazebo 8. ROS enabled the simulation to be developed faster by using existing software and libraries. The vehicle's throttle, brake, steering, and transmission are controlled by publishing to a ROS topic. All sensor data is published using ROS, and can be visualized with RViz.

We leveraged Gazebo's capabilities to incorporate existing models and sensors. The world contains a new model of Mcity and a freeway interchange. There are also models from the gazebo models repository including dumpsters, traffic cones, and a gas station. On the vehicle itself there is a 16 beam lidar on the roof, 8 ultrasonic sensors, 4 cameras, and 2 planar lidar.

The simulation is open source and available at on GitHub at osrf/car_demo. Try it out by installing nvidia-docker and pulling "osrf/car_demo" from Docker Hub. More information about building and running is available in the README in the source repository.

by Tully Foote on June 30, 2017 06:32 PM

June 27, 2017
Amazing montage video including NEXTAGE OPEN celebrates MoveIt! 5-year
From TORK's blog:

MoveIt!, de-facto standard motion planning library for ROS, now celebrates 5th year since its initial release by an amazing compilation of application videos.
This is the 2nd time MoveIt! maintenance team makes such a montage.


Comparing with the one from 4 years ago back in 2013 soon after the software was just released, we can see many more Pick&Place applications this time.
Also captured my personal interest was that there are some mobile base/subsea rover manipulation apps, which is one of the future improvement items of MoveIt! (see this page “Mobile base integration”). It’d be absolutely a great contribution if the developers of those apps would give back their development to the upstream MoveIt! software.

As has always been, NEXTAGE Open, a dual-arm robot that TORK has been actively contributing to its maintenance and providing support service, appears in the video as well thanks to a Spanish system integrator Tecnalia presumably for their work with Airbus.

Hironx in motion from MoveIt! 5-year montage. Image courtesy  of Tecnalia
Hironx in motion from MoveIt! 5-year montage by courtesy of Tecnalia

TORK has been a motivated, skillful supporter of ROS and MoveIt! since our launch in 2013. If you’re wondering how you could employ MoveIt! to your robot, please consider our hands-on workshop series too.

P.S. List of all application’s developers are also available as follows:

(0:06) Delft Robotics and TU Delft Robotics Institute
(0:09) Techman Robot Inc.
(0:13) Correll Lab, CU Boulder
(0:37) Nuclear & Applied Robotics Group, Unv Texas
(0:50) Beta Robots
(0:55) GIRONA UNDERWATER VISION AND ROBOTICS
(1:03) Team VIGIR
(1:34) Honeybee Robotics
(1:49) ROBOTIS
(1:58) TECNALIA
(2:05) Correll Lab, CU Boulder
(2:26) TODO Driving under green blocks
(2:38) ROBOTIS
(2:54) Fetch Robotics
(3:05) Hochschule Ravensburg-Weingarten
(3:12) TU Darmstadt and Taurob GmbH – Team ARGONAUTS
(3:20) isys vision
(3:27) Technical Aspects of Multimodal System Group / Hamburg University
(3:33) Clearpath Robotics
(3:43) Shadow Robot

by Isaac Saito (noreply@blogger.com) on June 27, 2017 08:10 PM

June 25, 2017
ROS in Poland?

@pnti wrote:

Hello,

Do you know any community, company or individual people in Poland creating robots with ROS?

Thank you in advance.

Wojtek.

Posts: 8

Participants: 7

Read full topic

by @pnti Wojciech Domalewski on June 25, 2017 01:34 PM

June 24, 2017
Updated MoveIt! Now Comes with Trajectory Introspection
From TORK blog:

    Through the package update earlier June 2017, MoveIt! now allows you to introspect planned trajectory pose by pose.
    Using the newly added trajectory slider on RViz, you can visually evaluate the waypoints in a planned trajectory on MoveIt!. 
    Introspect waypoints in a planned trajectory on MoveIt! on NEXTAGE Open.

    As you see on the slider on the left side, you can now introspect each waypoint in a planned trajectory on MoveIt! on NEXTAGE Open.

    See MoveIt! tutorial for how to activate this feature.

by Isaac Saito (noreply@blogger.com) on June 24, 2017 09:18 AM

New Software Release - Py Trees

@Daniel_Stonier wrote:

About

py_trees and py_trees_ros were developed and used on robots at field tests around the world over the course of the last couple of years for Yujin Robot. I'm happy to announce that they're now document complete with a great list of tutorials and ready to be consumed! A brief list of features:

  • All the bells and whistles' you'd expect from a comprehensive behaviour tree library
  • Assemble trees in relatively simple and short python scripts
  • Additional ROS behaviours for common ROS operations (subscriber, move_base, ...)
  • A ROS behaviour tree manager with status publisher for connection to an rqt monitoring plugin
  • Automatic bagging of the tree status when it changes
  • Replay bags in the rqt monitoring program to identify problems
  • Simple to mock with a robot layer for debugging, testing on CI and as a rapid simulation for use with web application development.

As you can probably infer, there was a focus on making sure we could easily debug problems, especially when they occurred at a remote test site without an engineer (the replay tool especially was very useful). On the other hand, a graphical designer frontend was not prioritised and never eventuated - scripting a python tree remained simple and flexible enough to suit our needs. We also had the trees pass a litmus test of being able to pass the work of building robot-specific behaviours and trees off to interns. It took three iterations of the core libraries to pass that point, but since then there has been negligible change in the core libraries.

Additionally, the trees started being used beyond the scenarios they were originally designed for. The control engineers started shifting all non-reactive control logic to the trees - it was just easier to follow patterns already implemented and to make use of the bagging/visualisation/replay tools, e.g. implementing an entire subtree for initialisation from a composition of context switches (small dyn. reconfigure changes), enabling/disabling of sensors and simple motions instead of having a separate c++ or python node that would handle the entire process as a custom state machine inside an action. Also, as the logic accumulated in the trees, the data to support it also centralised there, and it eventually became the natural portal point between robot and server/web applications.

Availability

All the py_trees packages (py_trees, py_trees_ros, py_trees_msgs, rqt_py_trees) are on the ros build farm and repository details on the ros wiki. You can also use the py_trees package itself directly from pip as a pure python module.

Getting Started

Get started at the py_trees_ros README. If you just want a quick glimpse of how they can be use in ROS, jump directly to the py_trees_ros tutorials.

Posts: 8

Participants: 4

Read full topic

by @Daniel_Stonier Daniel Stonier on June 24, 2017 08:10 AM

June 23, 2017
Announcing dynamixel-workbench version update (the official package in ROBOTIS)

@routiful wrote:

Hi, ROS people :slight_smile:

Dynamixel-Workbench is dynamixel solution for ROS.
This metapackage allows you to easily change the ID, baudrate and operating mode of the Dynamixel. Furthermore, it supports various controllers based on operating mode and Dynamixel SDK. These controllers are commanded by operators.

This updates are focused on toolbox library. This library is composed of 'dynamixel_tool', 'dynamixel_driver' and 'dynamixel_multi_driver' class. The 'dynamixel_tool' class loads the information of Dynamixel stored in '.device' files. The 'dynamixel_driver' class which is based on DynamixelSDK provides functions to control an Dynamixel. The 'dynamixel_multi_driver' class which is inherited by 'dynamixel_driver' class provides functions to control Dynamixels.

You can use this package and library when you operates Dynamixel.

If you have any questions or feedbacks for this packages, please feel free to contact to me. :wink:

Thank you!

WIKI : Dynamixel-Workbench

(Dynamixel-Workbench Single Manager)

(Dynamixel-Workbench Single Manager GUI)

Posts: 5

Participants: 3

Read full topic

by @routiful Taehoon Lim(Darby) on June 23, 2017 04:39 AM

June 22, 2017
Successful ROS-I Kinetic Training Class - Curriculum Available

The ROS-Industrial Consortium Americas hosted a ROS-Industrial Developers Training Class June 6-8, 2017, at SwRI in San Antonio, Texas. Twelve attendees represented a diverse set of organizations, including Bastian Solutions, EWI, John Deere, PlusOne Robotics, Magna International, Rensselaer Polytechnic Institute, The University of Texas at Austin, and Yaskawa America’s Motoman Robotics Division. The three-day class was geared toward individuals with a C++ programming background who sought to learn to compose their own ROS nodes.

  • Day 1 focused on introductory ROS skills.
  • Day 2 examined motion planning using MoveIt! as well as using the Descartes planner and perception concepts.
  • Day 3 included an introduction to perception and culminated with lab programming exercises with a choice of Pick-and-Place Application or Descartes Application.

Many thanks to training class leaders Jeremy Zoss and Austin Deric. The training curriculum is open-source and available here.

For more details about this class, see the event page.

If you are interested in attending the next class in October, keep an eye on this event page.

THE FULL CLASS WITH SWRI ROS-INDUSTRIAL SUPPORT STAFF INCLUDED

THE FULL CLASS WITH SWRI ROS-INDUSTRIAL SUPPORT STAFF INCLUDED

by Levi Armstrong on June 22, 2017 12:41 PM


Powered by the awesome: Planet