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.
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?
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.
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:
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
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
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.
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.
