Wish-list for ATOM2 - Githubissues

lardemua / atom

Calibration tools for multi-sensor, multi-modal robotic systems

GNU General Public License v3.0

252 stars 26 forks source link

Wish-list for ATOM2 #544

Open manuelgitgomes opened 1 year ago

manuelgitgomes commented 1 year ago

ATOM is currently being developed in ROS Noetic, which is supported to May 2025. Therefore, it is recommended to start ASAP to port ATOM to ROS2. For that, the creation of ATOM2 must take place.

When creating ATOM2, we should seize the opportunity to do some core software changes. These changes are:

[ ] Removal of link parameter nested inside a specific sensor, as this can be retrieved through the topic
[ ] Detachment of parent_link and child_link (to be calibrated) from specific sensors
[ ] Creation of ground_truth parameter to dataset
[ ] Depth labels - implement delete points feature in the dataset reviewer (#501)
[ ] System evaluation script.
[ ] Structure of ATOM datasets #469

eupedrosa commented 1 year ago

Hi there.

Is the idea to drop noetic before 2025 arrives? Or should a ROS2 version be developed and maintained in parallel? Are the new features only going to the ROS2 version?

manuelgitgomes commented 1 year ago

Hello @eupedrosa!

I believe we have not thought about when to drop support for ROS Noetic. I believe maintaining until 2025 is a given. However, new features might be locked to ROS2.

What is you opinion on this? And yours, @miguelriemoliveira?

eupedrosa commented 1 year ago

I believe that features must exist in both, Noetic and ROS2. Unless some features only can only exist using a certain version of ROS.

Furthermore, until 2025 Noetic should take priority. I believe the user base is wider with ROS1. By only adding new features to ROS2 you may loose some potencial users and even current ones.

The transition to ROS2 is going to be slow.

Nonetheless, it is a nice challenge. It forces you to identify what is independent of ROS and what is not.

miguelriemoliveira commented 1 year ago

Hi @eupedrosa ,

your suggestion makes sense. We should try to develop the ATOM2 (for ROS2) while maintaining the ATOM (for ROS1) on par with the same developments.

The problem I see is the lack of manpower we have, which may mean that we have to prioritize something. In that case I think the priorities should be:

Maintain ATOM as is, to allow users to use it (not including the development of new features, unless they are blocking someone from using ATOM)
Migrate the code to ATOM2
Implement new functionalities and improvements in ATOM2
Mirror the improvements to ATOM

One comment for number 2 and 3. Every time I did a migration procedure like this, I always end up mixing 3 and 4. I mean, when I am migrating I always end up saying, hum, this should work better like this, lets change it. This is a major mistake, which costed me a lot of weeks.

So whenever we endup doing 2, lets make sure we finish it and test it before going to 3.