Vehicle Interface meeting

Antonis_Skardasis · 2019-05-21T02:19:03.532Z

The following days we should have a kick off meeting about the vehicle interface, to align our thoughts and the various designs. I have included some people in this email as discussed in the meeting, but please feel free to add anyone else you think will be relevant to attend. Dates and time can be altered to satisfy the majority of people. I would propose the following two options:

A.
San Francisco Friday, 24 May 2019, 07:00:00 PDT
Chicago Friday, 24 May 2019, 09:00:00 CDT
Washington DC Friday, 24 May 2019, 10:00:00 EDT
London Friday, 24 May 2019, 15:00:00 BST
Barcelona Friday, 24 May 2019, 16:00:00 CEST
Tokyo Friday, 24 May 2019, 23:00:00 JST

B.
San Francisco Friday, 31 May 2019, 07:00:00 PDT
Chicago Friday, 31 May 2019, 09:00:00 CDT
Washington DC Friday, 31 May 2019, 10:00:00 EDT
London Friday, 31 May 2019, 15:00:00 BST
Barcelona Friday, 31 May 2019, 16:00:00 CEST
Tokyo Friday, 31 May 2019, 23:00:00 JST

It would be useful to reply back with your availability and a few topics you would like to discuss so to create a draft agenda for the meeting.

Thank you

gbiggs · 2019-05-22T00:10:08.429Z

I can do the 31st, but the 24th is more doubtful.

I would like to discuss the needs placed on the vehicle interface by the Autoware.Auto milestones.

wep21 · 2019-05-27T03:47:56.979Z

I would like to join this meeting. I’m available to join on the 31st.

cho3 · 2019-05-28T14:45:59.041Z

Antonis, thank you for organizing this.

Reposting my questions sent via email:

How much filtering/control should occur at the vehicle interface level?
How much command/control validation should occur at this level?
What is the most appropriate command representation i.e. for throttle/steer angle: Acceleration? Jerk? Wheel angle? Wheel angle rate?
What is the best way to unambiguously represent commands for independently actuated wheels (i.e. individual wheel angles, accelerations/forces)? How can this unambiguously map to simpler platforms? (i.e. 2/1 independent actuations)
Is it reasonable to assume at most 4 wheels in the vehicle for the purpose of control?
How can we report vehicle load, etc. (i.e. inferring that there is a trailer, headwind, incline/decline etc.)?
Does the proposed architecture and separation of concerns make sense?
Does it make sense for the vehicle interface to be the arbiter of vehicle parameters (i.e. tire gradients, wheelbase length, CoG, etc.)? If so, what is the most appropriate way to represent and communicate this?

esteve · 2019-05-28T14:58:43.144Z

@Antonis_Skardasis 31st works for me. Could you add a link to join the call? Thanks.

JWhitleyWork · 2019-05-29T01:48:22.887Z

Unfortunately, I can’t make it. I’m out this Friday helping a family member move.

Antonis_Skardasis · 2019-05-29T23:18:49.299Z

Thank you for your replies and your pms. As it seems we are going for the option B.
I will send calendar event to each one separately and will post the meeting link here in case someone else would like to join. The agenda will be to discuss the .ai implementations, the path to .auto requirements and the questions you have sent.

As a reminder, this is a kick-off meeting. More meetings to follow. So let’s try to keep it top level for now and to 1h duration.

Many thanks.

@JWhitleyWork no worries. We can arrange a short meeting when you have time, to catch up.

cho3 · 2019-05-31T17:09:56.428Z

We agreed that we should define some use cases for the vehicle interface. These use cases can then be used to inform an architecture, and the decomposition of this architecture can be used to define work packages that can be allocated among the members of the working group.

In addition, we provisionally agreed on monthly meetings as we start the planning process of this component.

As a first action item, we should begin collecting and discussing use cases for the vehicle interface in the following gitlab ticket for traceability:

GitLab

Collect use cases for vehicle interface (#85) · Issues · AutowareAuto /...

## Description ### Purpose In order to develop a scalable and cohesive vehicle interface, we must determine the use cases the vehicle interface must satisfy. To do this, we should...

Antonis_Skardasis · 2019-06-03T11:39:32.403Z

Thank you Chris for the notes and the new issue.
@JWhitleyWork feel free to get in contact with me for details. Your views will be useful.

Antonis_Skardasis · 2019-06-27T07:07:40.250Z

For the next meeting I would like to propose the following slot.
I think it is a reasonable solution for all the time zones.
Let me know your thoughts and your availability

San Francisco Friday, 5 July 2019, 07:00:00 PDT
Chicago Friday, 5 July 2019, 09:00:00 CDT
Washington DC Friday, 5 July 2019, 10:00:00 EDT
London Friday, 5 July 2019, 15:00:00 BST
Barcelona Friday, 5 July 2019, 16:00:00 CEST
Tokyo Friday, 5 July 2019, 23:00:00 JST

Thank you
Antonis

gbiggs · 2019-06-27T22:35:55.827Z

That works for me.

JWhitleyWork · 2019-07-01T19:01:43.095Z

Good for me too. It’s a holiday for us but I don’t mind calling in. Can someone please forward the call-in information to jwhitley@autonomoustuff.com and lbaldwin@autonomoustuff.com?

Antonis_Skardasis · 2019-07-05T07:24:29.538Z

Hi Joshua,
You should find the call-in information in the calendar event you received a few days ago.
I copy it here also:
https://meet.google.com/hes-xvne-ydf

JWhitleyWork · 2019-08-07T16:47:55.913Z

Notes from the meeting on 20190726:

Attendees:

Esteve Fernandez (Apex.AI)
Lee Baldwin (AutonomouStuff)
Antonis Skardasis (StreetDrone)
Christopher Ho (Apex.AI)
Josh Whitley (AutonomouStuff)
Daisuke Nishimatsu (Tier IV)

Since AutonomouStuff utilizes its SSC (Speed and Steering Control) software for vehicle interface and control functions, AS is on the group mostly for support and guidance.

AutonomouStuff offered the use of its Automotive Platform Messages (https://github.com/astuff/automotive_autonomy_msgs/tree/master/automotive_platform_msgs/msg) package for “abstracted” vehicle control and feedback. Other alternatives exist so this will be decided upon later.

In discussing physical layer protocols to support for vehicle interfaces, the group decided that CAN will be the primary focus. Others may exist but are not being used by member organizations so abstracting the physical layer messages does not currently seem necessary. The group seemed OK with using the ROS-industry-standard can_msgs/Frame (http://docs.ros.org/melodic/api/can_msgs/html/msg/Frame.html) message for representing CAN frames in ROS. This allows the use of the socketcan_bridge (http://wiki.ros.org/socketcan_bridge) and kvaser_interface (https://github.com/astuff/kvaser_interface) packages for hardware communication.

Action Item (All Members): Circulate list of vehicles to support.
Action Item (Josh Whitley): Create suggested flow diagram for Vehicle Interface layers.