my name is Andreas Lebherz and I’m a master student in ‘Information and Computer Engineering’ at the University of Technology Graz / Austria. My master program is heavily influenced by the topics ‘Automated Driving’, ‘Robotics’ and ‘Embedded Systems’.
In order to finish my studies I need to write a project thesis (before master thesis) and my advisor and I agreed on the implementation of a Ouster OS1 driver for the Autoware stack similar to the Velodyne VLP-16 driver. At the institute I have access to the newest generation of this sensor.
This project should be able to establish a connection the Ouster OS1 sensor and configure it according to given parameters (via .param.yaml file). The conversion functionality is similar to the Velodyne sensor but of course with different packet format and rate.
The current project state is that I have a functioning driver which is able to configure the sensor and convert the Udp data stream into a PointCloud, which can then be visualized in rviz2.
I started working on this topic in early March this year and kind of messed up introducing myself before even starting to work at the project. I already got a lot of help form the Autoware contributers and want to thank everyone that was helping out so far.
My main goal would be to release the driver for the Autoware stack and I welcome any advise in helping me to do so.
I’d like to point out that we don’t want more drivers in Autoware, and we are actively trying to reduce how many drivers we have. We’d prefer drivers to be put somewhere upstream (e.g. the ros-drivers repository, or your own repository if you can maintain and release it) for us to use like any other member of the ROS community.
I’d also like to make it clear that we 100% support new and involved development, please don’t take anything above as critique.
We’re just looking to make sure that we reduce duplicate work in my case and support something that pertains to the most number of users in Geoff’s case.
If you’ve done some great work we’d love to see it and incorporate it and/or allow you to utilize the work also available in the community.
Thanks a lot Geoffrey and Steve for your honest and direct responses. I absolutely don’t take this as critique and am happy to receive your honest opinions.
With this project I am aiming to build a driver that is based on both of your contributions meaning:
The overall structure of the velodyne_driver with separated CloudNode and Translator
Using the ros2 UdpDriver as network interface
Trying to develop a similar unit-test structure
(And of course use upstream functions like the GroundRayFilter and BoundingBoxes)
I feel like using the Autoware developer guidelines (and aiming for a similar project structure) as best practice helps me a lot in getting experience as a developer.
I also want to use parts of the TCP-Configuration functionality from your mentioned Ouster_Driver since for me this seems to be an extremely helpful inclusion. I spent som time with Steves ouster_driver and it helped me a lot in the development process.
Once I finished the documentation and testing I am glad to share everything i have with this community and am more than thankful for any advise and critique on the project.
To reduce duplication in long-term efforts (developing, maintaining, bug fixing, release, general community confusion about which to use when, etc), it would be great if any improvements you wanted to make, we made on this already-released driver. There are already several companies using it, including some that have put in a great deal of time to optimize performance, reliability, and actively helping to upstream changes. This driver is supported by Ouster itself.