Snapshot.

Author: martacarbone

docs/models/models.md

@@ -115,7 +115,7 @@ We want to create an application with two bricks with no models, one of them req
   require_devices: false
   mount_devices_into_container: false
   ports: []
-  category: null
+  category: [audio]
   variables:
   - name: ARDUINO_DEVICE_ID
     description: Arduino Cloud Device ID
@@ -135,8 +135,8 @@ We want to create an application with two bricks with no models, one of them req
 *Note:* Is the category keyword here connected to the model concept?
 
 The brick contains some variables, visible to the user that should/could be configured by the user from the AppLab brick configuration.
-![Brick configuration_button](brick_conf_b.png)
-![Brick configuration_vars](brick_conf_v.png)
+![Brick configuration_button](images/brick_conf_b.png)
+![Brick configuration_vars](images/brick_conf_v.png)
 
 ### App.yaml definition
 The configured variables will be stored in the related brick section in the App.yaml file, as follow:
@@ -173,6 +173,7 @@ models/
 ### hey_arduino_ei/conf.yaml
 ```
 name : "Edge Impulse Hey Arduino model"
+model_category: [audio]
 model_labels: 
   - "hey_arduino"
   - "other_labels_here"
@@ -192,18 +193,19 @@ source-model-url: "https://studio.edgeimpulse.com/studio/757509"
 ```
 ### hey_arduino_qlc/conf.yaml
 ```
-source: "qualcomm-ai-hub"
-ei-gpu-mode: false
-source-model-id: "hey_arduino_spotting-lite"
-source-model-url: "https://aihub.qualcomm.com/models/hey_ardino_spotting_lite"
-```
-### hey_arduino_qlc/metadata.yaml
-```
 name : "Qualcomm Hey Arduino model"
+model_category: [audio]
 model_labels: 
   - "hey_arduino"
   - "other_labels_here"
 ```
+### hey_arduino_qlc/metadata.yaml
+```
+source: "qualcomm-ai-hub"
+ei-gpu-mode: false
+source-model-id: "hey_arduino_spotting-lite"
+source-model-url: "https://aihub.qualcomm.com/models/hey_ardino_spotting_lite"
+```
 ### Brick definition (brick-list.yaml)
 ```
 - id: arduino:keyword_spotting
@@ -214,7 +216,7 @@ model_labels:
   require_devices: false
   mount_devices_into_container: false
   ports: []
-  category: audio
+  model_category: [audio]
   required_devices:
   - microphone
 ```
@@ -263,6 +265,7 @@ models/
 ```
 ### yolo_x_nano/conf.yaml
 name : Lightweight-Face-Detection
+model_category: [video]
 model_labels: 
   - "face"
   - "other_labels_here"
@@ -283,7 +286,7 @@ source-model-url: "https://github.com/Megvii-BaseDetection/YOLOX"
   require_devices: false
   mount_devices_into_container: false
   ports: []
-  category: video
+  model_category: [video]
 - id: arduino:fast_runner_object_detection
   name: Object Detection
   description: "Brick for faster object detection"
@@ -292,7 +295,7 @@ source-model-url: "https://github.com/Megvii-BaseDetection/YOLOX"
   require_devices: false
   mount_devices_into_container: false
   ports: []
-  category: video
+  model_category: [video]
 ```
 ### App.yaml definition
 ```
@@ -333,7 +336,7 @@ models/
 ```
 The conf and metadata YAML files are the same as in Case #2. This custom model scenario, however, changes the way we handle model lifecycle management and model provision to the container. (Could a filesystem overlay be an option?)
 
-*NOTE:* There is another case here: the container could decide to autonomously download the model from a remote site using its metadata. In this case, we just need to expose the metadata.
+*NOTE:* There is another case here: the container could decide to autonomously download the model from a remote site using its metadata. If this happens, we only need to expose the metadata.
 
 ### Brick definition (brick-list.yaml)
 ```
@@ -345,7 +348,7 @@ The conf and metadata YAML files are the same as in Case #2. This custom model s
   require_devices: false
   mount_devices_into_container: false
   ports: []
-  category: audio
+  model_category: [video]
   required_devices:
   - microphone
   variables:
@@ -370,8 +373,6 @@ bricks:
 EI_KEYWORD_SPOTTING_MODEL: "/models/hei_arduino_qlc/builds/qualcomm_impulse_hey_arduino.model"
 ```
 
-# end
-
 The following section explores whether this model is suitable for specific use cases.
 
 ## The user chooses a model for a brick (link Figma here)
@@ -435,9 +436,4 @@ This section details the proposed changes to the current implementation.
 A Model definition contains a list of categories.
 
 A Brick definition containes a list of supported categories supported and a default_mode_name.
- 
-
-![Model](model.png)
-![Brick](brick.png)
-![App](app.png)
-
+