Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Following these comments from @sykwer in the #282

We TIER Ⅳ members are now working on scheduling issues on Linux platforms. Our opinion is that the task scheduling document should be about how to configure the settings of a kernel scheduler to run Autoware in a predictable way. Based on workload analysis and detailed analysis of the implementation of the Linux kernel, we plan to publish a specialized functionality for the task scheduling of Autoware on Linux and the documentation about it.

Additionally, we need to deal with double scheduling problems (ROS2 executer and kernel scheduler) and scheduler settings for specialized operating systems. We are also struggling with these problems. User-defined and centralized task scheduler will be developed specialized for Autoware.

As a result, we’d like to keep this document blank until the functionality as explained above become fixed.

And this comment from @takam5f2

To my understanding, Autoware is not implemented without considering task scheduling so far. Autoware relies on task scheduling which is managed by ROS 2 and Linux. Task scheduling is one of the issue to be tackled in the future.

It is better, I think, that this section honestly tells that task scheduling is not designed and Autoware runs on a task scheduling by combination of ROS 2 and Linux kernel. "Introducing task optimized task scheduling mechanism and applying it to Autoware are one of our future work" is required statement here.

Purpose

Fill in the documentation for task scheduling.

Possible approaches

Fill in the documentation for task scheduling.

Definition of done

Fill in the documentation for task scheduling.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Some parameters in the sample_vehicle_launch package are missing on page Vehicle Dimensions. Parameters without description are listed below.

vehicle_info.param.yaml

• wheel_tread
• vehicle_height
• max_steer_angle

simulator_model.param.yaml

• simulated_frame_id
• origin_frame_id
• vehicle_model_type
• initialize_source
• timer_sampling_time_ms
• add_measurement_noise
• vel_lim
• vel_rate_lim
• steer_lim
• steer_rate_lim
• acc_time_delay
• acc_time_constant
• steer_time_delay
• steer_time_constant
• x_stddev
• y_stddev

mirror.param.yaml

• min_longitudinal_offset
• max_longitudinal_offset
• min_lateral_offset
• max_lateral_offset
• min_height_offset
• max_height_offset

Purpose

Adding comments makes documentation easy to follow.

Possible approaches

Adding all the parameters that belong to the packages.

Definition of done

Adding all the parameters that belong to the packages.

Currently, Autoware.Auto's documents are written for Autoware.Auto (of course) and GitLab.

However, since autoware.universe has different architecture and uses GitHub, the documents should be updated.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Create guidelines based on https://github.com/orgs/autowarefoundation/discussions/3371.

Purpose

How to configure ROS nodes is non-differentiating, and creating alignment in the AWF community will allow developers and users of Autoware to become more productive as less time will be spent on trivial tasks.

Possible approaches

Add guidelines to

• https://autowarefoundation.github.io/autoware-documentation/main/contributing/coding-guidelines/ros-nodes/parameters/

Definition of done

Once guidelines are live on the web documentation website.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Update the Open AD Kit wiki with more details of e.g., the benefits of developing and deploying Autoware as a microservices architecture

Purpose

Provide more clarity and raise awareness of the benefits microsevices architecture bring to Autoware

Possible approaches

Update the wiki https://github.com/autowarefoundation/autoware-projects/wiki/Open-AD-Kit-working-group

Definition of done

Once changes have been agreed on, reviewed and merged.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Update the current source installation documentation to include how to install and compile differently Autoware with arm64 hardware.

Purpose

For arm64 users, specifying differences in installation of dependencies and changes in build phase.

Possible approaches

Source installation section of the document will be updated for Jetpack users.

Definition of done

Autoware was compiled with a few different steps for Jetson that were not specified in the documentation.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I continuously get questions regarding what is the difference between Autoware AI, Autoware Auto, and Autoware Core/Universe. I thought it would be better if we had a page to describe the background of why we started Core/Universe development and explain history of Autoware distributions

Purpose

To provide information about the differences between AI, Auto, and Core/Universe

Possible approaches

Add a page under "Concepts" page

Definition of done

[ ] Document to explain the difference between different Autoware is available

Follow up from: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/1178

Add some brief documentation on how to create

• point cloud maps
• hd/vector maps

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Update the "Goal" section of Autoware Concept page https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-concepts/.

Purpose

We would like to add details for the Goal section of Autoware Concept page so that developers and users of Autoware would have better idea about the scope of Autoware in high level. This could also become guideline for the architecture design and implementation of the software.

Possible approaches

We do a review from software architects and iteratively update the document.

Definition of done

Goals of Autoware is clarified in the documentation.

Now Autoware.Auto uses Doxygen, but it has some disadvantages:

• UI is not modern.
• Search is slow.
• Some special syntaxes that developers aren't used to are required.
• etc.

Therefore, we'll propose a new documentation platform to use mkdocs-material
The advantages are:

• UI is beautiful.
• Search experience is great.
• Pure Markdown can be used.
• Multiple versions of the documentation are supported.
• etc.

Actually, we've already introduced this in autoware.universe as a trial.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

As current perception interface is empty, I am going to add doc to it if no one else has written.

Purpose

add perception interface on https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-interfaces/components/

Possible approaches

write perception interface doc.

Definition of done

write perception interface doc and merge it .

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I plan write a guids about add a custom ROS2 message.

Purpose

I plan write a guids about add a custom ROS2 message in autoware.

Possible approaches

Adding how-to guides for add a custom ROS2 message.

Definition of done

In progress.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Current coordinate-system.md in directory is empty.
I plan to write a guideline about coordinate system.

Purpose

Write a guideline about coordinate system.

Possible approaches

I plan to write the following:

1. The coordinate system in Autoware(for example map, base_link, sensor coordinate system).
2. An example of how to use TF2 for coordinate transformation in Autoware.

@kenji-miyake Do you have any advice?

Definition of done

TO DO!

As written in #3, we'll change the merge criteria for Core/Universe for more efficiency.

In this issue, we'll propose concrete ideas like:

• Required amount and kind of tests
• Required contents and quality of documentation
• Required code metrics

for each of Core and Universe.

Although Autoware.Auto already has the rules, it should be refined for our new process.
Also, Tier IV has previously proposed some criteria in ASWG, but it's yet high-level.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I plan write localization module interface tutorial in Autoware interfaces/Components page.

Purpose

Writing localization interface.

Possible approaches

Writing localization interface.

Definition of done

prepare.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

As ADASTEC, we are preparing how-to-use documents for open source SLAM implementations. We want to add our documents as subpages to how-to-guides section.

Purpose

Add subpages and how-to-use documents for open source SLAM implementations

Possible approaches

Adding subpages and documentations for each open source SLAM implementation

Definition of done

All subpages and documentations created

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Automatically generate MD table in web documentation from `.schema.json file for ROS node parameters.

Purpose

Using the JSON Schema to generate the parameter table for the web documentation removes the need to duplicate effort.

Possible approaches

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Parameters for Lidar Apollo Segmentation TVM Nodes",
  "type": "object",
  "definitions": {
    "lidar_apollo_segmentation_tvm_nodes": {
      "type": "object",
      "properties": {
        "range": {
          "type": "number",
          "default": 90,
          "exclusiveMinimum": 0,
          "description": "The range of the 2D grid with respect to the origin."
        }
      },
      "required": [
        "range"
      ]
    }
  },
  "properties": {
    "/**": {
      "type": "object",
      "properties": {
        "ros__parameters": {
          "$ref": "#/definitions/lidar_apollo_segmentation_tvm_nodes"
        }
      },
      "required": ["ros__parameters"]
    }
  },
  "required": ["/**"]
}

should be generated to

Definition of done

Once the JSON Schema is generated into a table in the web documentation, see example above.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

According to the current documentation page of Autoware, little information is provided regarding the hardware requirement to run Autoware either in simulation or on real vehicle.

The only mentioned information is the target hardware and prerequisites:

Architecture

• amd64
• arm64

Prerequisites:

• Ubuntu 20.04
• git

Although Autoware is scalable and does not have a universal hardware requirment, it would be helpful to provide some reference hardware platform requirements for Autoware users.

Purpose

Provide reference hardware platform requirements in target platforms and vehicle integration.

This issue was created off the back of an earlier discussion about adding more detail to the hardware requirements.

Possible approaches

Describe at least one reference hardware platform for each architecture:

• amd64
• arm64

amd64 may follow the requirement form AutowareArchitectureProposal

arm64 will be a distributed hardware platform where partial Autoware stack running on each

Definition of done

• Reference hardware requirement for amd64
• Reference hardware requirement for arm64

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Add a new page under 'others' in the 'How to guide', and provide instructions on how to implement a new Localization node.
https://autowarefoundation.github.io/autoware-documentation/main/how-to-guides/#others

Purpose

While the content of Autoware's documentation is comprehensive, the information is not organized when viewed from a specific purpose (in this case, adding a Localization node). The goal of this document is to clarify the process and organize the information related to the workflow.

Possible approaches

Determine the steps necessary for implementing a new Localization node and write the information required at each step.

Definition of done

Write document and merge it.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Follow up from #223

Purpose

Update the naming conventions for namespaces and launch files following discussion in https://github.com/orgs/autowarefoundation/discussions/3171

Possible approaches

Update the documentation following up from #223

Definition of done

PR is merged covering the updates in the discussion.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

In autoware docker installation , when it comes to the section How to setup a workspace, the instructions are using rocker.

Actually this step pull the image (equivalent to docker pull), build something, then start the container.

During the image pull, there is no any progress update bar or any information to tell about that.

Knowing that the image size may exceed 8 GB ... so for a new user it is easily to be interpreted that the rocker command is not doing anything or there is something wrong.

So adding a step before using rocker to do docker pull ghcr.io/autowarefoundation/autoware-universe:latest-cuda then do the rocker step, is way more better as docker pull is actually telling you the pull progress

Purpose

• Fixing long wait without any progress update for new installation / new users using rocker command
• Fixing false impressions that rocker command is not doing anything or something going wrong

Possible approaches

Update the How to setup a workspace section to add docker pull ghcr.io/autowarefoundation/autoware-universe:latest-cuda before rocker step, similar to how to update a workspace

Definition of done

The How to setup a workspace section is updated as described in the task.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

In the Behavior path planner path generation documentation , there are some images and latex equations are not loaded properly.

However, the same image and equations are shown correctly for the same document but in github readme

I will be very beneficial if this can be fixed in autoware documentation as well.

Purpose

Fix the image and latex equations loading for having better reading and understanding of autware documentation

Possible approaches

• Check if autoware.github.io can access the images to be loaded (could be a broken path)
• Check if autoware.github.io have proper rendering plugins for latex equations

Definition of done

To see the same output properly shown in Behavior path planner path generation documentation , as in github readme

Description

Documentation should be updated to include a section explaining how to uninstall Autoware.Auto (and unnecessary dependencies).

Steps Required

• Guide to uninstall Autoware.Auto from source
• Guide to uninstall Autoware.Auto from ade

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Sub ticket of autowarefoundation/autoware.universe#592
Add documentation for using calibration tools

Purpose

Create instructions for calibration tool so that users can generate calibration parameters for sensors.
This includes:

• Intrinsic parameter for cameras
• extrinsic parameter between cameras (camera-camera calibration)
• extrinsic parameter between lidars (lidar-lidar calibration)
• extrinsic parameter between a camera and a lidar (camera-lidar calibration)

Definition of done

• Documentation of intrinsic camera parameters available
• Documentation of camera extrinsic parameter calibration (camera-camera calibration) available
• Documentation of extrinsic parameter between lidars (lidar-lidar calibration) available
• Documentation of extrinsic parameter between a camera and a lidar (camera-lidar calibration) available

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Creating vehilce and sensor description is empty, I'm going to add document it.

Purpose

Adding specific instructions for creating vehicle and sensor descriptions.

Possible approaches

The following three explanations.

• Description of vehicle_description configuration.
• Description of sensor_description configuration.
• Description of individual_parameter, how to be used in sensor_description.

Definition of done

write document and merge it.

We'll send PRs for each item and discuss them in the PRs.

• Change formatters to clang-format and Black
• Change C++ namespace rule to be the same as the package name
• Change the package rule not to split core/node packages
• Replace ade with pure Docker in the installation section -> #18
• Write coding guidelines for each language
  • Common(naming etc.)
  • C++
  • Python
  • Markdown
  • etc. (Images, Shell Scripts, GitHub Actions)
• Write coding guidelines for ROS node
• Update documentation guidelines
  • It's worth discussing whether we really need Doxygen comments for all header files. (In other words, what the public APIs of Autoware's packages are.)
• Update testing guidelines -> #39
• Update contribution guidelines
  • Workflow -> #45
  • Commit rules #47
• Update how to write license notations -> autowarefoundation/autoware#29
• Update code of conduct to v2.1 -> autowarefoundation/autoware#29
• Update support guidelines to use GitHub Discuttions (proposing in #7)

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Follow up from autowarefoundation/autoware_msgs#48 (comment)

Purpose

To make it clear how we name plural messages.

from @isamu-takagi

Many of the ros messages use Array sufix, so I think it's better to match them.

diagnostic_msgs/msg/DiagnosticArray
geometry_msgs/msg/PoseArray
visualization_msgs/msg/MarkerArray

Possible approaches

Edit https://autowarefoundation.github.io/autoware-documentation/main/contributing/coding-guidelines/ros-nodes/message-guidelines/

Definition of done

Docs is updated.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

There are some errors.
https://github.com/autowarefoundation/autoware-documentation/runs/5800485685?check_suite_focus=true

Purpose

To resolve the errors.

Possible approaches

Replace links.

Definition of done

There is no CI error.

The current support guideline says we use ROS Answers for user support.
However, few people watch it and the responses are not good.

So we've proposed to use GitHub Discussions at the December TSC.

Also regarding the communication platform, Fatih-san has proposed to use Discord instead of Slack at the December TSC. It's under discussion.

It's discussed here.

I believe the discussion result should be organized like this.
(Autoware.Auto doesn't have such high-level documentation, but a bit similar one is this.)

Also regarding the messages, writing rationales like autoware_auto_msgs is nice.
But if possible, I feel a bit more detailed rationales are better.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Update current documentation to include how to do docker installation of Autoware with arm64 hardware .

Purpose

Update guide for arm64 hardware users.

Possible approaches

Document will be updated based on implementation result of Jetson AGX Xavier

Definition of done

Guideline provided for arm64 users to install autoware using docker method.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Related: autowarefoundation/autoware.universe#567 (comment)

There is no documentation about how to use control_performance_analysis package.

Purpose

Adding documentation about how to use control_performance_analysis package.

Possible approaches

Adding documentation about how to use control_performance_analysis package.

Definition of done

As discussed at the December TSC, we'll introduce explicit prototyping phases and change the merge criteria.

However, with the limited information, people cannot concretely understand how and how much Autoware will get high-quality and safety. We have to show a roadmap to the goal so that everyone can understand and agree.

Specifically, since the current Autoware.Auto's rules seem to be biased to ISO 26262, we'll propose comprehensive system-wide approaches like ISO/PAS 21448 and ISO/TR 4804.
We have to recognize we cannot build a perfect system from the beginning and that it requires some iterations.

To accomplish the approach, there are a lot of tasks. We should take the balance of each activity and improve the quality step by step.
Also, since it's difficult to guarantee everything by AWF with its limited resources, we have to show the area of responsibility and what is required for the users.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Update current documentation to include how multi-stage builds can be used with Autoware.

Purpose

Ensure that users and developers can build the Autoware container image using the newly developed multi-stage build process.

Possible approaches

TODO

Definition of done

When there are instructions enabling a developer to make changes to the multi-stage build process.

Blocked by

autowarefoundation/autoware#2447
(until changes have been made to enable multi-stage builds in Autoware CI/CD on GitHub, documentation cannot be written)

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

We AutoCore members are willing to contribute ourselves to preparing this part regarding: https://autowarefoundation.github.io/autoware-documentation/main/installation/related-tools/

However, we are not that clear about the definition of "related tools". Do these tools refer to some third-party tools / dependencies during installation such like pcl-tools or something else?

Purpose

Get clear about the scope of "related tools"

Possible approaches

TBD.

Definition of done

Prepare docs

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Writing guidelines about ros2 console-logging.

Purpose

Current console-logging.md in autowarefoundation/autoware-documentation/tree/main/docs/contributing/coding-guidelines/ros-nodes is empty.

Possible approaches

Writing guidelines in console-logging.md

Definition of done

finisih writing

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Write a guideline about ros2 topic namespaces.

Purpose

Current topic-namespaces.md in autowarefoundation/autoware-documentation/tree/main/docs/contributing/coding-guidelines/ros-nodes is empty.

Possible approaches

Write a guideline about ros2 topic namespaces.

Definition of done

Finished writing.

#40 (comment)
https://developers.google.com/style/person?hl=en

~/ghq/github.com/autowarefoundation/autoware-documentation main
❯ ag " our"
docs/contributing/index.md
28:To ensure our community stays open and healthy, we adhere to the [Contributor Covenant](https://www.contributor-covenant.org/), a widely used [code of conduct](https://github.com/autowarefoundation/autoware/blob/main/CODE_OF_CONDUCT.md) adopted by many other communities listed [here](https://www.contributor-covenant.org/adopters/).
52:See our [support guidelines](../help/support-guidelines.md) for the detailed steps.
68:See our [pull request guidelines](pull-request-guidelines/index.md) for the detailed steps.

docs/contributing/pull-request-guidelines/index.md
8:The following is a general example of our pull request workflow.
15:   - Follow our guidelines when you write code, tests, and documentation.
19:   - Follow our [Commit guidelines](commit-guidelines.md) when commit your change.
28:   - The reviewers will review your code following our [review guidelines](review-guidelines.md).
80:See our [commit guidelines](commit-guidelines.md) for the detailed rules.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

This proposal outlines the need for a defined versioning system for autoware_msgs. It will also cover how various packages and tools that interact with autoware_msgs can adapt to this versioning system.

This proposal serves as a follow-up from:

• autowarefoundation/autoware.universe#3787 (comment)

cc. @mitsudome-r @isamu-takagi @wep21 @kenji-miyake @TakaHoribe @mehmetdogru @kaancolak @miursh

Purpose

• Establish a robust version control mechanism for autoware_msgs to improve source control and make updates transparent and trackable.
• Define a transition process for tools/packages that interact with autoware_msgs to adapt to changes or updates, ensuring smooth integration and avoiding potential conflicts.
• Create a solid foundation for future development and expansion of the autoware_msgs package.

Possible approaches

1. Semantic Versioning (SemVer): Implement Semantic Versioning (major.minor.patch), providing clarity about backward compatibility and allowing easier integration for packages interacting with autoware_msgs.

2. Release Branching: Create release branches for autoware_msgs for each major version. This allows for bug fixes and minor updates to be added to previous versions without disturbing the main development.

Definition of done

• A comprehensive document outlining the chosen versioning system and the rationale behind it is drafted.
• Autoware developers have reviewed and approved the proposal.
• The document is merged into the project repository as an official guide for autoware_msgs versioning system.

Since we'll move from Autoware.Auto to Core/Universe soon, we should update the documents for that.

This is the high-level list of items that I think we should discuss for Core/Universe.

Firstly, we have to make a common understanding of the Core/Universe strategy.

• #2
• #3

After that, we'll revisit some items to match the strategy.

• #4
• autowarefoundation/autoware#5
• autowarefoundation/autoware#2411
• autowarefoundation/autoware#7

Then, we'll update the documents (mainly user manuals) for autoware.universe.

• autowarefoundation/autoware#8

Also, toward the incoming Bus ODD development, we have to write some design documents and prepare a development environment.

• autowarefoundation/autoware#9
• autowarefoundation/autoware#10
• autowarefoundation/autoware#2414

Note: Although I wrote this like a waterfall process, we can work on each task in parallel.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I'm going to prepare docs about "Create an Autoware package" in "how to guide". However, I'm not sure if I understand this part correctly. Is this section to guide new user how to customize his own project based on Autoware (msgs, tools, etc..) or instruct people how to become an Autoware code contributor?

Purpose

Get clear of the scope.

Possible approaches

TBD

Definition of done

completion of docs

Follow up from https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/573

Description

Disabling tests should be done via DISABLE_ prefixes on tests so that they aren't forgotten.

Expected behavior

The Developer's Guide should contain this information.

Definition of Done

• Add information about using the DISABLE_ prefixes to the Developer's Guide

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I want to add a documentation guideline in the following content to make the instructions clear.

Purpose

Provide clear contribution instructions to the developers

Possible approaches

Add the following content to the documentation guideline page

Documentation guidelines

Instructions to add documentation

• If you have knowledge about Autoware usage or functionality, or if you have a question about Autoware, and once it is resolved, turn the knowledge into the documentation!

There are two ways to contribute to the documentation page.

1. If you can make a documentation page based on your knowledge, please send a pull request. If you are unaware of if you can open a pull request or unaware of the format, you can ask on the feature requests page.
2. If you are curious about what to write or whether your contribution is worthwhile or not, you can ask on Q&A page.

Definition of done

• Developers can clearly understand the contribution instructions
• Cover basic cases, such as in which case to open a pull request, or in which case to open a discussion

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

plan write map module interface tutorial in Autoware interfaces/Components page.

Purpose

Write map interface

Possible approaches

Write map interface

Definition of done

Writing

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Writing guidelines about interactive dummy objects.

Purpose

Current planning-simulation.md in autowarefoundation/autoware-documentation/blob/main/docs/tutorials/ad-hoc-simulation/planning-simulation.md does not explain how to use dummy objects interactively.

Possible approaches

Writing guidelines in planning-simulation.md

Definition of done

Finish writing

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Closes: autowarefoundation/autoware.universe#1253

autowarefoundation/autoware.universe#1253 (comment)

Purpose

autowarefoundation/autoware.universe#1253 (comment)

Possible approaches

autowarefoundation/autoware.universe#1253 (comment)

Definition of done

autowarefoundation/autoware.universe#1253 (comment)

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

I plan to add the Autoware installation video tutorial in here, but the Autoware installation tutorial document is relatively complex. Even the Docker based installation tutorial requires a lot of additional dependencies, which is very unfriendly to beginners.

Autoware Universe now mostly provides images of the prebuilt version (image link). Based on this image, you do not need to download the source code of Autoware, and you can run Autoware without compiling. So can I record Autoware installation videos based on the prebuilt version images?

Autoware installation documentation (here) needs to be updated?

@kenji-miyake Do you have any suggestion?

Purpose

Add video of Autoware installation tutorial.

Possible approaches

Add video of Autoware installation tutorial.

Definition of done

TO DO.

Before writing design documents in #10, we have to discuss the format.

I feel Tier IV's proposal could be the base, but it should be refined a bit more.

The comments in #10 (comment) should be addressed as well.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

There is a question in Q&A might be frequently asked, i.e.: user thought stderr means build failure.
https://github.com/orgs/autowarefoundation/discussions/3269
autowarefoundation/autoware#3282
https://github.com/orgs/autowarefoundation/discussions/2731
autowarefoundation/autoware#2726

Therefore I wonder whether we should create FAQ section that specifically explains about the duplicated question.

Purpose

To reduce number of duplicated question and has a page that provides explanation so that contributor can provide link to the answer.

Possible approaches

1. Create and FAQ page.
2. Warns the user to search the FAQ first before placing their question.

Definition of done

FAQ page created

Seeing the current Autoware.Auto's documentation, some information is dispersed and some information is unnecessary.

It should be refined so that people can easily access the information they want with no confusion.

This issue addresses the tree structure and we'll consider each content in #6.