Friday, October 13, 2017

Opensource software package maintenance in a cleaner, more thorough and verbose manner

There's various form of maintenance for software packages. ROS wiki spreads out well.
And, there's a recent discussion about the maintainership for "orphaned package"s.

I totally agree with the bigger picture in this thread; spending (even minimal) effort on making releases to make packages sustain for longer period rather than letting packages fade out. Yes.

Below is something I just wanted to chime in to the thread, but decided not to because it's a little off-topic, and I was afraid that I may sound opposing to the main idea in the thread. while I am not. So I decided to tweet in my own space.

It was triggered by someone's line:
In my experience, running the `catkin_generate_changelog`, `catkin_prepare_release`, `bloom-release` commands takes up maybe 1% of the time in maintaining a package.
As a release-maintainer of many long-lasting packages, I have to oppose here. So I just listed out the "release-maintainer"'s tasks I can think of, which may not be clear to the outside. These don't make a whole, and most of them may be optional, but still:
  • Release the package.
    • Changelog. Yes, `catkin_generate_changelog` populates raw commit logs per pkg.
      • Totally optional, but I tend to spend certain amount of time to edit changelogs to be more useful than just a set of commit history.
    • To what version to increment? Yes `catkin_prepare_release` handles this.
      • But you want to version it "right", which requires some idea about backward compatibility, features added etc. Typically this might require coordinating developers and/or going through the commits/PRs that have been added.
    • Run prerelease test.
      • Locally if your repo doesn't do it on cloud (btw industrial_ci offers a feature to run it on cloud).
      • For a ROS distro that supports multiple platform, run prerelease tests per each platforms if possible. For Kinetic, there was Wily until it went EOL, in addition to Xenial.
    • `bloom` can fail for whatever issues in your packages that you are almost automatically in charge of fixing.
      • Once issues occur on ROS buildfarm, a lot of times you're the only one to take (at least initial) action against it.
        • Hence, `prerelease test`, folks.
  • There's also "mental" responsibility. Not a big deal most of the times, but when something occurred like on buildfarm, you'd feel bad besides that it's you who people expect to fix the issues.
For larger set of packages, making a new release could take up some good time if done thoroughly (at least it does for me). But for doing things like above, only changelog is where volume matters, so releasing in a good manner is non trivial IMO.

I do believe by doing the release chores more thoroughly like this, there's a benefit for the users. Still, what's critical at first hand is that the package being available, as discussed in the referenced thread and again I fully agree with that.

Tuesday, 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
(1:03) Team VIGIR
(1:34) Honeybee Robotics
(1:49) ROBOTIS
(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

Saturday, 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.

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] 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.