Appable Robot Design Proposal

[Daniel Stonier]

Hi all,

We are going to spend a busy couple of months upgrading the applications platform (previously installed on turtlebot and pr2) with the aim of landing it in Turtlebot for either Hydro or Indigo depending on progress.

Primary Goals:

The first three are simply upgrades on what was roughly working on turtlebot and pr2:

1) Easy retasking

2) Convenient installation/upgrade mechanisms

3) Pairing mode for 1-1 control with autodiscovery

These are additional features we are planning to work on:

4) Concert mode for multi-robot research and solutions

5) Capability layer to simplify and improve the robot app portability

6) Properly do public/private interfaces to the robot (i.e. don't expose the internal master, nor all topics)

If you're interested in providing input, I've kickstarted a review page where any and all ideas are welcome.

Best place for discussion is probably on the multimaster sig mailing list.

Cheers,

Daniel (Yujin Robot)

[Michael Ferguson]

Daniel,

I think one of the biggest shortcomings of the previous system was the inability to easily handle resource management, so I'm glad to see you're thinking about capabilities. 

A while back I had started on a little implementation of what a capabilities system might look like for ros (I just pushed it up to github, it was previously in the vanadium-ros-pkg SVN: https://github.com/mikeferguson/capabilities). The main features I was interested in was:

 * keep tracking of what capabilities were already launched, 

 * launching new ones when needed

 * most importantly: doing resource counting on the capabilities. Robots are always looking for more processing power, and turning off unneeded things often helps (ideally, every piece of software in ROS would be written with lazy publish/subscribe, but often that just isn't the case and lots of pipelines are running with data going nowhere). 

I also had some notion in there of attaching semantic tags to capabilities. For instance, you might have multiple cameras, but one of them is a "head" camera and one is a "base" camera and another is a "gripper" camera. If I write a security robot app that looks for unknown faces, it can ask for "head" cameras if available (and falls back to other cameras if no head camera exists). Obviously this requires some management of keyword choices, but it would likely go the way of topics (every robot builder out there uses geometry_msgs/Twist because navigation stack and teleop code everywhere does so, and if you have cool apps that require you label your head cameras as "head", robot builders will do it).

-Fergs

[Daniel Stonier]

On 21 March 2013 17:52, Michael Ferguson <mfe...@gmail.com> wrote:

Daniel,

I think one of the biggest shortcomings of the previous system was the inability to easily handle resource management, so I'm glad to see you're thinking about capabilities. 

A while back I had started on a little implementation of what a capabilities system might look like for ros (I just pushed it up to github, it was previously in the vanadium-ros-pkg SVN: https://github.com/mikeferguson/capabilities). The main features I was interested in was:

 * keep tracking of what capabilities were already launched, 

 * launching new ones when needed

 * most importantly: doing resource counting on the capabilities. Robots are always looking for more processing power, and turning off unneeded things often helps (ideally, every piece of software in ROS would be written with lazy publish/subscribe, but often that just isn't the case and lots of pipelines are running with data going nowhere). 

I also had some notion in there of attaching semantic tags to capabilities. For instance, you might have multiple cameras, but one of them is a "head" camera and one is a "base" camera and another is a "gripper" camera. If I write a security robot app that looks for unknown faces, it can ask for "head" cameras if available (and falls back to other cameras if no head camera exists). Obviously this requires some management of keyword choices, but it would likely go the way of topics (every robot builder out there uses geometry_msgs/Twist because navigation stack and teleop code everywhere does so, and if you have cool apps that require you label your head cameras as "head", robot builders will do it).

-Fergs

Sorry for the delay, been snowed under alot of white noise the last couple of days. 

Awesome that someone else has been thinking about capabilities already. I really didn't put much information on the wiki about them, but that is the one area I wanted to gather other people's opinion's on, so I'll parse through what you've got and update tomorrow. 

We actually had one more item we wanted to use the capabilities for - that was a means of working out what software needs to be installed. Our primary example in discussions here at Yujin was for the navigation stack. We run with a couple of implementations here depending on the robot, but they're all black boxes with the usual topics going in and out. We could feasibly have an application that needs navigation capability that could be installed on all of our robots, and depending on the robot, the capability rule for that robot determines which software underneath gets installed. 

I like the idea of semantics. I was planning to use something similar to that at a higher level, but that might well suit at the capability level as well. 

Daniel.

 

On Wednesday, March 20, 2013 7:01:01 PM UTC-7, Daniel Stonier wrote:

Hi all,

We are going to spend a busy couple of months upgrading the applications platform (previously installed on turtlebot and pr2) with the aim of landing it in Turtlebot for either Hydro or Indigo depending on progress.

Primary Goals:

The first three are simply upgrades on what was roughly working on turtlebot and pr2:

1) Easy retasking

2) Convenient installation/upgrade mechanisms

3) Pairing mode for 1-1 control with autodiscovery

These are additional features we are planning to work on:

4) Concert mode for multi-robot research and solutions

5) Capability layer to simplify and improve the robot app portability

6) Properly do public/private interfaces to the robot (i.e. don't expose the internal master, nor all topics)

If you're interested in providing input, I've kickstarted a review page where any and all ideas are welcome.

Best place for discussion is probably on the multimaster sig mailing list.

Cheers,

Daniel (Yujin Robot)

--
You received this message because you are subscribed to the Google Groups "ROS Multi-Master Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mm+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin R&D: http://rnd.yujinrobot.com/