Autoware.AI (current Autoware) roadmap

[gbiggs]

This topic is for discussion of the roadmap of the next few releases of Autoware.AI.

Here is some planned points to kick off discussion. I will update this list as the discussion progresses. Each release also has a theme to guide our major changes for that release.

Items are listed in order of priority.

1.11

• Theme: Chaos
• Lots of new features already planned (see the issue tracking the release)
• Build with colcon; remove catkin_make support
• Remove industrial_ci (temporarily, required to build with colcon)
• Deprecate ROS Kinetic support

1.12

• Theme: Source code reorganisation
• Move to using vcstool for install
• Repository reorganisation
• Branching model revision and cleanup of stale branches
• Package re-organisation
• Support ROS Melodic
• Amentifying some packages
• Document CI and testing
  • Gitlab CI
  • Basic simulator-based integration testing
• Conversion of some packages to ROS 2
• Map format improvements/support for Lanelet2
• Model Predictive Controller
• EKF localisation
• CARLA support
• 4-way stop intersection support
• Basic roundabout support

1.13

• Theme: ?
• Add the ros1_bridge as a dependency
• Add Autoware.Auto as a dependency
  • Remove from Autoware.AI features duplicated in and usable from Autoware.Auto
• Remove ROS Kinetic support
• Amentifying some packages
• Conversion of some packages to ROS 2

Future release

• Perception architecture re-design

[esteve]

@gbiggs

Move to using vcstools for install

vcstools or vcstool?

@gbiggs

Add the ros1_bridge as a dependency

We can’t add the ros1_bridge as a dependency unless we also remove Kinetic. The bridge only supports Melodic.

For 1.11 we’ll most likely also have to:

• Either remove industrial_ci or add support for colcon to it (unlikely)
• Remove catkin_make (deprecated in 1.10) from the scripts and announce colcon as the only supported build tool

[esteve]

The libymc_can library can’t be used in Melodic because Ubuntu 18.04 requires PIC libraries, however we only have a binary and not the source code. We’d have to ask Yamaha (IIRC) to provide us with an updated binary.

Disable ymc for ROS Melodic and later

[maximosipov]

It would be great to update documentation in 1.11 to include Gitlab CI testing requirements and also describe some basic integration testing, for example using a simulator.

[gbiggs]

@esteve

vcstools or vcstool?

Sorry, vcstool obviously. Fixed and added a link.

@esteve

We can’t add the ros1_bridge as a dependency unless we also remove Kinetic. The bridge only supports Melodic.

Right, I forgot to shift that to 1.13 during our heated discussion of version numbers. Fixed!

[gavanderhoorn]

@esteve

For 1.11 we’ll most likely also have to:

• Either remove industrial_ci or add support for colcon to it (unlikely)

Seems there is some progress here.

[gbiggs]

@esteve

For 1.11 we’ll most likely also have to:

• Either remove industrial_ci or add support for colcon to it (unlikely)
• Remove catkin_make (deprecated in 1.10) from the scripts and announce colcon as the only supported build tool

I’ve added these. Let me know if you want them added in a different way.

@esteve

The libymc_can library can’t be used in Melodic because Ubuntu 18.04 requires PIC libraries, however we only have a binary and not the source code. We’d have to ask Yamaha (IIRC) to provide us with an updated binary.

Added, although we need to discuss which route to take. Do you know who (at Tier IV, I guess) is responsible for getting the binary from Yamaha?

@maximosipov

It would be great to update documentation in 1.11 to include Gitlab CI testing requirements and also describe some basic integration testing, for example using a simulator

I don’t think that will happen for 1.11, but I’ve put it as an item for 1.12.

[sgermanserrano]

@gbiggs

@esteve

The libymc_can library can’t be used in Melodic because Ubuntu 18.04 requires PIC libraries, however we only have a binary and not the source code. We’d have to ask Yamaha (IIRC) to provide us with an updated binary.

Added, although we need to discuss which route to take. Do you know who (at Tier IV, I guess) is responsible for getting the binary from Yamaha?

@amc-nu has asked for the new binary

[gbiggs]

As part of the repository reorganisation, I think we shall revisit the branching model. I’ll start a topic about it soonish with some options to kick off the discussion. Please don’t start talking about it here - this is just a note that I’m adding it to the roadmap.

[gbiggs]

@sgermanserrano

@amc-nu has asked for the new binary

@amc-nu Any updates on this?

[amc-nu]

I haven’t received it. I’ll keep pushing.

[Dejan_Pangercic]

@gbiggs

Repository reorganisation

This will be painful. What benefit do we expect from it? Same for “Package re-organisation”

@gbiggs

Document CI and testing

Which testing ?

@gbiggs

Remove ROS Kinetic support

Does this mean that we already have Ubuntu 18.04 support?

What you could also do:

1. remove some 200 out of 215 branches Branches · autowarefoundation/autoware · GitHub
2. identify which of above branches have changes in them that never made it back into master. What features those branches hold that would be great to have in Autoware (e.g. ours has 4 way stop intersection handling and 10 other goodies). I know of at least 2 branches:
   1. https://github.com/CPFL/Autoware/tree/feature/pacmod_apex
   2. https://github.com/CPFL/Autoware/tree/experimental/peoria
   3. …

[gbiggs]

@Dejan_Pangercic

This will be painful. What benefit do we expect from it? Same for “Package re-organisation”

Discussion is happening here. There are trade-offs, but we do believe there are identifiable benefits.

@Dejan_Pangercic

Which testing ?

All of it?

There’s so much missing testing that pretty much any testing is welcome. I haven’t had time to put thought into what testing in particular we want, but I think with the work being done on Autoware.Auto, for Autoware.AI I’m happy with unit testing and system integration tests.

@Dejan_Pangercic

Does this mean that we already have Ubuntu 18.04 support?

We are probably going to have unofficial support for Melodic and Ubuntu 18.04 in 1.11. As I recall there are just some issues with Docker remaining, I’m not sure if those have been worked out yet. So having it officially supported in 1.12 is doable.

@Dejan_Pangercic

remove some 200 out of 215 branches

This is already on my list to do for 1.12 as part of cleaning up the repository and issues. I’m going to pare it way way back in the first couple of weeks and then any remainders we will sort out over a longer period. The ideal is that we just have the master branch and a bunch of version tags; it remains to be seen how close we can get to that.

@Dejan_Pangercic

identify which of above branches have changes in them that never made it back into master. What features those branches hold that would be great to have in Autoware (e.g. ours has 4 way stop intersection handling and 10 other goodies).

The creators of unmerged branches are going to get a message asking them to sort out their branches. For ones where the person has vanished, we can try to find someone else to take over updating and PRing that work.

[gbiggs]

@amc-nu

I haven’t received it. I’ll keep pushing.

I think I saw a PR about this. Did you get a new binary?

[amc-nu]

Sorry for late reply.

Yes. PR is here

[Fix] Update YMC library for melodic / not for indigo

@esteve can you check and integrate it in the melodic branch?

[gbiggs]

Thanks, I’ve removed its removal from the roadmap.

Here are some new features targetted for 1.12 that I’ve added:

• Map format improvements/support for Lanelet2
• MPC
• EKF localisation
• CARLA support
• 4-way stop intersection support
• Basic roundabout support

[gbiggs]

Features for 1.12 are being added to the 1.12 milestone. If you have a feature you plan to release in 1.12, then please make a new feature issue (if necessary) and add it to that milestone. We will be grooming and freezing the list of features on April 1st (UTC), so you must get it in by then.