Car Control

The goal of this project is to create an applictation that will read inputs from multiple sources and control the piracer vehicle. Also this application aims to provide vehicle's status to other applications via CommonAPI.

Tabel of Contents

• Introduction
• User Functionallity
• CommonAPI
• Dependencies
• References

Introduction

The following tree shows the project structure.
This application uses Convesa's Common API to connect the PiRacer's drivetrain to the on-board network.

car_control
├── build 
├── fidl
│   ├── car_control.fidl 
│   ├── car_control.fdepl 
├── include 
│   ├── CarControlStubImpl.hpp 
│   ├── GamePad.hpp 
│   ├── PiRacer.hpp 
├── piracer 
│   ├── gamepads.py
│   ├── vehichles.py
├── scripts 
│   ├── Build.sh 
│   ├── Run_Client.sh 
│   ├── Run_Services.sh 
├── src 
│   ├── CarControlClient.cpp 
│   ├── CarControlService.cpp 
│   ├── CarControlStubImpl.cpp 
│   ├── GamePad.cpp 
│   ├── PiRacer.cpp 
├── src-gen/v0/commonapi 
│   ├── core 
│   │   ├── CarControl.hpp 
│   │   ├── CarControlProxy.hpp 
│   │   ├── CarControlProxyBase.hpp 
│   │   ├── CarControlStub.hpp 
│   │   ├── CarControlStubDefault.hpp 
│   ├── someip 
│   │   ├── CarControlSomeIPDeployment.cpp 
│   │   ├── CarControlSomeIPDeployment.hpp 
│   │   ├── CarControlSomeIPProxy.cpp 
│   │   ├── CarControlSomeIPProxy.hpp 
│   │   ├── CarControlSomeIPStubAdapter.cpp 
│   │   ├── CarControlSomeIPStubAdapter.hpp 
├── CMakeLists.txt 
.github 
├── workflows 

The application uses the python modules gamepads.py and vehicles.py from SEA:ME (see: [1]) and Convesa's CommonAPI that runs on C++. To connect python and C++, the Boost.Python libary is used. Boost.Python is a C++ library which enables seamless interoperability between C++ and the Python programming language.
Read the follwing [2] if you want to know more about it.

User Functionallity

This section describes the application's user functionallity.
The car's drivetrain is controlled by Gamepad and Head Unit inputs.
Steering and acceleration are set with the joysticks.
Changing lanes can be indicated by a button push of L1 (left indicator) or R1 (right indicator).
The car's gear is selected by the X (Neutral), A (Drive), B (Park), and Y (Reverse) buttons.
If the car is in Drive ("D"), the car will drive forward - In Reverse ("R"), the car will drive backwards. The right joystick needs to be pushed in the corresponding direction to accelerate. Hence, the car will not move if the Joystick is pushed backwards while "D is selected. The same rule apply for the gear selection reverse ("R") just in reverse. Last but not least, in Park ("P") & Neutral ("N"), the car will not move at all.

Button	Action
Left Joystick	Steering
Right Joystick	Throttle
L1	Left Indicator
R1	Right Indicator
X	Neutral ("N")
A	Drive ("D")
B	Park ("P")
Y	Reverse ("R")

CommonAPI

The communication between the Head Unit and the Car Control is based on the vSOME/IP protocol.
The application "Head_Unit" (in the following titled as "Head Unit") acts as a client and application "Car_Control" (titled as "Car Control") runs as a services.
The vSOME/IP interface of the application car control is definfied in the .fidl file.
The interface contains two attributes "indicator" and "gear" as well as a method called "gearSelectionHeadUnit".
A client can subscribe to the attributes to get notified about changes.
By invoking the method "gearSelectionHeadUnit", the client (in this case Head Unit) can request the car's gear via synchronous call.

package commonapi

interface CarControl {
    version { major 0 minor 1 }

    attribute String indicator readonly
    attribute String gear readonly
    
    method gearSelectionHeadUnit {
        in { 
            String selectedGear
        }
        out { 
            Boolean accepted
        }
    }
}

The Head Unit can invoke the method "gearSelectionHeadUnit" on the service side to set the gear.
In the Request-Resonse communication, the Head Unit will sends a request with the selected gear ("D", "R", "P", "N") to the service. The service will response with "true" if the gear change was accepted.

 --------------------------- 
Result of synchronous call: 
   callStatus: SUCCESS
   Input Gear:  R
   Output Gear Change accepted: 1
 ---------------------------

The service receives the request and checks if the car is in motion. If the car is not in motion, the car will accept the gear change.

 ---------------------------
Head Unit invoked service method & tries to set gear.
  Input Gear: R
->Gear change accepted.
 ---------------------------

Next, the service will set the attribute "Gear" to the selected gear. All clients which subscriped to this attribute will recieve a notification about the change.

 ---------------------------
Service Notification: 'Gear' changed to : R
 ---------------------------

A gear change request will be declined, if the car is still in motion. Therefore, the output of the client's synchronous call will false.

 ---------------------------
Result of synchronous call: 
   callStatus: SUCCESS
   Input Gear:  D
   Output Gear Change accepted: 0
 ---------------------------

The same rules applies for a gear change input made by the Gamepad.

 ---------------------------
GamePad tries to set gear. 
  Input Gear: R
->Gear change declined.
 ---------------------------

If the shoulder button L1 is pressed, the service will notify the client about the change of the attribute "Indicator". The attribute indicator toggles between the selected direction ("Left" in case of L1) and "None" if the button is released.
The same rules applies for the shoulder button R1.

 ---------------------------
Service Notification: 'Indicator' changed to : Left
 ---------------------------

 ---------------------------
Service Notification: 'Indicator' changed to : None
 ---------------------------

Dependencies

• Piracer-py
• Boost.Python
• vSOME/IP v3.4.10
• CommonAPI Core Runtime v3.2.3
• CommonAPI SOME/IP Runtime v3.2.3

References

[1]: SEA-ME Piracer
[2]: Boost
vsomeip in 10 minutes
CommonAPI wiki