I'm beginning to migrate a self driving car SW stack that is based on ROS1 to ROS2. Not a lot of people in my company are familiar with ROS2 so I'm on my own for the time being. It's going to be a lot of work but I think it will be a fun journey. I worked on the original ROS1 based project from the beginning so I think I am prepared, but many things have changed in ROS since I started the project so I have a lot to catch up. I will also have to understand the workings of many packages contributed by my previous collaborators too. Wish me luck!
1st2nd
joined 1 year ago
Thanks for your interest :) This is a full scale vehicle project which I participated in its development during my PhD. All my lab colleagues put their own package based on their specializations (perception/decision/control). It actually began as my hobby project when I was frustrated with the lab's legacy MATLAB+LabView based SW and HW. I am now working in a startup company that bought the technology from the lab.
The code works, but the code quality suffers since it's been developed by newbies(most of the lab members are from ME background so their computer skills aren't stellar, and this was everyone's first rodeo with ROS) so the company's goal is to clean up and refactor the codebase while we are updating the system to a modern ROS version. Sadly the company is still small and I hope we get more people on board to speed up the process. On the bright side, I have a lot of opportunities to contribute.
BTW I totally agree with what you mentioned about Python. The old codebase is using ROS melodic which still supported Python 2.7, which makes things even harder. I also have to check if the dependencies are met in new Python versions while updating the code to 3.x versions. One more problem is that when we are deploying our code in our clients' systems we wish to hide our source code as much as possible but Python packages are posing to be a problem in that aspect. I would be happy to hear some tips regarding that issue. Most of our C++ code is fine, but many of our homemade packages are mainly Python scripts.