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.

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 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
(0:55) GIRONA UNDERWATER VISION AND ROBOTICS
(1:03) Team VIGIR
(1:34) Honeybee Robotics
(1:49) ROBOTIS
(1:58) TECNALIA
(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

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

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.

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!

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