Difference with ros-industrial/abb_experimental version?

[gavanderhoorn]

Out of curiosity: what's the main reason this support package was created in this repository?

It doesn't seem like there are any really significant differences, or at least not ones which couldn't be merged in ros-industrial/abb_experimental.

It seems to follow (almost) the same structure as well, the xacro:macro seems similar and the package also depends on abb_resources (even though that dependency is not stated in the manifest).

[gonzalocasas]

No fundamental reason, we just didn't have the time to go through the reviewing to get it merged. Eventually we will. Also the other variants that we have (https://github.com/gramaziokohler/abb_irb4600_40_255) needs to be checked against abb_experimental and merge differences (if any).

[gavanderhoorn]

Afaict, all IRB 4600 variants are already supported by abb_irb4600_support (here), so I'm not sure there would be anything to merge.

I found https://github.com/gramaziokohler/abb_irb4600_40_255/pull/4 interesting to read, especially since that compares with a variant already supported 'upstream'.

Seeing as that happened, I assumed there was some reason those could not be used, hence my question here.

[gonzalocasas]

As mentioned, it's basically just lack of time (and some legacy): the first of these models we inherited from another team at ETH that had modifications/tweaks that were not (at the time) upstreamed. As you say, it's likely that today, these models are matching and there's nothing to upstream anymore. But at the moment, i don't have the time to check and update our internal projects accordingly so it will have to wait a bit longer.

It's basically the same thing that happens within ROS-I and the _experimental packages: most of those models have been tried and tested for a multitude of years, so it's not about stability anymore, it's just lack of time to upstream.

I have brought this up before, and i would like to point to it again: the barrier to upstream stuff is too high right now. Even internal to ROS-I as pointed out above with the experimental repos. And no, I'm not complaining about your thorough reviews, that's a very good thing; but things just take super long, between the lack of sync between time on the contributor's side and the maintainers side, the extreme caution applied by both sides, etc.

If at all possible, I'm pretty sure that a switch to a more dynamic pace would result in a better ROS-I ecosystem overall. If moving faster speed means things break (sorry for implicitly quoting Zuckerberg), then the answer should be more automated testing/linting/static analysis/etc, instead of stricter human reviewing (which are time-intensive and don't scale well).

[gavanderhoorn]

If at all possible, I'm pretty sure that a switch to a more dynamic pace would result in a better ROS-I ecosystem overall. If moving faster speed means things break (sorry for implicitly quoting Zuckerberg), then the answer should be more automated testing/linting/static analysis/etc,

would you have an idea on how to do this for robot models?

Automating verification is not easy, and has been the main blocker to "just merging" things.

Incorrect joint limits or link lengths have the potential to cause catastrophic failures, hence the reviews.

If we can address that, review effort would go down and merging such contributions would become much easier.

[gavanderhoorn]

I'll close this as it's not really anything actionable here.

Thanks for the information @gonzalocasas.

[gonzalocasas]

Actually, even if there are no differences between this and the upstream repos, I would like to keep this open as a reminder that we need to delete it and update all our references to it.

would you have an idea on how to do this for robot models?

I should sit down and think more in depth, but I think there are options. For instance, iirc ABB publishes the robot's work envelope in STEP files (and other formats as well), so, one way to automatically test for model's correctness would be load it, and run a set of (probably extensive) IK calls to points inside and outside of that published model; if the set matches (ie. points inside the theoretical work envelope and points outside of it have corresponding successful and failed IK solutions), it could be concluded that the model is at least not terribly wrong.

[gavanderhoorn]

it could be concluded that the model is at least not terribly wrong.

yes, but that I can conclude from a visual inspection and isn't too useful.

We've had users open PRs because there was a 0.1 mm length difference in the length of a link. I believe anything automated would only really reduce review effort if it can authoritatively vet a urdf.

[gonzalocasas]

Incorrect joint limits or link lengths have the potential to cause catastrophic failures, hence the reviews.

yes, but that I can conclude from a visual inspection and isn't too useful. We've had users open PRs because there was a 0.1 mm length difference in the length of a link

Some form of automatic checking must be possible and better than current situation. You mention changing link length to be the potential source for catastrophic issues, but on the other hand, 0.1mm length difference cannot really lead to such a massive issue even if it were incorrect, because robots are just not that accurate in real life, so, if someone's process depends on 0.1mm correctness and they haven't taken the measures local to the project to ensure, that's a whole different topic that does not depend on ROS-I's reviewing process.

Anyway, going back to explore options for automatically ensuring models are correct: many vendors have tools that allow to accurate simulate their machines, it would be possible to script a test that compares FK results of the model against that of the simulation, if those match, that is as good as it gets. For ABBs this would be definitely possible because RobotStudio is very close to the real system when simulating it. I believe the same thing goes for Stäubli robots. I have not used URsim or Kukas to judge there.