Project proposal for WASP-CAT: Coordination of 3 vehicles over C-V2X
==============================

## Overview/Outline
Deadline 30th-sep
Draft 26th-sep

Outline
* Title Proposal
* Problem Description
* Motivation
* Project Proposal
* Scenario Limitations
* Scenario Assumptions
* Problem Decomposition
* Who does what
* Timeplan
* Project Management

## Title Proposal
We propose the project to be titled _**Autonomous Traffic Intersections**_.

## Problem Description
* Traffic lights are inefficient for intersection management.

* Traffic lights enforce a stop-wait-go protocol.
=> Fuel loss and pollution due to idling vehicles.
=> Traffic build up leading to jams.

* Sub-optimal waiting times.
=> Difficult to adapt in real time.
=> No easy way to optimize network of traffic lights.

## Motivation
* Autonomous vehicles can cooperate by relying on a central controller.

* Intersection management possible with simple speed up / slow down commands.
=> Replacing stop-wait-go protocol.
=> Removes the need for traffic lights.

* Several promising studies in simulated environments.
=> MIT Senseable City Lab: http://senseable.mit.edu/light-traffic/
=> https://www.youtube.com/watch?v=4CZc3erc_l4

## Project Proposal
* For the WASP project, we can demonstrate:
=> An autonomous slot-based intersection that demonstrates wireless and vehicle control capabilities.

## Scenario Limitations

### Baseline scenario
* In a baseline scenario we assume that the central scheduler does not get the 'uplink' information about the vehicles, and still assigns timeslots.
* The central scheduler could emulated a case with a traffic light by sending commands for one vehicle to stop before the intersection and then to move when the lights “goes” green. Another vehicle should “see” a green light and drives without stopping.

### Simple case
* To begin with, we will limit us to two (2) vehicles approaching an intersection. They will approach the intersection from perpendicular directions as shown in the figure down below.
* No steering is required only velocity adjustment is needed to let the vehicles cross the intersection in a safe manner.
* The intersection is considered as one block that is occupied fully by one vehicle
* Each vehicle send information to the central scheaduler about its distance to the intersection and its velocity.
* The central scheduler allocates a timeslot to each vehicle to perform its maneuver. The scheaduler assumes the vehicles brake at a constant rate until reachin the intersection. A promise about a timeslot could not be withdrawn, so it should be safe to perform maneuver even when communication is lost.
* Each vehicle calculates its motion plan according to constraints


[//]: <> (#### Subcase)
[//]: <> (:::info)
[//]: <> ([This case may be not needed in the proposal
Paolo: Vehicles could be tested in parallel lines, where no real intersection occurs])
[//]: <> (:::)
[//]: <> (If two real vehicles are available for testing then the simple case could be modified so the vehicles approach the intersection in a manner when their lanes are not intersect, but all assumptions from the simple case are still considered. It would mean that two vehicles would be not allowed to be at the central block at the same time, so the scheduler could be tested, but it should be safe to avoid real collisions.)

### Advanced case
* Tree (3) vehicles are approaching an intersection
* Each vehicle approach the intersection from a different direction, it means there are no vehicles following each other before (and after) the intersection.
* The intersection is considered as several blocks, and it could be shared between multiple vehicles
* In case a new vehicle appears in the communication range of the scheduler the already allocated timeslot could be renegotiated to improve optimality of the solution.
* Each vehicle send information about its capabilities.


## Scenario Assumptions
* The downlink (DL) have multiple antennas, hence we can achieve beamforming.
* Control the beams through an existing API.
* Assume that there exist a detailed map of the intersection in question.
* Data, like high precission GPS, velocity, and acceleration, are availble through a given API.
* The vehicle(s) have working 5G PoC modules, with an interface given to us.
* To start with, the communication link is assumed to be perfect, i.e. no packet loss.
* Since information from cameras and radars/lidars are not available (not used), gps information is the only reliable source for the vehicle. It could send information with emulated noise to the schedule that would adjust safety margins, but it is assumed that the vehicle itself could reliably detect where the intersection starts and ends.

### Plan for recorded videos/executed test
* The baseline scenario with traffic-light-like control
* The simple scenario with assumptions about perfect communication and positioning
* The simple scenario with an emulated noise in positioning
* The simple scenario with an emulated delay in the scheduler
* The advanced scenario with three vehicles and turns in trajectories

## Problem Decomposition
### Who will do what?
* Pavel and Victor will look at the MPC problem given the constraints set by the intersection scheduler.
* Vidit will look at a machine learning approach for beam steering in the DL.
* Christian will look at the scheduler for the intersection, inspired by the MIT project mentioned above.

### Processing units
#### Vehicle
* Performs position estimation
* Send information about its state to the scheduler
* Receives a time slot from the scheduler
* Performs motion planning with constraints from the scheduler
* Executes the motion plan

#### Cloud/Scheduler
* Collects state information from vehicles
* Performs scheduling and assigns time slot to vehicles
* Handle uncertainties to keep the system safe

### Timeline
We plan to visit the facility 5 times. The first visit is more like an orientation and kick-off and could be in a one day visit somewhere before the study trip (before October 15). Preferably one implementation visit could also be done before the study trip to start working on the simple scenario.
Three visits after that could be two days each. One for getting the simple case to work (around mid November) and two visits to focus on the advanced case (beginning and mid December).

The first visit will be spend to get familiar with the test vehicle.
Expected tasks:
* Get introduction and documentation
* Read inputs
* Check that “+” corresponds to the right direction
* Check variables (that steering angle corresponds to wheels’ orientation and in radians)
* Use actuators to drive forward
* (Send commands over 5G)

The second visit, focus on implementing the simple scenario:
* Longitudinal and lateral control with predefined trajectory to follow
* Control and online planning with locally specified timeslot
* Communication with the schedule to receive a timeslot
* Combined testing for parallel lines
* Integration with simulated vehicles?

The third visit, focus on getting the simple scenario to work:
* Bug fixing for the simple scenario
* Recording a video for the simple scenario
* Implementing traffic-light control for the schedual
* Recording a video for the baseline scenario

The fourth visit, steps in the direction of the advanced scenario:
* Test more advanced scheaduler on the simple scenario.
* Test that vehicle path following is suitable for the advanced scenario.
* Test scheaduler feedback renegotiating timeslots.

The fifth visit, making the advanced scenario to work:
* Fix bugs
* ...
* ...
* Recording a video for the advanced scenario

## Project Management
We will version control all code in a git repositories hosted on GitHub as a private project. At the end of the project we can make all code availble publically if it is mature enough.

Since we are distributed over three geographical locations, we will use Slack as a means of communication.

### Meeting Notes
:::info
**2017-09-19: Skype Meeting**
* Henrik: In a baseline scenario assume that the central scheduler does not get the 'uplink' information about the vehicles, and still assigns timeslots. Then show the improvement obtained (if any) with the additional information.
* Paolo: Maintain a minimum level of documentation that makes it possible for others to understand what is done. Priority is on delivering something that works.
* Henrik: 5G POC is more like LTE at physical layer level. How much can we control the lower layer (probably not too much) because it is a commercial system. Handover could be something to explore with ML.
* Paolo: What are the non-idealities that might impact the system (e.g., position errors, network drops, latency, etc.). Make a list and analyze. Good for learning from the project and to show in the demo. Inject faults into the system and see how it responds, e.g. with larger margins etc. Propose schemes with increasing complexity to motivate further work. Focus on "Interaction of control with communication".
* Henrik: Will get hold of the 5G POC specifications.
* Paolo: Completing the project with 2-3 times might be rather optimistic.
* Paolo: Try to construct a high-resolution timeline with specific milestones e.g., related to position sensing, car control, etc. Preparation of experimental setup will take time. Paolo will find out about availability of technitians.
* Henrik: What is the split of the processing: between vehicle/cloud/commuication module, and who takes care of what.
:::

:::info
**2017-09-26: Skype Meeting**
* Paolo: Similar experiments have been conducted at AstaZero before, but using WiFi to set up a LAN. The LAN comprises 3 computers for scheduler and vehicles.
* It is interesting to study: How does scheduler reach to the uncertainities related to positioning, communication resource constraints etc., by increasing the safety margins. Also, possibility of additional vehicles and how study how well the scheudling scales.
* Paolo: Timeline seems reasonable, mail Fredrik well in advance to book time with vehicle / at AstaZero
* Paolo: Can you sketch an architecture of the solution with info flow between the modules, e.g., with what info you need, what is available, etc. What is input of scheduler, what is output, what info is flowing, etc. Where is implementation happening, e.g., in MATLAB / in the 5G module, etc.
* Henrik: Mention which signals are periodic, e.g., positioning, vs. those that are triggered once, e.g., downlink control info etc.
* Paolo: Try to update the layout with nicer documentaion (more like a report/ project proposal)
* Paolo: Contact Ivo, Paolo's PhD student who has worked with the car before.
:::

---