Investigating unexplored region while making a map (frontier_exploration with Turtlebot)

(From TORK blog)

When making a map using ROS, you’re likely tele-operating your robot for every single move via keyboard or joystick at best. But I know a demand exists for “planning” in advance a region that robot explores to make a map.

That’s where a package called frontier_exploration gets useful; it provides ROS actionlib interface, through which users can send the location to explore. We just made a sample using Turtlebot to show how to integrate frontier_exploration package into your own robot. Resulted package can be seen at turtlebot_samples. As the following movie (It’s long! You’re warned…) shows, you can run by a single command Gazebo simulator, spawn Turtlebot on a sample map and send a command for the exploration.

You set the region to be visited by drawing a polygon on RViz, then after clicking a point within the polygon robot will move. Once it starts moving user isn’t sending anything (robot moves autonomously to the given goal along the computed path).

Shorter video is also available (it’s not Turtlebot. Video was taken by the original developer of the frontier_exploration package)

In these videos the robot is commanded manually on RViz window. You can also send commands programmatically using its API.

So far we confirmed that frontier_exploration can be applied to the robots with gmapping and move_base (incorporating with other navigation packages may be as simple?)．

Thanks to opensource community, issue with NEXTAGE Open software (3D model geometry, tf) got resolved promptly

(From TORK's blog)

A user reported an issue in tf with NEXTAGE Open software that got resolved in a quick fashion thanks to opensource collaboration across organizations/userbases. Binaries (the ones installable by apt-get) including the fix is already available online. Please see more detail of the issue and how to apply the fix this ticket on github.
We, TORK, thinks without any doubts that the big advantage of making software public is that you get testers from across the globe. The fix this time is a true realization of this opensource dogma; if I review the ticketed report for this issue on github now, you’ll see the flow:

• A user reported the issue.
• –> Someone from robot’s manufacturor gave a comment.
• –> Another heavy user commented.
• –> Maintainer (us) created a fix candidate.
• –> Reporter user tested fix candidate and confirmed that it fixes.
• –> Maintainer pulled in the fix.

At least four persons from different organizations contributed so far up to this point, within only a week timeframe. And everybody is not obligated to this ticket (but us).
Going further, once the fix is pulled then it’s also important to make the fix easily accessible by the users. Having them as binary form is the way to go. We do that by relying on the platform the ROS maintenance team (OSRF) runs, as have we already done so. Steps for that is really simple (*1)：

• Submit a request for generating a binary (submission from this time)
• –> Announcement by OSRF that the binaries are ready (announcement made this time by OSRF)

TORK believes that opensource software development contributes to improving quality and fastening the engineering cycle for the corporations. That’s why we have and will continue contribution to the opensource community.

*1 Initial release takes a bit more steps. But once done so it’s really easy!