Adding acceleration scaling factor#17
Adding acceleration scaling factor#17davetcoleman merged 1 commit intomoveit:indigo-develfrom BrettHemes-3M:indigo-devel
Conversation
|
@mikeferguson are you ok with this changing a message type in indigo? I forget the rule of thumb |
|
The challenge with changing this is that the addition of a field will change the MD5 on the message -- if someone then has a robot with slightly older debs than their desktop (or vice versa) the two will not be able to communicate. In general I would recommend against MD5 changes in stable releases, but we have changed the MD5 in Indigo once already in the past, so I can't say flat out "no this shouldn't be merged". In fact, the last MD5 change was to add the velocity scaling... |
|
@mikeferguson Understood. I actually had a MD5 message issue the other day and it was a bit troublesome. Ideally this change would have been made at the same time that the velocity scaling was added. That said, I do feel that the acceleration scaling feature is important. In many cases maximum acceleration is undesirable for a trajectory and being able to change it on a per-request basis makes handling dynamic payloads convenient. As an aside, the particular issue I had that spawned my efforts was with a UR10. If I have any significant payload attached (~4+ Kg) a full-acceleration trajectory will result in jerky starts and stops, even after scaling the maximum velocities. |
|
Since this is a mirror of the velocity scaling feature, which was merged into indigo after indigo's release, I think it should be ok to make this change, too. |
Adding acceleration scaling factor
Adding acceleration scaling factor (Cherry-pick #17 into jade)
|
Please bump minor/major version when you changed MD5 value, we just had a MD5 message issue yesterday... |
|
On Wed, Dec 21, 2016 at 07:38:44PM -0800, Kei Okada wrote:
Please bump minor/major version when you changed MD5 value, we just had a MD5 message issue yesterday...
Could you explain why bumping the minor/major version would avoid that?
Is there some mechanism in place somewhere in ROS that checks for that?
I find it really unfortunate that we do not have a way to indicate that new fields were added to messages.
This is essentially only ABI breakage, but because the messages are header-only we can't code that in sonames.
- We just introduced (full) sonames in kinetic to get rid of abi problems in the libraries.
Version numbers in MoveIt is a topic somewhat difficult.
Some people ascribe quality & stability properties to 1.x releases that we cannot meet at the moment,
so, up to now, we stayed away from the major version number at all.
Also, because we release software for several branches, we want to keep the version numbers for the different
branches apart. This reserves the minor number (0.7.x for indigo, 0.8.x for jade, 0.9.x for kinetic).
This only leaves the patch-version for upgrades within a single ROS distribution.
On the other hand MoveIt is still more fast-paced in its interface development than ROS distributions.
I don't see the sense in declining user-submissions for the sole reason that they would add a member to
an existing message.
Just to give you a gimpse of the reasoning behind the released version.
If you have concrete ideas for how to improve this, please talk to us about them!
|
|
Could you explain why bumping the minor/major version would avoid that?
it will not avoid that, but very hard to imagine that 0.7.0 and 0.7.1 are
so different.
using minor number for each distribution assuming that we do not change API
during same distro, so if we plan to change them, I think we'd better to
use 0.xx for indigo, 1.xx for jade, and 2.xx for kinetic.
…--
◉ Kei Okada
2016-12-22 18:47 GMT+09:00 Michael Görner <notifications@github.com>:
On Wed, Dec 21, 2016 at 07:38:44PM -0800, Kei Okada wrote:
> Please bump minor/major version when you changed MD5 value, we just had
a MD5 message issue yesterday...
Could you explain why bumping the minor/major version would avoid that?
Is there some mechanism in place somewhere in ROS that checks for that?
I find it really unfortunate that we do not have a way to indicate that
new fields were added to messages.
This is essentially only ABI breakage, but because the messages are
header-only we can't code that in sonames.
- We just introduced (full) sonames in kinetic to get rid of abi problems
in the libraries.
Version numbers in MoveIt is a topic somewhat difficult.
Some people ascribe quality & stability properties to 1.x releases that we
cannot meet at the moment,
so, up to now, we stayed away from the major version number at all.
Also, because we release software for several branches, we want to keep
the version numbers for the different
branches apart. This reserves the minor number (0.7.x for indigo, 0.8.x
for jade, 0.9.x for kinetic).
This only leaves the patch-version for upgrades within a single ROS
distribution.
On the other hand MoveIt is still more fast-paced in its interface
development than ROS distributions.
I don't see the sense in declining user-submissions for the sole reason
that they would add a member to
an existing message.
Just to give you a gimpse of the reasoning behind the released version.
If you have concrete ideas for how to improve this, please talk to us
about them!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAeG3FRIx6fsVn2Yssx95sCSupEAj77Gks5rKkcggaJpZM4HDGQw>
.
|
This is a change related to moveit/moveit_ros#634 and adds a maximum acceleration scaling factor for optionally limiting trajectory acceleration.