ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Project ASLAN Open Source Announcement

Hello ROS community!

We are very excited to announce that we just open-sourced a complete self-driving software platform!

It is something we have been working on for quite some time and we are now in a position to say that we have open sourced a stable, fully documented, end-to-end self-driving software stack with an integrated Gazebo simulation and a user-friendly GUI to facilitate software launching. It builds in under 30 mins (or less if you use the docker), just follow the instructions.

Project Aslan is targeting to facilitate the research and development in autonomous driving projects for low-speed applications in urban environments. We are aiming for maximum community engagement, promoting the research in robotics and enabling education in ROS and self-driving cars.

We would like everyone to be a part of this project!!

There are multiple awesome platforms out there and we engage and support all of them.

What we have done differently is that we developed and tested an easy to install, fully documented and stable self-driving software for specific low-speed urban autonomous applications (20mph control speed urban environments). While we couldn’t test during the lockdown, we took the time to improve our simulation and test on the digital twin of the actual DBW vehicle used during testing. To facilitate the users even more, we have released a full set of tutorials at Project Aslan Youtube Channel.

So with just a few clicks on a GUI, you can:

  • Launch a complete self-driving software: Fully documented and tested based on the sense-plan-act robotics top-down approach
  • Record rosbags, build point cloud maps, extract waypoints or just use the ones we have provided: rosbag, point cloud map and waypoints csv
  • Watch the output of the software stack going live in Gazebo sim and RVIZ
  • Develop your own features on top and test them in Gazebo sim or an actual vehicle
  • Be part of something awesome!

Features on this Release:

  • Graphics User Interface (GUI) with integrated ROS tools
  • Docker and Source Code installation
  • Vehicle Model basic urdf for RVIZ
  • Multiple Sensors Drivers
  • Normal Distribution Transform (NDT)* for localization and mapping
  • Voxel Grid and Ground Removal point cloud filtering
  • Path Planning* based on waypoints
  • Object Detection using LiDAR and Radar
  • Route Planning* Algorithm based on A* Planner
  • High-level supervisor/monitor node
  • Vehicle Interface using SocketCAN
  • Comprehensive simulation model and worlds with 3 ways of controlling the robot: keyboard, joystick and the vehicle interface
  • Complete documentation of the source code in the repo and inside the GUI

*Originally suggested at Autoware 1.10.0. These packages have been configured and modified significantly to fit the requirements of Project ASLAN.

Join the community Project Aslan
GitHub project-aslan/aslan
Project Aslan Dockerhub: projaslan/aslan
Online Tutorials: Youtube Channel
Quick Start Resources: rosbag, point cloud map and waypoints csv

15 Likes

This is cool :slight_smile:

1 Like

Hey, this is Josh Whitley. I’m an independent software engineer but I’m currently employed as the Software Architect for The Autoware Foundation. I have a few questions about this project:

  1. How different is your codebase from Autoware.AI 1.10.0 from which it was forked? Many of the files seem to be exact copy-pastes.
  2. What was the impetus behind forming a new organization to work on a clone of Autoware.AI instead of providing input, feedback, and contributions to Autoware.AI?

As a side note, this project has at least one legal problem with code attribution as mentioned in this thread from PCL’s NDT implementation. The AWF has fixed this in Autoware.AUTO but the code that you’re using is prior to that fix and still contains PCL’s implementation without attribution.

10 Likes

+1 for not duplicating work in the same community. Especially if this at some point had heritage with Autoware, it would be an extremely good idea to reintegrate the deep fork. We don’t want to have duplicate efforts occurring to offer similar functionality within a community if there’s a way around it.

9 Likes

Dear Efimia,

Thanks you for your announcement. In full disclosure, I am a representative for the Autoware Foundation.

We found that Project Aslan was forked from the Autoware.ai project (If you look into the source code (e.g. https://github.com/project-aslan/Aslan/blob/master/src/localization/packages/lidar_localizer/nodes/ndt_matching/ndt_matching.cpp ) you will find in lines 2 and 3 the proper attribution of the source file to the Autoware.AI project.) Autoware.AI was released under the Apache 2.0 license and forking the project is obviously possible and we take this as a compliment that Streetdrone likes what we have published!

What we would have preferred though is providing modifications and fixes back upstream into the Autoware.ai project so that the whole Autoware Open Source community benefits from it. Furthermore it would have been nice (but not legally required obviously) if Project Aslan would also attributed the source of this project to Autoware.AI here in this announcement.

13 Likes

I believe that is what the Open Source Project is.

5 Likes

Actually, it’s very disappointing to see this. Looks like streetdrone doesn’t really understand what “open source” means.

As Autoware Foundation member, instead of living up to its commitment to contribute, to be a good open source citizen working with everyone else, Streetdrone decided to fork an early version of Autoware and without proper attribution or upstream the patches, launched not only another ‘forked’ open source project but also another Foundation with itself chairing.

This is exactly the opposite of the spirit of open source community upholds. Just looking through the code, it’s a stripped down version of early Autoware throughout.

4 Likes

Hi @efimiap,

Can you please explain the rationale behind forking Autoware? Do you have a roadmap to explain how your fork will diverge and the main constraints for not contributing or building on top of Autoware?

1 Like

Project Aslan launched yesterday with the hope that we can add to the continued development of autonomous software, specifically for low speed, urban environments. We look forward to welcoming all feedback from individuals and organisations, and we are excited to build productive and collaborative relationships within the wider open source community.

A few points that we’d like to clarify following feedback:

  1. As per above, Project Aslan is specifically designed for operational design domains suited for low speed, urban autonomous driving. This means that Project Aslan encourages development of all software specifically towards this final deliverable.

  2. We do not consider that Aslan is a fork of Autoware, rather it uses some aspects of Autoware 1.10.0 as part of the original StreetDrone technology, donated to Project Aslan (a non-for-profit organisation which holds the assets of Aslan). The current build was a private build by StreetDrone that includes various open-source stacks like StreetDrone’s urdf and vehicle model, Autoware.AI, StereoLabs and Velodyne code that, after testing, was proved to be very helpful for our specific use case - low-speed ODD. This code, having proved to be stable in public road testing, was documented and donated to Project Aslan Ltd by StreetDrone.

  3. Technology - Project Aslan is built and maintained in ROS1, which differs to the currently maintained version of Autoware. Project Aslan will continue to develop in ROS1 beyond the End of Life of Autoware.AI. Currently, Project Aslan does not intend to follow the immediate migration to ROS2 /Autoware.Auto, and anticipates a distinct path based on an ODD-specific roadmap developed by the partners.

  4. In total there are 40 ROS packages in the Aslan GitHub, from which 11 were based on the original Autoware 1.10.0, 10 StreetDrone privately built (or made open source) and 19 others (mostly sensors drivers). We are liaising directly with the Autoware Foundation to work out the best way to incorporate any beneficial changes that we have made back to the original upstream Autoware code.

  5. Membership of Project Aslan and the Autoware Foundation are not mutually exclusive. Speaking on behalf of StreetDrone here only, we intend to continue to contribute to the Autoware Foundation where deemed appropriate, as we have over the course of the 2 years membership with coding, debugging, support and on-going promotion. Project Aslan wishes to foster collaboration as much as possible, and looks forward to hearing all suggestions on how best to do this.

  6. All code that originated from Autoware has all the initial copyrights, licenses and mentions as required by an Apache 2.0 licence. If you can find any code is not attributed correctly (for example the PCL quoted by Josh above) please let us know and we will correct that immediately.

We hope that this clarifies some of the concerns, and justifies our rationale for setting up Project Aslan. Aslan is not intended to replace, nor be competitive to the Autoware Foundation, and we hope that the two offerings will prove complementary, with varied focuses on different operational design domains.

We look forward to further feedback from the open source community, so that we can all move the world towards autonomy and its benefits, faster.

3 Likes

Hi Kasper,

Thank you very much for your question, sounds like a really cool project!

The vehicle interface in Project Aslan, when it’s used on a SD vehicle, it is built to support the peak usb interface and the specific CAN Bus protocol of that vehicle (with more interfaces and cars from other providers hopefully coming soon!).

To be specific:
The sd_vehicle_interface_node receives the /twist_cmd geometry_msgs/TwistStamped topic as output from the GUI. It then translates the message into can_msgs/Frame and publishes it at the topic /sent_messages. The socketcan_bridge_node subscribes to that topic and then passes the can frame to the CAN Bus drive-by-wire vehicle for low level state control (throttle/brake/steer). The socketcan_bridge_node is also receiving the CAN Bus messages from the vehicle, translates them into /received_messages of type can_msgs/Frame which are then being passed to the sd_vehicle_interface_node.
The rqt_graph for your reference:

Please note that the faketwist_node is not included in Aslan, as it was specifically developed for this quick graph demonstration.

IMU and GPS integration is advised on the Vehicle Interface. Please feel free to open an issue on GitHub for specific questions on the code and the engineer who wrote it will be able to reply in more detail.

For your project, the way to move forward is to build your own interface for your mobile robot. You could use the sd_vehicleinterface as an initial guide of how the communication between the Aslan GUI and a vehicle’s CAN Bus is happening.

Of course, if you are interested in making it open source we are more than happy to accept your new feature, and would welcome you as a contributor. Or if you would like to publish it separately, we are more than happy to support it.

Please note, the stack is built using ROS1 Kinetic and if you would like to use ROS2 please do take a look at Autoware.Auto which is currently developing quickly in that direction.

Looking forward to hearing more about your progress!

2 Likes

@efimiap Thank you for the explanation and feedback. As an active and (hopefully) consicenious part of the open-source community we are very happy to see our code being re-used with appropriate licensing and will let you know in the coming weeks if we find additional problems with the copyrights.

However, it sounds like you may have made or been given at least a few incorrect assumptions regarding Autoware Foundation projects: Autoware.AI is our ROS1-based software stack and Autoware.AUTO is our ROS2-based stack. The EOL decision for Autoware.AI was based on the lack of contributions from the community and was only decided 2-3 months ago. Autoware.AI 1.10.0 was released in January of 2019 when the project was still incredibly active. There was no plan at that point to move away from ROS1 or Autoware.AI. In fact, Autoware.AI is still actively maintained (now on Github) and is accepting pull requests with new features until at least the end of 2020. We would be glad to see any improvements from project ASLAN contributed back to the Autoware.AI project but we also understand if your project has diverged too much from the upstream for contributions.

And while I hate to debate numbers with you, I don’t think you’re being very honest about the source of your packages. I did some digging through the ASLAN source code and found 39 package.xml files. Below are listed the paths to each package along with the source of each package. Where I list “AWF” as the source, the code is either 100% copy-pasted from Autoware.AI or has only changes to the messages package name (autoware_msgs -> aslan_msgs). If more substantive changes were made, I mention it with a comment. Those prefixed with CATKIN_IGNORE currently have a CATKIN_IGNORE file in them, meaning they will not be built. However, they are all from sources other than ASLAN/StreetDrone. Where a name other than AWF, ASLAN, or CATKIN_IGNORE preceeds the package name, it was sourced from a public ROS package with that name.

ASLAN - aslan_tools/aslan_build_flags
ASLAN - aslan_tools/aslan_gui
ASLAN - mapping/pcd_loader
ASLAN - supervisor/check_message_alive
ASLAN - vehicle_configuration/models/vehicle_model
ASLAN - vehicle_simulation/gazebo/sd_twizy_model/streetdrone_model/sd_control
ASLAN - vehicle_simulation/gazebo/sd_twizy_model/streetdrone_model/sd_description
ASLAN - vehicle_simulation/gazebo/sd_twizy_model/streetdrone_model/sd_robot
AWF (minor changes) - localization/packages/lidar_localizer
AWF (minor changes) - msgs/aslan_msgs
AWF (originally PCL) - localization/lib/pcl_omp_registration
AWF - localization/lib/ndt_cpu
AWF - mapping/map_tf_generator
AWF - planning/mission/lane_planner
AWF - planning/motion/astar_planner
AWF - planning/motion/waypoint_follower
AWF - planning/motion/waypoint_maker
AWF - sensing/filters/ray_ground_filter
AWF - sensing/filters/voxel_grid_filter
CATKIN_IGNORE - sensing/drivers/camera/pointgrey_camera_driver/image_exposure_msgs
CATKIN_IGNORE - sensing/drivers/camera/pointgrey_camera_driver/pointgrey_camera_description
CATKIN_IGNORE - sensing/drivers/camera/pointgrey_camera_driver/pointgrey_camera_driver
CATKIN_IGNORE - sensing/drivers/camera/pointgrey_camera_driver/statistics_msgs
CATKIN_IGNORE - sensing/drivers/camera/pointgrey_camera_driver/wfov_camera_msgs
CATKIN_IGNORE - sensing/drivers/camera/zed-ros-wrapper/zed_ros
CATKIN_IGNORE - sensing/drivers/camera/zed-ros-wrapper/zed_wrapper
CATKIN_IGNORE - sensing/drivers/radar/umrr_driver
ouster_example - sensing/drivers/lidar/ouster/ouster_client
ouster_example - sensing/drivers/lidar/ouster/ouster_ros
ouster_example - sensing/drivers/lidar/ouster/ouster_viz
pylon_camera - sensing/drivers/camera/camera_control_msgs
pylon_camera - sensing/drivers/camera/pylon_camera
socketcan_bridge and socketcan_interface (plus closed-source library) - vehicle_interface/sd_vehicle_interface
spinnaker_sdk_camera_driver - sensing/drivers/camera/spinnaker_sdk_camera_driver
velodyne - sensing/drivers/lidar/velodyne/velodyne
velodyne - sensing/drivers/lidar/velodyne/velodyne_driver
velodyne - sensing/drivers/lidar/velodyne/velodyne_laserscan
velodyne - sensing/drivers/lidar/velodyne/velodyne_msgs
velodyne - sensing/drivers/lidar/velodyne/velodyne_pointcloud

Given the list of major open-source projects from which code was borrowed and the variety of licenses under which that code was released, I wish you luck making sure you’re in compliance with all of them.

Edit: Adding links to open-source projects.

5 Likes

It is perhaps also relevant here that the Autoware Foundation has never excluded a low-speed, urban ODD for either Autoware.AI or Autoware.AUTO. A strict fork would make more sense if there was some fundamental disagreement about the direction of each work.

Philipp

2 Likes

You said “ We are liaising directly with the Autoware Foundation to work out the best way to incorporate any beneficial changes that we have made back to the original upstream Autoware code”

Liaising with whom? I am the board member of AWF, as far as I know, you never ‘liaised’ to upstream.

“we have over the course of the 2 years membership with coding, debugging, support and on-going promotion”

Can you share the patchset from your contribution in the past two years?

1 Like

Thanks for sharing. I am very interested in a software stack dedicated to smaller autonomous (micromobility) vehicles. What’s your roadmap and plan for the future?

1 Like

Hi everyone,

Thank you very much for the feedback.

We just published a complete Changelog of any alterations we have made to source code originating from open source projects. You can find it here:

Hope it helps! Have a great weekend! :smile:

1 Like

Hi!

At the moment the project is targeting low-speed urban self-driving applications without any specification on the vehicle used. Any feedback and new ideas are more than welcome. Do you have a specific implementation in mind?
Please contact Project Aslan directly at info@project-aslan.com and we can take it from there.

Thanks :smiley:

@efimiap that file doesn’t exist any more in the master branch (and therefore the link is broken)

Good spot! - Thanks for letting me know
We have updated this file to include a complete feature log of the project.
Please find the latest version, here:

@efimiap I see that the the folders in Project ASLAN have been reorganized and now include a git submodule which is a modified, forked version of Autoware.AI version 1.10.0. This is much appreciated. This keeps the licensing very clean and makes the distinction between code provided by Autoware and that provided by the developers of Project ASLAN much more clear. Thank you very much for this change!