PR list for hrpsys trunk

[garaemon]

list up the PRs waiting for hrpsys trunk release.

• update :start-auto-balancer and :stop-auto-balancer method rtmros_common#396
• update rtc name ;; Absoluteforcesensor => RemoveForceSensorLinkOffset rtmros_common#397
• Support odom topic rtmros_common#424
• add launch file to run robot_pose_ekf rtmros_tutorials#37
• Support imu topic rtmros_common#430

[garaemon]

we need to merge these branches in order to test hrpsys trunk code

[k-okada]

@130s, here is the request from rtmros_common users to update using hrpsys-trunk, this will break all QNX usres, any idea?

[garaemon]

also, now I'm preparing several PRs for hrpsys trunk about walking stuff.

[garaemon]

I added another PR about /odom topic

[snozawa]

@130s, here is the request from rtmros_common users to update using hrpsys-trunk, this will break all QNX usres, any idea?

@k-okada, what do you mean by "break"?
As for Hironx@QNX, these update about AutoBalancer and RemoveForceSensorOffset have few influence to use hrpsys + rosBridge.
IDL update might be a big change.

[k-okada]

Half of QNX users did no have compiler/SDK so we have to compile and install software for them remotely.

Unfortunately we haven't yet suceeded to build up the process to do that automatically. I hope https://github.com/start-jsk/rtmros_hironx/blob/groovy-devel/hironx_ros_bridge/robot/robot-compile-hrpsys.sh script should work, but everytime we visited hiro user, it does not work. One reason is that each hiro robot have different harddisk setup.

We also need something new for HIRO users for convince them to upgrade hrpsys, and collision detection may good feature, but it still opened -> start-jsk/rtmros_hironx#36, I asked several people, but may be I have to do that by my self....

[130s]

I prefer to talking about branching policy at one single place, at #76 if that's okay.

[snozawa]

Thank you, I see.

One reason is that each hiro robot have different harddisk setup.

This seems to be a quite big problem...

[k-okada]

As I write at #76 (comment), this is for expert users and only applied to robot internal/related machines.
I think is may good compromise to create branch in rtmros_common for trunk version of hrpsys. and as for hrpsys repository, expert users manually changed Makefile.hrpsys-base to download current version of the software.

Before doing that I'd like to confirm:

1. Could you specify which commit in https://github.com/fkanehiro/hrpsys-base/commits/master breaks IDL API, I'd like to know that there are no change of creating 315.1.11 that contains new features, so that we do not have to create new branch
2. s PR list for hrpsys trunk #75 (comment) contians "ALL" pathces that requires hrpsys-trunk?
3. can you consider reverting Absoluteforcesensor => RemoveForceSensorLinkOffset in hrpsys-base so that we can avoid keeping https://github.com/start-jsk/rtmros_common/pull/397/files PR in branch?
4. If 3 happens, do we really need to manage https://github.com/start-jsk/rtmros_common/pull/424/files in different branch?

[garaemon]

I added start-jsk/rtmros_tutorials#37, but it does not depend on hrpsys-trunk strongly, so we can merge it before hrpsys-trunk.
because the PR just adds a launch file.

[garaemon]

I added start-jsk/rtmros_common#430.

[k-okada]

@snozawa By the way, can we consider hrpsys-315.1.11? that includes newer features for current experiment?

I'm not sure what is the difference between hrpsys-trunk and hrpsys-315.1.10, unless it breaks API we can merge and bump to 315.1.11.
If hrpsys-trunk features that is required for @garaemon is

1. Imu, 2) TbaseTransfrom, 3) AutoBalancer and if 1) 2) is not change the API, then it can be merged into 315.1.x, if 3 just to add new idl I'm not sure if this will break downstream package.
   if compiled verison of 315.1.11 works with deb version of rtmros_common, then it is ok.

cf: start-jsk/rtmros_common#397 (comment),
#76 (comment)

[k-okada]

closing, if this is not applied yet, please reopen this.