Tuesday, January 24, 2017

2017 MoveIt! update pt.2; Stopping motion on NEXTAGE needs your help

From TORK blog:


In the previous post we introduced one of the many new features that were added to MoveIt! with its first update in 2017. Next feature we want to mention is the “stop motion”, which we’ve received many questions from our NEXTAGE users about.

Other than situations where you need to stop robots to move for the safety reasons, there can be many cases you want to stop/cancel/halt your robot for your application. The standard way to achieve this in MoveIt! had been lacking, which is finally organized this time (lead by a student at GSoC project by the way).

It works well with Pepper robot on simulation. You see in the following Youtube video (link in case you don't see the video pasted) that the arm stops as soon as the “stop” button on RViz was clicked.

This nice feature, however, does not YET work with the NEXTAGE Open. Don’t worry much, there’s a work going on already and we confirmed a patch submitted from a community member solves the issue on simulation! We just need to test the patch on the real NEXTAGE Open robot, and this is where we need a help from the robot owners. If you think you can help us testing with your own robot, please contact TORK at info[a_t]opensource-robotics.tokyo.jp or joint the discussion at the ticket for this issue on Github so that we’ll communicate with you. Thank you for your understanding toward the opensource!

Wednesday, January 4, 2017

First MoveIt! Update in 2017. Using it on NEXTAGE pt.1

From TORK blog:

New version of MoveIt! binary 0.7.6 is just released for ROS Indigo, first time in 2017 (for sure!) and first release since June 2016. This version comes with some long-wanted features (along with bug fixes of course) that we’re trying out using NEXTAGE simulator.

1. Changing trajectory velocity and acceleration during runtime

Changing the speed of the trajectory during runtime has been one of FAQs from NEXTAGE users who use MoveIt!, let alone many MoveIt! users on the globe. Now through MoveIt! RViz plugin you can conveniently configure that on the fly on the spinboxes added.


To configure that programmatically, see this tutorial that explains chainging MotionPlanRequest topic would do the work.

TORK is actively contributing the development and maintenance of MoveIt!.

Wednesday, December 21, 2016

Dynpick force-torque sensor ROS driver update thanks to opensource contribution

From TORK blog:

ROS device driver for force-torque sensor Dynpick, one that TORK joins its maintenance, has been known to work for a discontinued product only so far. Now someone in the opensource community just confirmed that the package works with a product that’s still available!

Products confirmed to work has been and will be updated on the driver’s wiki page. Report, questions can be posted on its Github page.

And as always, may the power of opensource be with you. Happy holidays!

Thursday, December 15, 2016

TORK to co-host Toyota HSR workshop for users

From TORK's blog:

TORK has been partnering with the “HSR” welfare robot’s dev team at Toyota Motors Corporation (TMC). In 2014 and the last year 2015 we worked together with them for the hackathon.
This year we worked with TMC again to host developers workshop at 4 venues in Japan. In addition to going over the robot’s unique features and programming using ROS, we particularly focused on utilizing the online community designated for HSR owners, which TMC initiated in 2015 and maintains by themselves (membership-only as of today). Goal is that participants get hands on experience in interacting on the developers community so that they can accelerate their own development, which also contributes to develop the community size and maturity, which the developers ultimately appreciate. That said the seminar series this time is the beginning of building the community’s life cycle as TMC’s dev team intended.    

DSC_0302 CIMG3749 tokyo20_crop IMG_20161108_112241 IMG_20161108_111225 DSC_0312

Also discussed is problem isolation – engineers often need to figure out the types of problems and post questions at the best community per incident. This is more an advanced subject, but participants well exceeded our expectation to separately post HSR-specific questions and generic-ROS questions on the forums of each. This may have resulted in the positive spike of the number of posts at the ROS Japanese user groups as you see in the graph below (workshop series started in October).
Closing this blog post with some videos from the code challenge at the end of the workshops (if you're not seeing any video snippet, go to the original blog post). We truly hope that we’ve contributed to the HSR and the world of robotics community by encouraging community involvement.

Friday, September 23, 2016

catkin-tools tip pt.2

From TORK blog

Following our previous post about a nice hidden tip for catkin-tools, here’s another one.

When finishes compilation, `catkin build` shows a pop-up window at the top-right on your screen (if you’re on Ubuntu Linux), which indicates `Build Finished` or `Build Failed`. This is nice in that you can work on another windows without payting attention to catkin’s progress. Caveat is, though, that “Finished” and “Failed” aren’t that obviously differentiating whatsoever.
With the newer version of catkin-tools, 0.4.3 or higher, the window pops up with a distinguishable colors; Green for success and red for failure.

This little but significantly effective change is done by our TORK associates again. The change was made swiftly and neatly as it has always been in the opensource software community.

Friday, July 1, 2016

Easy Teaching Operation for NEXTAGE Open by MoveIt! Joystick

(From TORK blog)

One of good news about ROS community is that the maintenance of MoveIt! got revitalized where TORK is contributing to as well. In 2016 there has already been three binary update releases so far. No more building from source if you were forced to!
We’ve mentioned about MoveIt! a few times recently ([1][2]), so do we today again. With the version 0.7.2 (on ROS Indigo), you can operate robot arms by joystick via MoveIt!

Running the feature is as simple as joystick. On RViz on the host where the joystick is plugged, check “Planning” tab –> “AllowExternalExecution” (see the image below).
Then run a launch file, either the one in your XXXX_moveit_config package if there’s already the aforementioned launch file, or simply make a launch file with the following:

<!-- https://github.com/ros-planning/moveit_setup_assistant/pull/90 -->
  <arg name="dev" default="/dev/input/js0" />

  <!-- Launch joy node -->
  <node pkg="joy" type="joy_node" name="joy">
    <param name="dev" value="$(arg dev)" /> <!-- Customize this to match the location your joystick is plugged in on-->
    <param name="deadzone" value="0.2" />
    <param name="autorepeat_rate" value="40" />
    <param name="coalesce_interval" value="0.025" />

  <!-- Launch python interface -->
  <node pkg="moveit_ros_visualization" type="moveit_joy.py" output="screen" name="moveit_joy"/>
For the detail follow the usage page.
To run on NEXTAGE Open, make sure MoveIt! is running then run a single command below (modify jsX). You can also refer to wiki for joystick usage for NEXTAGE Open.

roslaunch nextage_moveit_config joystick_control.launch dev:=/dev/input/js1

(At the top window, the human operator plans the movement on RViz visualizer. Once the plan looks good then operator executes the plan so that the simulated robot in the bottom window conducts the movement. This is a screen capture so joystick isn't invisible, but yes, all the robot's movement is commanded from a Sony PS3 joystick.)

Friday, June 24, 2016

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?).