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.
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:
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.
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.
+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.
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.
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.
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?
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:
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.
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.
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.
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.
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.
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.
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!
@project-aslan 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.
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.
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.
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?
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?
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.
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:
@project-aslan 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!