diff options
15 files changed, 634 insertions, 277 deletions
diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/11_Building_for_EC2_arm64_and_x86-64.md b/docs/01_Getting_Started/02_Building_AGL_Image/11_Building_for_EC2_arm64_and_x86-64.md new file mode 100644 index 0000000..8e22274 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/11_Building_for_EC2_arm64_and_x86-64.md @@ -0,0 +1,155 @@ +--- +title: Building for AWS EC2 (arm64 or x86-64) +--- + +Building an image for emulation allows you to simulate your +image without actual target hardware. In this case using an EC2 instance. + +This section describes the steps you need to take to build the +AGL demo image for emulation using EC2 either for arm64 or x86-64. + +In the commanline examples below, we will focus on aws-ec2-arm64 primarily. +If you need x86-64, then replace it with aws-ec2-x86-64 likewise. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" +section presented generic information for setting up your build environment +using the `aglsetup.sh` script. +If you are building the AGL demo image for emulation, you need to specify some +specific options when you run the script: + +**Sample Qt based IVI demo :** + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m aws-ec2-arm64 -b build-aws-ec2 agl-demo agl-devel +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ ln -sf $AGL_TOP/site.conf conf/ +``` + +**IVI-EG Flutter based demo :** + +``` +$ source meta-agl/scripts/aglsetup.sh -f -m aws-ec2-arm64 -b build-aws-ec2 agl-demo agl-devel +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ ln -sf $AGL_TOP/site.conf conf/ +``` + +The "-m" option specifies the "aws-ec2-arm64" machine. +The list of AGL features used with script are appropriate for development of +the AGL demo image. For production use, you need to omit agl-devel and tailor your image. + +## 2. Using BitBake + +Start the build using the `bitbake` command. + +**NOTE:** An initial build can take many hours depending on your +CPU and and Internet connection speeds. +The build also takes approximately 100G-bytes of free disk space. + +**Sample Qt based IVI demo :** +The target is `agl-ivi-demo-qt`. + +``` +$ time bitbake agl-ivi-demo-qt +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as `$IMAGE_NAME`: + +``` +<build_directory>/tmp/deploy/images/aws-ec2-arm64/agl-ivi-demo-qt-aws-ec2-arm64.rootfs.wic.vhd +$ export IMAGE_NAME=agl-ivi-demo-qt +``` + +**IVI-EG Flutter based demo :** +The target is `agl-ivi-demo-flutter`. + +``` +$ time bitbake agl-ivi-demo-flutter +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as $IMAGE_NAME: + + +``` +<build_directory>/tmp/deploy/images/aws-ec2-arm64/agl-ivi-demo-flutter-aws-ec2-arm64.rootfs.wic.vhd +$ export IMAGE_NAME=agl-ivi-demo-flutter +``` + + +## 3. Deploying the AGL Demo Image + +Deploying the image consists of uploading the image to S3 and +conversion to to an AMI image. The whole process is done using +a script out of meta-aws . Next you need to start a new instance +using your new image. +The image is setup to expose its screen over rdp. This is ok for +development, but you need to keep security in mind when configuring +the EC2 security groups and/or tunnel over ssh. + + + +### 3.1 Uploading using create-ec2-ami.sh + +The script required to upload the resulting image is part of meta-aws in the subfolder scripts/ec2-ami/. + +**It has a few requirements that you need to setup first.** + +**These are documented in the [Readme there](https://github.com/aws4embeddedlinux/meta-aws/blob/scarthgap/scripts/ec2-ami/README.md).** + +**Read it and set it up accordingly.** + +The script itself is called creat-ec2-ami.sh and takes 4 arguments: +* your S3 bucket name +* the size of the AMI (don't make it too small) +* the target image name +* the machine name + +``` +Example run +../bsp/meta-aws/scripts/ec2-ami/create-ec2-ami.sh my_s3_bucket 8 agl-ivi-demo-flutter aws-ec2-arm64 +``` + +After this process is complete, your image is available as AMI to you (only to you). + +### 3.2 Configuring within AWS EC2 + +In your EC2 dashboard go the the same region as you configured the upload for, +select "Launch instance" and enter a name. + + + +Select under "My AMIs" the uploaded AGL image in question. Select an instance type +that is big enough (>= 4GB RAM, 8GB RAM recommended). + + + +Select your key pair, select the security group. + + + +Finally start the instance. + +**Note1: AWS serial console does not help as you have no root password available until you reset it.** + +**Note2: You cannot connect as 'root' (as shown in the connect tab) - you have to substitute 'root' with 'user'.** + +**Note3: There is no web output, you need to use RDP. See below ...** + + +### 3.3 Connecting via RDP + +For security reasons, you should always tunnel over ssh. + +For this, connect using 'ssh -i "yourkey.pem" -L 3389:localhost:3389 user@publicIPofSERVER' . + +Then use an rdp client and connect to 'localhost' . + +### 3.4 Security considerations + +As mentioned above, do not expose port 3389 to the internet by opening up the port. diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/11_Available_Demo_Images.md b/docs/01_Getting_Started/02_Building_AGL_Image/21_Available_Demo_Images.md index 32ebb6c..32ebb6c 100644 --- a/docs/01_Getting_Started/02_Building_AGL_Image/11_Available_Demo_Images.md +++ b/docs/01_Getting_Started/02_Building_AGL_Image/21_Available_Demo_Images.md diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/12_Available_KVM_Demo_Images.md b/docs/01_Getting_Started/02_Building_AGL_Image/22_Available_KVM_Demo_Images.md index ce8bb44..ce8bb44 100644 --- a/docs/01_Getting_Started/02_Building_AGL_Image/12_Available_KVM_Demo_Images.md +++ b/docs/01_Getting_Started/02_Building_AGL_Image/22_Available_KVM_Demo_Images.md diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/1_EC2_dashboard.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/1_EC2_dashboard.png Binary files differnew file mode 100644 index 0000000..6a5341b --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/1_EC2_dashboard.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/2_start-instance-1.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/2_start-instance-1.png Binary files differnew file mode 100644 index 0000000..89e38ad --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/2_start-instance-1.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/3_start_instance-2.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/3_start_instance-2.png Binary files differnew file mode 100644 index 0000000..3387182 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/3_start_instance-2.png diff --git a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/01_Instrument_Cluster_(IC-IVI_with_Container_isolation).md b/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/01_Instrument_Cluster_(IC-IVI_with_Container_isolation).md index bca5ef6..e44e2a9 100644 --- a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/01_Instrument_Cluster_(IC-IVI_with_Container_isolation).md +++ b/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/01_Instrument_Cluster_(IC-IVI_with_Container_isolation).md @@ -31,13 +31,10 @@ table2. | Board type | Support integration type | status | |:---:|:---:|:---:| -| AGL RefHW | 1,2a,3a,3b | Tested | +| AGL RefHW | 1,2a,3a,3b | Tested. | | R-CarH3 Starter Kit with Kingfisher board | 1,2a,3a,3b | Not tested. | -| R-CarM3 Starter Kit with Kingfisher board | 1,2a,3a,3b | EOL Board. Not tested. | -| R-CarH3 Starter Kit | 1,2a | End of Supported in latest release. | -| R-CarM3 Starter Kit | 1,2a | EOL Board. End of support in latest release. | | Raspberry Pi4 (4G or 8G) | 1,2a,3a,3b | Tested. | - +| NanoPC-T6 (4G or 8G or 16G) | 1,3a,3b | TODO. | We recommend to choice AGL RefHW or Raspberry Pi4 (4G or 8G). @@ -99,7 +96,9 @@ If your board is Raspberry Pi4, please skip this step. #### 7-1: Downloading Proprietary Drivers from [Renesas-automotive-products](https://www.renesas.com/us/en/products/automotive-products/automotive-system-chips-socs/r-car-h3-m3-documents-software). -In case of Optimistic Octopus and master, please download this. +In case of master, please download this. + +***Note. Latest AGL use same binary as kirkstone.***  @@ -210,7 +209,6 @@ agl-ivi-demo-qt, agl-ivi-demo-flutter and agl-ivi-demo-html5. ```bash $ bitbake agl-ivi-demo-qt $ bitbake agl-ivi-demo-flutter -$ bitbake agl-ivi-demo-html5 ``` #### 3rd step: Set deploy path of AGL IVI Demo to IC side config. @@ -260,7 +258,7 @@ Renesas propriety license limitation. Download IVI guest images from this link. [[Prebuild AGL Demo IVI container images for Raspberry Pi -4.]](https://drive.google.com/file/d/1uXel0K9_IK7SAEc8msKyXvNWhFRWgF4C/view?usp=sharing) +4.]]() Extract download tar.bz2 archive to any directory. @@ -314,48 +312,74 @@ card device is /dev/mmcblkX may be. ## 7. How to use container exchange UI. -### 7a. Momi Web +IC container integration has three method for container exchange. -The Momi web is a web interface for container exchange. When you want -to use Momi web, you must connect network between board and -PC/Tablet/Phone. +| No. | Method | Refer to | +|:---|:---|:---| +| 1 | Command line interface | Sub section 7a. | +| 2 | Web UI | Appendix 3. | +| 3 | Key board UI | Appendix 4. | -**The Momi web is completely demo feature, that open many security hole. - You shall not use out of standalone demo.** -#### 1st step: Check IP address in your board. +### 7a. How to change guest using command line interface -After booting, you check IP address in your board. +The cmcontrol is a command line interface for the container manager. It supports container listing, shutdown, reboot, force reboot, and active guest change. ```bash -root@raspberrypi4-64:\~# ifconfig\ -eth0 Link encap:Ethernet HWaddr E4:XX:YY:ZZ:WW:VV\ - inet addr:192.168.10.128 Bcast:192.168.10.255 - Mask:255.255.255.0 +$ cmcontrol +usage: [options] + + --help print help strings. + --get-guest-list get guest container list from container manager. + --get-guest-list-json get guest container list from container manager by json. + --shutdown-guest-name=N shutdown request to container manager. (N=guest name) + --shutdown-guest-role=R shutdown request to container manager. (R=guest role) + --reboot-guest-name=N reboot request to container manager. (N=guest name) + --reboot-guest-role=R shutdown request to container manager. (R=guest role) + --force-reboot-guest-name=N reboot request to container manager. (N=guest name) + --force-reboot-guest-role=R shutdown request to container manager. (R=guest role) + --change-active-guest-name=N change active guest request to container manager. (N=guest name) ``` -In this case, this board set IP address by 192.168.10.128. +You can get installed container guests in the system using --get-guest-list option. -#### 2nd step: Connect to board using web browser. +```bash +$ cmcontrol --get-guest-list +HEADER: name, role, status + cluster-demo, cluster, started + agl-flutter-ivi-demo, ivi, disable + agl-momi-ivi-demo, ivi, started + agl-qt-ivi-demo, ivi, disable +``` -Open "[http://a.b.c.d:8080](http://a.b.c.d:8080)". When -a board is set IP address 192.168.10.128, you open -"[http://192.168.10.128:8080](http://192.168.10.128:8080)". +The name is a guest name. The role is a guest role (cluster or ivi). The status is a status of guest. Current inactive guest status is disable. -When you success to connect to board, your web browser show these web -UI. -#### PC View +If you want to change guest from agl-momi-ivi-demo to agl-flutter-ivi-demo, it uses these command. - +```bash +$ cmcontrol --change-active-guest-name=agl-flutter-ivi-demo +$ cmcontrol --shutdown-guest-role=ivi +``` -#### Mobile View +If you want to reboot IVI guest with shutdown process, it uses these command. - +```bash +$ cmcontrol --reboot-guest-role=ivi +``` -### 7b. Keyboard Interface +If you want to force reboot IVI guest without shutdown process, it uses these command. + +```bash +$ cmcontrol --force-reboot-guest-role=ivi +``` + +## Frequently Asked Questions + +| Questions | Answer | +|:---|:---| +| Why not show map in default screen of Momi IVI. | When you want show map, you need extra step. Please fallow [this page](../../06_Component_Documentation/Demo_Application/01_Momi_Navi.md).| -Please refer to Appendix 3. ## Appendix.1. Typical Hardware set. @@ -395,15 +419,51 @@ Please refer to Appendix 3.  -### HTML5 IVI - - - ### Momi IVI  -## Appendix 3. How to configure Special Keyboard. +## Appendix 3. How to use Web UI (Momi Web). + +The Momi web is a web interface for container exchange. When you want +to use Momi web, you must connect network between board and +PC/Tablet/Phone. + +**The Momi web is completely demo feature, that open many security hole. + You shall not use out of standalone demo.** + +### 1st step: Check IP address in your board. + +After booting, you check IP address in your board. + +```bash +root@raspberrypi4-64:\~# ifconfig\ +eth0 Link encap:Ethernet HWaddr E4:XX:YY:ZZ:WW:VV\ + inet addr:192.168.10.128 Bcast:192.168.10.255 + Mask:255.255.255.0 +``` + +In this case, this board set IP address by 192.168.10.128. + +### 2nd step: Connect to board using web browser. + +Open "[http://a.b.c.d:8080](http://a.b.c.d:8080)". When +a board is set IP address 192.168.10.128, you open +"[http://192.168.10.128:8080](http://192.168.10.128:8080)". + +When you success to connect to board, your web browser show these web +UI. + +### PC View + + + +### Mobile View + + + + +## Appendix 4. How to configure Special Keyboard. ### How to get configuration tool. diff --git a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image10.jpeg b/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image10.jpeg Binary files differdeleted file mode 100644 index 70af6c2..0000000 --- a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image10.jpeg +++ /dev/null diff --git a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image9.jpeg b/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image9.jpeg Binary files differindex 0a3e945..8d42761 100644 --- a/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image9.jpeg +++ b/docs/01_Getting_Started/03_Build_and_Boot_guide_Profile/images/image9.jpeg diff --git a/docs/06_Component_Documentation/01_AGL_components.md b/docs/06_Component_Documentation/01_AGL_components.md index 3508096..4aa9a17 100644 --- a/docs/06_Component_Documentation/01_AGL_components.md +++ b/docs/06_Component_Documentation/01_AGL_components.md @@ -24,3 +24,8 @@ title: AGL Components ### Application Lifecycle and Services - [Application Framework](Application_Framework/01_Introduction.md) + +### Application for Demo + +- [Momi Navi](Demo_Application/01_Momi_Navi.md) + diff --git a/docs/06_Component_Documentation/09_AGL_Demo_Control_Panel.md b/docs/06_Component_Documentation/09_AGL_Demo_Control_Panel.md index af42523..2b99242 100644 --- a/docs/06_Component_Documentation/09_AGL_Demo_Control_Panel.md +++ b/docs/06_Component_Documentation/09_AGL_Demo_Control_Panel.md @@ -5,7 +5,10 @@ title: AGL Demo Control Panel ## Introduction -This document describes the design and usage of the **AGL Demo Control Panel**, a **Qt5-based** tool that allows you to control and interact with various **Automotive Grade Linux (AGL)** demo applications. The tool uses **Kuksa.val** and **CAN frame messages** to communicate with the target machine that runs the AGL image(s). You can use the tool to perform tasks such as starting and stopping scripts, changing the vehicle speed and engine RPM, adjusting the HVAC settings, and providing Steering Inputs. The tool is designed to **demonstrate** the capabilities and features of AGL in a **user-friendly** and **interactive** way. +This document describes the design and usage of the **AGL Demo Control Panel**, a **Qt6-based** tool that allows you to control and interact with various **Automotive Grade Linux (AGL)** demo applications. The tool uses **Kuksa.val** and **CAN frame messages** to communicate with the target machine that runs the AGL image(s). You can use the tool to perform tasks such as starting and stopping scripts, changing the vehicle speed and engine RPM, adjusting the HVAC settings, and providing Steering Inputs. The tool is designed to **demonstrate** the capabilities and features of AGL in a **user-friendly** and **interactive** way. + +It also supports file playback from CARLA based CAN messages. Refer to the [CARLA with AGL](13_CARLA_with_AGL.md) for more information. + ### Application Overview To use the control panel, you need to connect the main machine that runs the control panel to the target machine that runs the AGL image(s) using a **LAN/ethernet cable**. You also need to configure the IP address of the Kuksa server and set your preferences in the tool’s settings menu. @@ -13,16 +16,6 @@ To use the control panel, you need to connect the main machine that runs the con  ## Installation - - -- _Note_: - If errors occur in Debian based/Rasbian OS during installation, follow the steps mentioned below and skip to step 2: -```bash -$ nano requirements.txt -# -> Comment pyqt5 dependency using "#" -$ sudo apt install python3-pyqt5 python3-qtpy pyqt5-dev-tools python3-pyqt5.qtsvg -y -``` - - Step 1 ```bash $ python3 -m venv control-panel @@ -32,7 +25,7 @@ $ source control-panel/bin/activate - Step 2 ```bash $ pip3 install -r requirements.txt -$ pyrcc5 assets/res.qrc -o res_rc.py +$ pyside6-rcc assets/res.qrc -o res_rc.py ``` ## Setup @@ -40,8 +33,9 @@ Before using the `AGL Demo Control Panel`, we need to make sure to run the Kuks ### 1. Connect the Machines -First, we need to connect the machines, i.e. the host machine (Running the control panel) and the target machine (running the AGL image) via LAN or a bridged network (QEMU or VM) -### 2. CAN interface (WIP) +First, we need to connect the machines, i.e. the host machine (Running the control panel) and the target machine (running the AGL image) via LAN or a bridged network (QEMU or VM). + +### 2. CAN interface To set up the CAN interface between the Host system and the target machine(s) we use [cannelloni](https://github.com/mguentner/cannelloni), diff --git a/docs/06_Component_Documentation/12_AGL_Persistent_Storage_API.md b/docs/06_Component_Documentation/12_AGL_Persistent_Storage_API.md index 97ec0ac..04ee9ee 100644..100755 --- a/docs/06_Component_Documentation/12_AGL_Persistent_Storage_API.md +++ b/docs/06_Component_Documentation/12_AGL_Persistent_Storage_API.md @@ -1,225 +1,229 @@ -# Persistent Storage API for the Automotive Grade Linux demo - -The [AGL Persistent Storage API](https://github.com/LSchwiedrzik/agl-persistent-storage-api) -is a grpc API for [AGL](https://www.automotivelinux.org/) -that serves as persistent storage API for the demo. The API is written -in Rust and makes use of [tonic](https://crates.io/crates/tonic-build) for grpc -functionality as well as [RocksDB](https://rocksdb.org/) as a database backend, -using [rust-rocksdb](https://crates.io/crates/rust-rocksdb). Use cases include -retaining settings over a system shutdown (e.g. audio, HVAC, profile data, Wifi -settings, radio presets, metric vs imperial units). - -The most important hardware consideration for this project is that the AGL demo -runs on embedded hardware with flash storage, so we want to minimize number of -write operations. This impacts the choice of database; we have chosen to work -with RocksDB as it is well-suited for embedded computing and tunable with -respect to write amplification. In principle the API is flexible with -respect to database used (pluggable backends), but only RocksDB is implemented. -This API is part of the AGL demo as of release 'Royal Ricefish'. - -The AGL Persistent Storage API is constructed using a layered architecture: - -- Controller layer: translates proto calls to service calls. -- Service layer: communicates with the controller and facade layers, implements - the business logic -- Facade layer: implements RocksDB. - -## API Specification - -**Namespaces** -The rpcs described below interact with keys belonging to specific namespaces. This feature enables applications to maintain private namespaces within the same database. Not specifying a namespace when calling the API will result in the default namespace "" being used. Alternatively, a specific namespace (e.g. "AppName") can be chosen. With the exception of DestroyDB, which acts on the entire database, all rpcs can only interact with one namespace at a time. - -- `DestroyDB() -> StandardResponse(success: boolean, message: string)` - - - Consumer wants to destroy the entire database. - - ```text - DestroyDB() -> //destroys entire database. - ``` - -- `Write(key: string, value: string, namespace: string) -> StandardResponse(success: boolean, message: string)` - - - Consumer wants to save *key* + *value* to a given *namespace* (default is ""), (e.g. - 'Vehicle.Infotainment.Radio.CurrentStation':'hr5'). - - This overwrites existing *value* under *key*. - - An empty string cannot be used as a *key*. - - ```text - Write('Vehicle.Infotainment.Radio.CurrentStation':'wdr 4') -> Response - - Write('Vehicle.Infotainment':'yes') -> Response - - Write('test':'1') -> Response - - Write('':'test') -> Error - - Write(key: 'Private.Info', value: 'test', namespace: 'AppName') -> Response - ``` - -- `Read(key: string, namespace: string) -> ReadResponse(success: boolean, message: string, value: string)` - - - Consumer wants to read *value* of existing *key* in a given *namespace* (default is ""), e.g. - 'Vehicle.Infotainment.Radio.CurrentStation': - - ```text - Read('Vehicle.Infotainment.Radio.CurrentStation') -> 'wdr 4' - - Read('Vehicle.doesNotExist') -> ERROR - - Read(key: 'Private.Info', namespace: 'AppName') -> 'test' - ``` - -- `Delete(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)` - - - Consumer wants to delete an existing *key* + *value* from a given *namespace* (default is ""), e.g. - 'Vehicle.Infotainment.Radio.CurrentStation': - - ```text - Delete('Vehicle.Infotainment.Radio.CurrentStation') -> Response - - Delete('Vehicle.doesNotExist') -> ERROR - - Delete(key: 'Private.Info', namespace: 'AppName') -> Response - ``` - -- `Search(key: string, namespace: string) -> ListResponse(success: boolean, message: string, keys: repeated string)` - - - Consumer wants to list all keys that contain *key* in a given *namespace* (default is ""), e.g. 'Radio' - - ```text - Search('Radio') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Communication.Radio.Volume') - - Search('Info') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature') - - Search('nt.Rad') -> ('Vehicle.Infotainment.Radio.CurrentStation') - - Search('') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume') - - Search(key: '', namespace: 'AppName') -> ('Private.Info') - ``` - -- `DeleteNodes(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)` - - - Consumer wants to delete all keys located in the subtree with root *key*, within the given *namespace* (default is ""), e.g. - 'Vehicle.Infotainment' - - `key = ''` returns `ERROR` - - This rpc assumes that keys follow a VSS-like tree structure. - - ```text - DeleteNodes('Vehicle.Infotainment') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature') - - DeleteNodes('Vehicle') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume') - - DeleteNodes('') -> ERROR - - DeleteNodes('DoesNotExist') -> ERROR - - DeleteNodes('Vehic') -> ERROR - - DeleteNodes(key: 'Private', namespace: 'AppName') -> Response //deletes ('Private.Info') - ``` - -- `ListNodes(node: string, layers: optional int, namespace: string) -> ListResponse(boolean, message, repeated string keys)` - - - Consumer wants to list all nodes located in the subtree with root *node* exactly *layers* - layers deep, within the given *namespace* (default is "") , e.g. 'Vehicle.Infotainment' - - - `layers = 0` lists all keys that start in *node* any number of *layers* deep - - `layers` default value is 1 - - `node = ''` returns top-level root node(s) - - This rpc assumes that keys follow a VSS-like tree structure. - - ```text - ListNodes('Vehicle.Infotainment', 1) -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC') - - ListNodes('Vehicle.Infotainment', 2) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature') - - ListNodes('Vehicle', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment') - - ListNodes('', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment', 'test') - - ListNodes('Vehicle.Infotainment') -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC') - - ListNodes('', 1) -> ('Vehicle', 'test') - - ListNodes('Vehicle.Infotainment.Radio.Volume', 1) -> () - - ListNodes('Vehicle', -1) -> ERROR - - ListNodes('Vehicle.DoesNotExist', 1) -> ERROR - - ListNodes(key: 'Private', namespace: 'AppName') -> ('Private.Info') - - For empty data base: - ListNodes('', 1) -> () - ``` - -## Example Tree - -Note: nodes marked by \* are keys (and therefore have a value) - -**Namespace: ""** -- Vehicle - - Infotainment \* - - Radio - - CurrentStation \* - - Volume \* - - HVAC - - OutdoorTemperature \* - - Communication - - Radio - - Volume \* -- test \* - -**Namespace: "AppName"** -- Private - - Info \* - -## Setup instructions - -1. Install rust - -2. Download or install protobuf (e.g. from - [here](https://github.com/protocolbuffers/protobuf/releases)) and set the - `PROTOC` environment variable: - `echo -n "export PROTOC=/path/to/protoc.exe" >> ~/.bashrc` - -3. Build application - - ```bash - cargo build - ``` - -4. Run tests - - ```bash - cargo test - ``` - -5. Start server - - ```bash - cargo run --release --bin server - ``` - -## rpc Usage - -Insomnia usage for manual testing is describd in -https://konghq.com/blog/engineering/building-grpc-apis-with-rust - -```text -DestroyDB: {} - -Write: { "key": "foo", "value": "foobar", "namespace": "bar" } - -Read: { "key": "foo", "namespace": "bar" } - -Delete: { "key": "foo", "namespace": "bar" } - -Search: { "key": "foo", "namespace": "bar" } - -DeleteNodes: { "key": "foo", "namespace": "bar" } - -ListNodes: { "key": "foo", "layers": 1, "namespace": "bar" } - -``` +# Persistent Storage API for the Automotive Grade Linux demo
+
+The AGL Persistent Storage API
+is a grpc API for [AGL](https://www.automotivelinux.org/)
+that serves as persistent storage API for the demo. The API is written
+in Rust and makes use of [tonic](https://crates.io/crates/tonic-build) for grpc
+functionality as well as [RocksDB](https://rocksdb.org/) as a database backend,
+using [rust-rocksdb](https://crates.io/crates/rust-rocksdb). Use cases include
+retaining settings over a system shutdown (e.g. audio, HVAC, profile data, Wifi
+settings, radio presets, metric vs imperial units).
+
+The most important hardware consideration for this project is that the AGL demo
+runs on embedded hardware with flash storage, so we want to minimize number of
+write operations. This impacts the choice of database; we have chosen to work
+with RocksDB as it is well-suited for embedded computing and tunable with
+respect to write amplification. In principle the API is flexible with
+respect to database used (pluggable backends), but only RocksDB is implemented.
+This API is part of the AGL demo as of release 'Royal Ricefish'.
+
+The AGL Persistent Storage API is constructed using a layered architecture:
+
+- Controller layer: translates proto calls to service calls.
+- Service layer: communicates with the controller and facade layers, implements
+ the business logic
+- Facade layer: implements RocksDB.
+
+By default, the API can be accessed through port 50054. This can be changed in main.rs.
+The RocksDB database files are stored in directory "AGLPersistentStorageAPI",
+located in the home directory of your system. This can be changed in service.rs.
+
+## API Specification
+
+### Namespaces
+
+The rpcs described below interact with keys belonging to specific namespaces. This feature enables applications to maintain private namespaces within the same database. Not specifying a namespace when calling the API will result in the default namespace "" being used. Alternatively, a specific namespace (e.g. "AppName") can be chosen. With the exception of DestroyDB, which acts on the entire database, all rpcs can only interact with one namespace at a time.
+
+### Remote procedure calls
+
+- `DestroyDB() -> StandardResponse(success: boolean, message: string)`
+
+ - Consumer wants to destroy the entire database.
+
+ ```text
+ DestroyDB() -> //destroys entire database.
+ ```
+
+- `Write(key: string, value: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+ - Consumer wants to save *key* + *value* to a given *namespace* (default is ""), (e.g.
+ 'Vehicle.Infotainment.Radio.CurrentStation':'hr5').
+ - This overwrites existing *value* under *key*.
+ - An empty string cannot be used as a *key*.
+
+ ```text
+ Write('Vehicle.Infotainment.Radio.CurrentStation':'wdr 4') -> Response
+
+ Write('Vehicle.Infotainment':'yes') -> Response
+
+ Write('test':'1') -> Response
+
+ Write('':'test') -> Error
+
+ Write(key: 'Private.Info', value: 'test', namespace: 'AppName') -> Response
+ ```
+
+- `Read(key: string, namespace: string) -> ReadResponse(success: boolean, message: string, value: string)`
+
+ - Consumer wants to read *value* of existing *key* in a given *namespace* (default is ""), e.g.
+ 'Vehicle.Infotainment.Radio.CurrentStation':
+
+ ```text
+ Read('Vehicle.Infotainment.Radio.CurrentStation') -> 'wdr 4'
+
+ Read('Vehicle.doesNotExist') -> ERROR
+
+ Read(key: 'Private.Info', namespace: 'AppName') -> 'test'
+ ```
+
+- `Delete(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+ - Consumer wants to delete an existing *key* + *value* from a given *namespace* (default is ""), e.g.
+ 'Vehicle.Infotainment.Radio.CurrentStation':
+
+ ```text
+ Delete('Vehicle.Infotainment.Radio.CurrentStation') -> Response
+
+ Delete('Vehicle.doesNotExist') -> ERROR
+
+ Delete(key: 'Private.Info', namespace: 'AppName') -> Response
+ ```
+
+- `Search(key: string, namespace: string) -> ListResponse(success: boolean, message: string, keys: repeated string)`
+
+ - Consumer wants to list all keys that contain *key* in a given *namespace* (default is ""), e.g. 'Radio'
+
+ ```text
+ Search('Radio') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Communication.Radio.Volume')
+
+ Search('Info') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+ Search('nt.Rad') -> ('Vehicle.Infotainment.Radio.CurrentStation')
+
+ Search('') -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume')
+
+ Search(key: '', namespace: 'AppName') -> ('Private.Info')
+ ```
+
+- `DeleteNodes(key: string, namespace: string) -> StandardResponse(success: boolean, message: string)`
+
+ - Consumer wants to delete all keys located in the subtree with root *key*, within the given *namespace* (default is ""), e.g.
+ 'Vehicle.Infotainment'
+ - `key = ''` returns `ERROR`
+ - This rpc assumes that keys follow a VSS-like tree structure. *key* must be the full name of an existing node.
+
+ ```text
+ DeleteNodes('Vehicle.Infotainment') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+ DeleteNodes('Vehicle') -> Response //deletes ('Vehicle.Infotainment', 'Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume')
+
+ DeleteNodes('') -> ERROR
+
+ DeleteNodes('DoesNotExist') -> ERROR
+
+ DeleteNodes('Vehic') -> ERROR
+
+ DeleteNodes(key: 'Private', namespace: 'AppName') -> Response //deletes ('Private.Info')
+ ```
+
+- `ListNodes(node: string, layers: optional int, namespace: string) -> ListResponse(boolean, message, repeated string keys)`
+
+ - Consumer wants to list all nodes located in the subtree with root *node* exactly *layers*
+ layers deep, within the given *namespace* (default is "") , e.g. 'Vehicle.Infotainment'
+
+ - `layers = 0` lists all keys that start in *node* any number of *layers* deep
+ - `layers` default value is 1
+ - `node = ''` returns top-level root node(s)
+ - This rpc assumes that keys follow a VSS-like tree structure. *node* must be the full name of an existing node.
+
+ ```text
+ ListNodes('Vehicle.Infotainment', 1) -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC')
+
+ ListNodes('Vehicle.Infotainment', 2) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature')
+
+ ListNodes('Vehicle', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment')
+
+ ListNodes('', 0) -> ('Vehicle.Infotainment.Radio.CurrentStation', 'Vehicle.Infotainment.Radio.Volume', 'Vehicle.Infotainment.HVAC.OutdoorTemperature', 'Vehicle.Communication.Radio.Volume', 'Vehicle.Infotainment', 'test')
+
+ ListNodes('Vehicle.Infotainment') -> ('Vehicle.Infotainment.Radio', 'Vehicle.Infotainment.HVAC')
+
+ ListNodes('', 1) -> ('Vehicle', 'test')
+
+ ListNodes('Vehicle.Infotainment.Radio.Volume', 1) -> ()
+
+ ListNodes('Vehicle', -1) -> ERROR
+
+ ListNodes('Vehicle.DoesNotExist', 1) -> ERROR
+
+ ListNodes(key: 'Private', namespace: 'AppName') -> ('Private.Info')
+
+ For empty data base:
+ ListNodes('', 1) -> ()
+ ```
+
+## Example Tree
+
+Note: nodes marked by \* are keys (and therefore have a value)
+
+**Namespace: ""**
+- Vehicle
+ - Infotainment \*
+ - Radio
+ - CurrentStation \*
+ - Volume \*
+ - HVAC
+ - OutdoorTemperature \*
+ - Communication
+ - Radio
+ - Volume \*
+- test \*
+
+**Namespace: "AppName"**
+- Private
+ - Info \*
+
+## Setup instructions
+
+1. Install [rust](https://rustup.rs/).
+
+2. Install the Protobuf Compiler, e.g. by downloading the latest pre-built binary for your system [here](https://github.com/protocolbuffers/protobuf/releases) and following the installation instructions included in the readme. Be sure to add your Protobuf installation to your PATH. See also the general [Protobuf installation instructions](https://github.com/protocolbuffers/protobuf?tab=readme-ov-file#protobuf-compiler-installation).
+
+3. Install a clang compiler, e.g. by downloading the latest pre-built LLVM binary for your system [here](https://github.com/llvm/llvm-project/releases) and adding the LIBCLANG_PATH variable to your environment.
+
+4. Build application.
+
+ ```bash
+ cargo build
+ ```
+
+5. Run tests.
+
+ ```bash
+ cargo test
+ ```
+
+6. Start server.
+
+ ```bash
+ cargo run --release --bin server
+ ```
+
+## Remote Procedure Call Usage
+
+To ensure your API is working as expected, you can use [Insomnia](https://insomnia.rest/) to manually send remote procedure calls to the API, following the instructions provided in the [Insomnia documentation](https://docs.insomnia.rest/insomnia/requests#send-a-grpc-request). For each procedure call, an example is given below:
+
+```text
+DestroyDB: {}
+
+Write: { "key": "foo", "value": "foobar", "namespace": "bar" }
+
+Read: { "key": "foo", "namespace": "bar" }
+
+Delete: { "key": "foo", "namespace": "bar" }
+
+Search: { "key": "foo", "namespace": "bar" }
+
+DeleteNodes: { "key": "foo", "namespace": "bar" }
+
+ListNodes: { "node": "foo", "layers": 1, "namespace": "bar" }
+```
diff --git a/docs/06_Component_Documentation/13_CARLA_with_AGL.md b/docs/06_Component_Documentation/13_CARLA_with_AGL.md new file mode 100644 index 0000000..075da80 --- /dev/null +++ b/docs/06_Component_Documentation/13_CARLA_with_AGL.md @@ -0,0 +1,104 @@ +--- +title: CARLA with AGL +--- +# CARLA with AGL (WIP) + +## Setting up CARLA + +You can follow the steps provided in the [CARLA documentation](https://carla.readthedocs.io/en/latest/start_quickstart/#carla-installation) for installing CARLA. + +We recommend using the [latest release](https://github.com/carla-simulator/carla/releases/), and using the supported Python version to run the `carla_to_CAN.py` Script. + +1. Running the CARLA Server + + ```bash + # Move to the installation directory + $ cd /path/to/CARLA_<version> + + # Start the CARLA Server + $ ./CarlaUE4.sh + + # To run using minimum resources + $ ./CarlaUE4.sh -quality-level=Low -prefernvidia + ``` + + You may also add the `-RenderOffScreen` flag to start CARLA in off-screen mode. Refer to the various [rendering options](https://carla.readthedocs.io/en/latest/adv_rendering_options/#no-rendering-mode) for more details. + + Another way of running the CARLA server without a display is by using [CARLA in Docker](https://carla.readthedocs.io/en/latest/build_docker/). + +2. Starting a Manual Simulation + + ```bash + # Navigate to directory containing the demo python scripts + # + $ cd /path/to/CARLA_<version>/PythonAPI/examples + ``` + + Create a Python virtual environment and resolve dependencies + ```bash + $ python3 -m venv carlavenv + $ source carlavenv/bin/activate + $ pip3 install -r requirements.txt + + # Start the manual_control.py script + $ python3 manual_control.py + ``` + +## Converting CARLA data into CAN + +The `carla_to_CAN.py` script can be run run alongside an existing CARLA simulation to fetch data and convert it into CAN messages based on the [agl-vcar.dbc](https://git.automotivelinux.org/src/agl-dbc/plain/agl-vcar.dbc) file. + +While the `record_playback.py` script is responsible for recording amd playing back the CAN data for later sessions. + +_NOTE_: This does **not** require the CARLA server to be running. + +To access these scripts, clone the [AGL Demo Control Panel](https://gerrit.automotivelinux.org/gerrit/admin/repos/src/agl-demo-control-panel,general) project. + +```bash +# Move to the Scripts directory +$ cd /path/to//agl-demo-control-panel/Scripts + +# Fetch the agl-vcar.dbc file +$ wget -nd -c "https://git.automotivelinux.org/src/agl-dbc/plain/agl-vcar.dbc" +``` + +Create a Python virtual environment and resolve dependencies +```bash +$ python3 -m venv carlavenv +$ source carlavenv/bin/activate +$ pip3 install -r requirements.txt + +# Optionally, set up the vcan0 interface +$ ./vcan.sh +``` + +1. Converting CARLA Data into CAN + + ```bash + $ python -u carla_to_CAN.py + # OR + $ python -u carla_to_CAN.py --host <carla_server_ip> --port <carla_server_port> + ``` + +2. Recording and Playback of CAN messages + + ```bash + $ python -u record_playback.py + # OR + $ python -u record_playback.py --interface (or) -i can0 # default vcan0 + ``` + + CLI Options: + + - 1: Captures CAN messages and writes them into 'can_messages.txt' + - 2: Replays captured CAN messages + - 3: Exit + + +## CAN interface to AGL Demo Platform + +To use the **`carla_to_CAN.py`** and **`record_playback.py`** scripts to send messages on the CAN interface, one can use the CAN bus or use CAN over Ethernet using **cannelloni**. + +**cannelloni** is available in AGL, just add `IMAGE_INSTALL:append = " cannelloni"` to your `conf/local.conf`. + +To set up the CAN interface between the Host system and the target machine(s) refer to the [cannelloni docs](https://github.com/mguentner/cannelloni). diff --git a/docs/06_Component_Documentation/Demo_Application/01_Momi_Navi.md b/docs/06_Component_Documentation/Demo_Application/01_Momi_Navi.md new file mode 100644 index 0000000..ac0f886 --- /dev/null +++ b/docs/06_Component_Documentation/Demo_Application/01_Momi_Navi.md @@ -0,0 +1,35 @@ +--- +title: Momi Navi +--- + +# What is Momi Navi + +Momi Navi is a example application for navigation. It run on simple ivi demo (that name is momi IVI) for the instrument cluster container integration. + + + +## How to use + +When you build the instrument cluster integration without momi navi specific setting, it will not show map. You need momi navi specific setting. + +The momi navi uses mapbox gl plugin fo Qt location. It requires own access token to download map. You can create own mapbox access token following [this page](https://docs.mapbox.com/help/getting-started/access-tokens/). + +After creation, please set environment variable to local.conf (or site.conf). + +``` +MOMIMAP_MAPBOX_ACCESS_TOKEN = "Your access token." +``` + +## Extra configuration + +Momi navi supports configuration for customize. + +When you set environment variable to local.conf (or site.conf), you can customize Momi navi. + +| Environment variable | Customizing parametor | +|:---|:---| +| MOMIMAP_MAPBOX_STYLE | Map style | +| MOMIMAP_INITIAL_LATITUDE | Default location | +| MOMIMAP_INITIAL_LONGITUDE | Default location | + +How to create map style, please check [this page](https://docs.mapbox.com/studio-manual/guides/map-styling/). diff --git a/docs/06_Component_Documentation/Demo_Application/images/mominavi.jpg b/docs/06_Component_Documentation/Demo_Application/images/mominavi.jpg Binary files differnew file mode 100644 index 0000000..8e30c05 --- /dev/null +++ b/docs/06_Component_Documentation/Demo_Application/images/mominavi.jpg |
