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 would like to move the HADMapRoute message to add the route setting service. Also, I think it's hard to understand what the name HADMapRoute stands for. How about renaming it to VectorMapRoute or LaneletRoute?

Purpose

Remove unnecessary dependencies when adding route setting service.

Possible approaches

Move the following messages:

Definition of done

• Add autoware_planning_msgs.
• Remove autoware_auto_planning_msgs.

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

Same as autowarefoundation/autoware_adapi_msgs#56

Expected behavior

Same as autowarefoundation/autoware_adapi_msgs#56

Actual behavior

Same as autowarefoundation/autoware_adapi_msgs#56

Steps to reproduce

Same as autowarefoundation/autoware_adapi_msgs#56

Versions

No response

Possible causes

No response

Additional context

No response

I believe we can apply almost the same settings as autoware_common.
https://github.com/autowarefoundation/autoware_common/tree/main/.github

See autowarefoundation/autoware#99.
Related: https://gitlab.com/autowarefoundation/autoware.auto/autoware_auto_msgs/-/issues/28

@xmfcx edited:

I plan to keep this issue as an epic for the migration and configuration of the messages.

• Control messages
  • #11
• Geometry messages
• Mapping messages
  • #30
• Perception messages
• Planning messages
• Sensing messages
  • #24
• System messages
• Vehicle messages

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

With the introduction of the autoware_perception_msgs, the memory layout of the TrackedObjectKinematics message was changed compared to the old autoware_auto_perception_msgs version, because the orientation_availability property was moved below the various geometry_msgs. Due to this changed memory layout, simply renaming the message type from autoware_auto_perception_msgs to autoware_perception_msgs, e.g., by using the autoware_msg_bag_converter without explicitly setting each property during conversion results in broken objects.

Expected behavior

I expected the memory layout to be the same as before to maintain compatibility with recorded rosbags and the autoware_msgs_bag_converter.

Actual behavior

The values of the converted autoware_perception_msgs/TrackedObjectKinematics message (seen on the left-hand side) are shifted compared to the original autoware_auto_perception_msgs/TrackedObjectKinematics (on the right-hand side)

Steps to reproduce

1. ros2 topic echo of a topic with autoware_auto_perception_msgs/TrackedObjects in a bag
2. Convert bag with the autoware_msg_bag_converter
3. ros2 topic echo of the converted topic with autoware_perception_msgs/TrackedObjects
4. Compare contents of the output

Versions

No response

Possible causes

If the orientation_availability property was placed directly behind pose_with_covariance as before, conversion of bags with TrackedObjects with the autoware_msg_bag_converter would still be possible.

Additional context

No response

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 a common status that can return the success or failure of the service, and the cause if it fails. Currently this is the same as the API status, to avoid dependencies.

bool   success
uint16 code
string message

The field success and message are just like their names. The field code represents the type of error. The status code zero is reserved for success. The status code 50000 or over are also reserved for common errors (e.g. timeout, transform). The other codes can be defined by each service. If success is true and code is not 0, it can be treated as a warning.

Purpose

This status allows standardization of error handling.

Possible approaches

Add the message.

Definition of done

• This message is added.