Subscribe via Email

Monday, January 23, 2017

Porting to ROS: ARC Stage

technical: Directed to those in CS/Robotics/etc. General reader may still keep up.
3 weeks or so have passed. I've been incredibly busy with the startup of a new term, I'll document some of it here.
Migration to ROS

First and foremost, I've migrated from Player to the ROS (Robot Operating System) platform. This was due primarily to community activity. stage_ros  is a package that exists on the ROS Platform, which is nearly identical to Stage; however, it acts as a node publishing simulation information onto various topics, which can be picked up by other nodes developed in ROS.
If you're interested, here is a brief rundown of ROS. There is a lot going on, so I can't even begin to explain it here.

Why ROS?

The Player project was used to provide an open source network server for interfacing with various robot sensors and actuators. It provided a layer of abstraction that took away the complexity of each driver, and allowed programmers to focus solely on programming to a single interface.
ROS is the next level of Player. ROS (Robot Operating System) provides a wide spanning selection of packages developed by a rapidly growing community that allows for interfacing with almost any commercial robotics. Furthermore, the use of message passing allows for "nodes", that is, individual executables, to publish messages on some topic, and have other nodes subscribe (listen) to these messages. Such a structure means you can now use software such as Stage, without following the elaborate tutorials for it. Once you understand the ROS structure, of how nodes/messages/etc work, you can communicate with stage via these components.

Again, I couldn't begin to start summarizing the workings of ROS. I strongly suggest reading up on tutorials for it if interested. ROS has gotten to the point where, if you're involved in robotics, you should at least be familiar with it. Not knowing basic ROS in 2017 is like not knowing how to sleep.... EVERY ONE knows how to sleep, even robotics researchers (most of them)... so they should learn ROS... that's what I'm trying to get at here... ANYWAY, here is what the rest of the workterm is looking like, as the noise settles.

Workterm Focus

     Throughout a lot of reading, and exploring of work, the path for this workterm will involve porting thesis work from a previous graduate, Geoff Nagy  to the ROS platform.

      Geoff Nagy did his thesis on Active Recruitment in robot teams. Picture a group of robots, that needs to cooperate. In order to do so, each player on the team may have certain roles it must follow, and thus tasks it can take on to itself. More often than not, a team will find work to be done; but not possess the ability to complete it with the current team mates. This means recruitment is needed. Traditional work in the AALAB focused on passive recruitment, where a new robot may join a team if they cross paths, coincidentally. Active recruitment, on the other hand, involves the intentional act of searching for a new teammate, by navigating through the environment.
     The consequence of active recruitment is that there is a tradeoff between searching, and working. If a team is purely active, and only spends time searching for better teammates, no work may get done. Geoff's thesis explores the tradeoffs of Active vs Passive recruitment and the challenges of balancing them to maximize the performance of a team.

     The work he did went in depth, a LOT More than I will go (or can go). Check out his thesis HERE or shorter summary HERE if interested.

     He did some interesting experimentation via simulation, that I would like to replicate in the real world, using a team of Pioneer 3DX robots.
pioneer P3-DX robot with sonar
A pioneer P3-DX robot equipped with sonar (front)

     The traditional way would be to use Player; however as said above the lack of community involvement (migration to ROS) and just the overall betterness of ROS directed me to use it. Now the challenge will be to determine the opportunity cost of using ROS, which primarily includes time spent porting from raw Stage implementation.
   
     record scratch

     freeze frame

How did I get here?
It's a Sunday afternoon and I'm catching up on missed work hours due to the Google interview I had earlier in the week. Aside from bombing the interview, I've made a decent amount of progress on porting to ROS.

As it stands, the ARC_stage (active recruitment component + STAGE) now runs on a ROS node. One consequence is that stage_ros only supports 1 sensor per ranger... ie I can use only lasers and not sonar sensors that come with Pioneer robots. I made a few patches to the stage_ros package, so I may consider modding it to support sonar. For now my next week or so will involve designing a ROS implementation, and determining how it will be ported...

This is where a unique learning experience has shown itself to me. Unlike a University course, where you have an assignment and know the time it will take to complete, this is an open-ended project. I'm in charge of figuring out

  • WHAT I want to do
  • WHAT I need to do it
  • HOW long it will take
  • DOING it

all while communicating with my advisor, and others who are appropriate to.

My overall goal this term will be to port to ROS, and run Geoff's work on real robots. ROS will allow me to record more complex results from the simulation which is an added bonus.

Robot Magic

     The magic continues, with a paper in creation. Jacky dropped by from Taiwan a week ago, and dropped this on me (which is awesome!). I'm working heavily on this paper now, which means I don't have time to write this blog post. I'll do a shorter version summary of the paper after it is completed. I'm greatly hoping this will be my first publication accepted into a journal.

That's all for now. This chaotic summary was brought to you by tight deadlines and caffeine.

   
   

No comments:

Post a Comment

Please feel free to give feedback/criticism, or other suggestions! (be gentle)

Subscribe to Updates via Email