mirror of
https://github.com/jomjol/AI-on-the-edge-device-docs.git
synced 2025-12-06 03:26:54 +03:00
.
This commit is contained in:
CaCO3
@@ -1,5 +1,4 @@
|
||||
# Best Practice
|
||||
|
||||
This page shows some best practices:
|
||||
|
||||
## Camera Placement
|
||||
@@ -8,11 +7,10 @@ This page shows some best practices:
|
||||
* If the LED reflections are too strong, put tape over the LED to diffuse the light
|
||||
* Change the ImageSize to QVGA under "Expert mode" configuration when close enough, this will be faster and is often good enough for digit recognition.
|
||||
|
||||
## Reflections
|
||||
|
||||
* Try to get rid of the reflections by rotating the camera, so that the reflections are at positions, where no number is.
|
||||
* By using the external LED option, you can place WS2812 LEDs freely away from the main axis.
|
||||
* Users report, that a handy cover foil could also help
|
||||
## Reflections
|
||||
* Try to get rid of the reflections by rotating the camera, so that the reflections are at positions, where no number is.
|
||||
* By using the external LED option, you can place WS2812 LEDs freely away from the main axis.
|
||||
* Users report, that a handy cover foil could also help
|
||||
|
||||
## Post-processing
|
||||
* Filter out the Number "9", as "3" will often be misread for a "9" and void every number between 3 and 9 due to it being negative flow.
|
||||
|
||||
@@ -9,7 +9,6 @@ This page tries to help you on which model to select.
|
||||
For more technical/deeper explanations have a look on [Neural-Network-Types](Neural-Network-Types.md).
|
||||
|
||||
## Digit Models
|
||||
|
||||
For digits on water meters, gas-meters or power meters you can select between two main types of models:
|
||||
|
||||
- `dig-class11`
|
||||
@@ -20,7 +19,6 @@ For digits on water meters, gas-meters or power meters you can select between tw
|
||||
**continuous** means, that there is no discrete model, that has discreate states, but there is a different mechanism, that provides a not discrete value in the interval between [0, 1[.
|
||||
|
||||
### `dig-class11`
|
||||
|
||||
This model can recognize **full digits**. It was the first model version. All intermediate states shown a `N` for not-a-number (aka. `NaN`). But in post process it uses older values to fill up the `N` values if possible.
|
||||
|
||||
{: style="width:300px"}
|
||||
@@ -33,7 +31,6 @@ Main features:
|
||||
* the ExtendedResolution option is not supported. (Only in conjunction with `ana-class100` or `ana-cont`)
|
||||
|
||||
### `dig-class100` and `dig-cont`
|
||||
|
||||
These models are used to get a **continuous reading** with intermediate states. To see what the models are doing, you can go to the Recognition page of your device.
|
||||
|
||||
{: style="width:300px"}
|
||||
@@ -54,9 +51,6 @@ The `dig-class100` is a standard classification model. Each tenth step is an out
|
||||
Look [here](https://jomjol.github.io/neural-network-digital-counter-readout) for a list of digit images used for the training.
|
||||
|
||||
## Analog pointer models
|
||||
|
||||
### `ana-class100` and `ana-cont`
|
||||
|
||||
For pointers on water meters use the analog models:
|
||||
|
||||
{: style="width:250px"}
|
||||
@@ -82,7 +76,6 @@ Again, the difference between `ana-class100` and `ana-cont` is in the internal p
|
||||
Look [here](https://jomjol.github.io/neural-network-analog-needle-readout/) for a list of pointer images used for the training
|
||||
|
||||
## Different types of models (normal vs. quantized)
|
||||
|
||||
The normally trained network is calculating with internal floating point numbers. The saving of floating point numbers naturally takes more space than an integer type. Often the increased accuracy is not needed. Therefore there is the option, to "quantize" a neural network. In this case the internal values are rescaled to integer values, which is called "quantization". The stored tflite files are usually much smaller and runs faster on the edgeAI-device.
|
||||
Usually the models are distrusted therefore in both versions. They can be distinguished by a `q` at the end of the logfile.
|
||||
|
||||
@@ -94,7 +87,6 @@ Example:
|
||||
| Quantized | `dig-cont_0610_s3-q.tflite` |
|
||||
|
||||
## Model Naming Convention
|
||||
|
||||
Model filenames follow a specific structure composed of several parts:
|
||||
|
||||
1. **Model Type**: Indicates the kind of model, such as `ana/dig`, `cont`, `class11`, or `class100`.
|
||||
@@ -104,7 +96,6 @@ Model filenames follow a specific structure composed of several parts:
|
||||
5. **File Type**: Always `.tflite`.
|
||||
|
||||
### Version Number
|
||||
|
||||
The version number consists of four digits:
|
||||
|
||||
- The **first two digits** represent the *main version*.
|
||||
@@ -115,7 +106,6 @@ Example:
|
||||
In general, higher numbers correspond to newer models.
|
||||
|
||||
### Size Indicator
|
||||
|
||||
- The size indicator typically starts with `s` followed by a number, e.g., `s3`.
|
||||
- This naming is not strictly standardized yet.
|
||||
- Training usually begins with a larger model (`s0`), and successive versions (`s1`, `s2`, ...) reduce the number of parameters to create smaller, faster networks.
|
||||
@@ -123,6 +113,5 @@ Example:
|
||||
- In newer model generations, only the best-performing sizes are retained and further trained.
|
||||
|
||||
### Quantization Indicator
|
||||
|
||||
- If the model name ends with `-q`, it indicates that **quantization** was applied after training.
|
||||
- Quantization significantly reduces the model size, typically without a noticeable impact on recognition performance.
|
||||
@@ -1,7 +1,6 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
## My device reboots frequently. What can I do?
|
||||
|
||||
There are several reasons for frequent reboots:
|
||||
|
||||
* Frequent HTML requests
|
||||
@@ -12,7 +11,6 @@ There is a dedicated page about this: [Frequent Reboots](Frequent-Reboots.md).
|
||||
|
||||
|
||||
## Bad WebUI responsiveness. What can I do?
|
||||
|
||||
This is usually due to hardware or WLAN issues. There are already many entries in discussion section, some of which have good tipps.
|
||||
|
||||
Possible checks / ideas:
|
||||
@@ -33,7 +31,6 @@ Check [discussion section](https://github.com/jomjol/AI-on-the-edge-device/discu
|
||||
|
||||
|
||||
## How accurate are the detections?
|
||||
|
||||
It is hard to give a specific accuracy number. It depends on many factors, e.g.
|
||||
|
||||
* How in-focus is your camera?
|
||||
@@ -48,7 +45,6 @@ See the FAQs below for more details and configuration hints.
|
||||
|
||||
|
||||
## My numbers are not correctly detected. What can I do?
|
||||
|
||||
* There is a dedicated page about the correct setting [ROI Configuration](ROI-Configuration.md).
|
||||
* This page also includes the instructions for gathering new images for the training.
|
||||
|
||||
@@ -65,7 +61,6 @@ You can change the following settings to reduce incorrect readings (but potentia
|
||||
* Reduce `AutoTimer` configuration option `Interval` to the lowest it can be (e.g. `3` min). The more often you take readings, the less likely for data staleness to occur.
|
||||
|
||||
## Even after I have setup everything perfect there is a false reading - especially around the zero crossing (roll over to next number)
|
||||
|
||||
* The roll over behavior is different for the different meters. E.g.:
|
||||
* Rolling over start with different previous position (e.g. at 7, 8 or 9)
|
||||
* The neutral position (no rolling) is not perfectly at zero, but rather at something like 7.9 or 8.1, even if it should be exactly 8
|
||||
@@ -81,7 +76,6 @@ You can change the following settings to reduce incorrect readings (but potentia
|
||||
So please be a bit patient with your meter :-)
|
||||
|
||||
## Pre-Value
|
||||
|
||||
PreValue is here a bit missleading, because normally it is the same as the last value. In the next round of reading it will be used to check nagtive rates, high rates (MaxRateValue / MaxRateType) and CheckDigitIncreaseConsistency (dig-class11 only). Either from a previous correctly identified value or manual setting by the user.
|
||||
|
||||
If you use post processes, enable the pre-value. The pre-value must be set at first time. Set it to the current raw value.
|
||||
@@ -89,7 +83,6 @@ If you use post processes, enable the pre-value. The pre-value must be set at fi
|
||||
If the device runs in errors, the pre-value will not be updated, as long as the `preValueAgeStartup` time between the last valid value (or startup time) and current time is not exceeded. After it the preValue will be set again, if no other error occured. So the device can not run in an endless error, like high rate.
|
||||
|
||||
## "Rate too high - Read: ..."
|
||||
|
||||
In configuration you can set the `MaxRateValue` and `MaxRateType`. The settings suppress improbably high values that can come from false readings. To do this, the value must be set correctly depending on your meter.
|
||||
|
||||
Before doing this, you should be clear about the type of rating you want to use.
|
||||
@@ -103,7 +96,6 @@ If there is an interval of 5 minutes between readings and a MaxRateValue of 1, a
|
||||
- RateChange: the difference is `> 1 / 5`
|
||||
|
||||
## Train on my own images
|
||||
|
||||
Look at [Learn models with your own images](https://jomjol.github.io/AI-on-the-edge-device-docs/Learn-models-with-your-own-images/)
|
||||
and [Cookbook running the jupyter notebook with my own data](https://github.com/haverland/Tenth-of-step-of-a-meter-digit/wiki/Cookbook-running-the-jupyter-notebook-with-my-own-data).
|
||||
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
# Basic hardware / configuration issues
|
||||
|
||||
|
||||
If the device is behaving eratically or not running as expected you can use the following tools trying to identify the root cause:
|
||||
|
||||
1. Internal logging (`config.ini`)
|
||||
@@ -19,7 +17,6 @@ There are in principle two reboots types:
|
||||
______
|
||||
|
||||
### Sporadic random reboots
|
||||
|
||||
Sporadic random reboots could have the following reasons:
|
||||
|
||||
* In general: Unstable system due to software issues (e.g. overload during HTML access, ...)
|
||||
@@ -30,7 +27,6 @@ Sporadic random reboots could have the following reasons:
|
||||
In general: There are several mechanisms in the firmware (like saving previous values), to have a "smooth" reboot without too many notable disturbance.
|
||||
|
||||
##### System instabilities
|
||||
|
||||
If your system is sometimes running smoothly over several runs and sometimes reboots obviously randomly, you have an partially unstable device.
|
||||
|
||||
You can check this in the standard log file on the SD card:
|
||||
@@ -47,7 +43,6 @@ There is noting you can do about it, beside testing different hardware.
|
||||
|
||||
|
||||
#### Overload during HTML access
|
||||
|
||||
If you frequently access the web server over HTML requests, the firmware tends to reboot. This especially happens during the first run and when the ESP32 is busy with the digitization flow.
|
||||
|
||||
The reason for this are running out of memory during a flow, minor memory leakage in combination with missing error handling.
|
||||
@@ -59,15 +54,10 @@ There is noting you can do about this kind of reboot, beside two thing:
|
||||
|
||||
|
||||
##### Bad or insufficient power supply
|
||||
|
||||
A good and stabilized power supply is essential to have error free operation. The device is quite picky in terms of proper power supply. Especially the wifi module have some load spikes which the power supply needs to cover. If the power is not stable enough, the brwonout mechanism is protecting against strange behaviour and force a reboot whenever the voltage drops below a specific level. You can see this in random reboots which indication is logfile: --> Reset reason: Brownout
|
||||
|
||||
|
||||
|
||||
______
|
||||
|
||||
### Repeating boot loops
|
||||
|
||||
Repeating boot loops at the same situation during the flow has a systematic problem either in the hardware or the configuration. It usually happens during initialization state or processing the first round as there all needed parts of the firmware have been loaded for the first time.
|
||||
|
||||
To identify the root cause the logfiles, the reduced web interface, the red board LED or the serial log of the UART interface (no remote access, USB access needed) is helpful.
|
||||
@@ -78,15 +68,11 @@ Possible issues:
|
||||
* RAM related issues
|
||||
* Configuration related issues
|
||||
|
||||
|
||||
|
||||
##### SD card related issues
|
||||
|
||||
The ESP32CAM is a little bit "picky" with the supported SD cards. Due to the limited availability of GPIOs the SD card can only be accessed via 1-wire mode. Therefore not all SD cards are supported. The following error cases can occur:
|
||||
|
||||
|
||||
###### SD card: Wrong filesystem (only FAT32 is supported)
|
||||
|
||||
If this SD card error is detected only the following indications are available. No web interface will be accessible.
|
||||
|
||||
* Red board LED is blinking. The blinking codes are described here: [Status LED Blinkcodes](https://jomjol.github.io/AI-on-the-edge-device-docs/StatusLED-BlinkCodes/)
|
||||
@@ -94,7 +80,6 @@ If this SD card error is detected only the following indications are available.
|
||||
|
||||
|
||||
###### SD card not detected / not supported
|
||||
|
||||
If this SD card error is detected the following indication are available. No web interface will be accessible.
|
||||
|
||||
* Red board LED is blinking. The blinking codes are described here: [Status LED Blinkcodes](https://jomjol.github.io/AI-on-the-edge-device-docs/StatusLED-BlinkCodes/)
|
||||
@@ -102,7 +87,6 @@ If this SD card error is detected the following indication are available. No web
|
||||
|
||||
|
||||
###### SD card detected but files are not readable / writeable
|
||||
|
||||
The SD card is detected, but the files cannot be read or written. A basic SD card check for SD reading / writing is performed on every boot. This not 100% guarantee that SD card is working but it's at least a indication.
|
||||
|
||||
If this SD card error is detected the following indications are available:
|
||||
@@ -112,16 +96,12 @@ If this SD card error is detected the following indications are available:
|
||||
* Red board LED is blinking. The blinking codes are described here: [Status LED Blinkcodes](https://jomjol.github.io/AI-on-the-edge-device-docs/StatusLED-BlinkCodes/)
|
||||
* Error messages on serial log (UART interface)
|
||||
|
||||
|
||||
|
||||
##### RAM related issues
|
||||
|
||||
In order to run the firmware, 4 MB of external RAM (PSRAM) are mandatory. Usually, the ESP32CAM is equipped with 8MB (64Mbit) PSRAM chip, whereof only 4MB can be used effectively (direct addressable).
|
||||
Unfortunately, there is hardware around, where no PSRAM or only 2MB of PSRAM is present - **even if you have bought a device where a 8MB PSRAM was promoted**. These modules are not suiable for this firmware because the external RAM is needed to handle the CNN files and camera images. There is nothing to do, than to buy a new ESP32CAM with **really** 64MBit of PSRAM.
|
||||
|
||||
|
||||
###### Too less external RAM (PSRAM)
|
||||
|
||||
During the boot process the available RAM is going to be checked.
|
||||
|
||||
If there is too less RAM (PSRAM or total HEAP < 4MB) detected, the follwoing indications are available:
|
||||
@@ -131,13 +111,8 @@ If there is too less RAM (PSRAM or total HEAP < 4MB) detected, the follwoing ind
|
||||
* Red board LED is blinking. The blinking codes are described here: [Status LED Blinkcodes](https://jomjol.github.io/AI-on-the-edge-device-docs/StatusLED-BlinkCodes/)
|
||||
* Error messages on serial log (UART interface)
|
||||
|
||||
|
||||
|
||||
##### Configuration related issues
|
||||
|
||||
|
||||
###### Folders and files missing
|
||||
|
||||
Most of the relevant folders and files are checked during boot. The complete list can be found here: [Error codes on reduced webinterface](https://jomjol.github.io/AI-on-the-edge-device-docs/Error-Codes/)
|
||||
|
||||
If a relevant folder or file is missing the following indications are available:
|
||||
@@ -149,7 +124,6 @@ If a relevant folder or file is missing the following indications are available:
|
||||
|
||||
|
||||
###### CNN model file not available / corrupt
|
||||
|
||||
Additionally for operation CNN model files on SD card are mandatory, one CNN model file for analog counter and for for digit numbers each.
|
||||
|
||||
* `/config/XXXXX.tflite` (XXXXX is the file name, that is written in the `config.ini`)
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
# Neural Network Types
|
||||
|
||||
!!! Note
|
||||
For an overview, see [Choosing the Model](Choosing-the-Model.md).
|
||||
|
||||
@@ -7,7 +6,6 @@ This section is describing the different types of neural networks, that are used
|
||||
|
||||
|
||||
## Overview neural network type
|
||||
|
||||
There are two **types of input**:
|
||||
|
||||
* digits with rolling number (top town)
|
||||
@@ -33,7 +31,6 @@ No setting of the type in the firmware is necessary. The type can detect by the
|
||||
|
||||
|
||||
## Naming convention
|
||||
|
||||
| | Classification<br />11 classes<br />0, 1, ... 9 + "N" | Classification<br />100 classes<br />0.0, 0.1, ... 9.9 | Continuous<br />Interval<br />[0, 10[ |
|
||||
| ---------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------ | ------------------------------------- |
|
||||
| **Digits** <br /> | **dig-class11**_XXX.tflite | **dig-class100**_XXX.tflite | **dig-cont**_XXX.tflite |
|
||||
@@ -57,36 +54,28 @@ Example: `dig-class11_1410_s2_q.tflite`
|
||||
* q = Quantized Version
|
||||
|
||||
|
||||
|
||||
## Overview of trained types and details
|
||||
|
||||
### Analog Pointer ("ana-cont_XXX.tflite" & "ana-class100_XXX.tflite")
|
||||
|
||||
This is to transfer the direction of a pointer into a continuous number between 0 and 1, whereas 0 (=1) is the upwards position (12 o'clock), 0.25 corresponds to the 3 o'clock positions and so on. This network is a envelop for all different types of pointers. Currently there are no dedicated network trainings for specific types of pointers.
|
||||
|
||||
There are two types of network structure, currently both are supported. The "class100" is a pure classification network, that might need a bit more accuracy in the labeling. "cont" is a no classic approach with a continuous output off only 2 neurons (details see below).
|
||||
|
||||
#### Types of counters trained:
|
||||
|
||||
#### Types of counters trained
|
||||
| | | | |
|
||||
| ----------------------------------- | ----------------------------------- | ----------------------------------- | ----------------------------------- |
|
||||
|  |  |  |  |
|
||||
|  |  |  | |
|
||||
|
||||
#### Training data needs
|
||||
|
||||
* Quadratic images, minimum size: 32x32 pixel
|
||||
* Typically 100 - 200 images with a resolution of 1/100 of the full rotation (every 0.1 value or 3.6°)
|
||||
* Naming: x.y_ARBITRARY.jpg, where x.y = value 0.0 ... 9.9
|
||||
|
||||
#### CNN Technical details:
|
||||
|
||||
##### Input
|
||||
|
||||
* 32 x 32 RGB images
|
||||
|
||||
##### Output
|
||||
|
||||
* **ana-cont**_XXX.tflite:
|
||||
* 2 neurons with output in range [-1, 1] - representing a sinus / cosine encoding of the angle
|
||||
* needs to be converted to angle with arctan-hyperbolic function
|
||||
@@ -95,69 +84,52 @@ There are two types of network structure, currently both are supported. The "cla
|
||||
* 100 neurons representing the classes from 0.0, 0.1, ... 9.8, 9.9
|
||||
|
||||
|
||||
|
||||
|
||||
### Digits with 11 classes ("dig-class11_XXX.tflite")
|
||||
|
||||
The digit type is a classical classification network, with 11 classes representing the numbers 0, 1, ... 9 and the special class "N". It is trained for the rolling ring of gas and electric meters. As there is sometime a status between two images, the special class "N" is representing Not-A-Number for the case, that the image cannot be unique classified to one number e.g. because it is between two digits. For this type the lowest amount of training data per type is needed, resulting in a large variety of type being already part of the training set.
|
||||
|
||||
|
||||
#### Types of counters trained:
|
||||
|
||||
#### Types of counters trained
|
||||
| | | | | | | |
|
||||
| -------------------------- | -------------------------- | -------------------------- | -------------------------- | -------------------------- | -------------------------- | -------------------------- |
|
||||
|  |  |  |  |  |  |  |
|
||||
|  |  |  |  |  |  | |
|
||||
|
||||
#### Training data needs
|
||||
|
||||
* RGB images, with minimum size: 20x32 pixel
|
||||
* Typically 10 - 20 images (1-2 for each digit and an arbitrary number for the "N" class
|
||||
|
||||
* Naming: x_ARBITRARY.jpg, where x = value 0 ... 9 + N
|
||||
|
||||
#### CNN Technical details:
|
||||
|
||||
#### CNN Technical details
|
||||
##### Input
|
||||
|
||||
* 20 x 32 RGB images
|
||||
|
||||
##### Output
|
||||
|
||||
* 11 neurons for image classification (last layer normalized to 1)
|
||||
* Neuron 0 to 9 represent the corresponding numbers "0" to "9"
|
||||
* Neuron 10 represents the "Not-A-Number" class, telling, that the image is not uniquely classified
|
||||
|
||||
|
||||
|
||||
### Digits with rolling results ("dig-class100_XXX.tflite" & "dig-cont_XXX.tflite")
|
||||
|
||||
This type of network tries to overcome the problem, that there are intermediate values, when a rolling digit is between two numbers. Previous this was the "N" class. In this network type, there are also sub-digit values trained, so that the intermediate state can be used as additional information for the algorithms.
|
||||
|
||||
|
||||
#### Types of counters trained:
|
||||
|
||||
#### Types of counters trained
|
||||
| | | | |
|
||||
| ---------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ---- |
|
||||
|  |   |    | |
|
||||
|
||||
|
||||
|
||||
#### Training data needs
|
||||
|
||||
* RGB images, with minimum size: 20x32 pixel
|
||||
* Typically 100 - 200 images (1-2 for each possible position)
|
||||
|
||||
* Naming: x.y_ARBITRARY.jpg, where x.y = 0.0, 0.1, ... 9.9 representing the intermediate state
|
||||
|
||||
#### CNN Technical details:
|
||||
|
||||
#### CNN Technical details
|
||||
##### Input
|
||||
|
||||
* 20 x 32 RGB images
|
||||
|
||||
##### Output
|
||||
|
||||
* **dig-cont**_XXX.tflite:
|
||||
* 10 neurons representing the digits 0, 1, ... 9. The intermediate values are represented by weighted normalized values of two neighboring output neurons
|
||||
* needs to be converted to angle with arctan-hyperbolic function
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
# ROIs (Regions of Interest)
|
||||
|
||||
!!! Notes
|
||||
You are using a neural network approach which is trained to fit as many different type of meters as possible.
|
||||
The accuracy will never be 100%. It is normal to see a missing reading once in a while.
|
||||
@@ -76,9 +75,6 @@ In [Model Selection](Choosing-the-Model.md) you find the differences between the
|
||||
Here we only show the different configuration of the ROIs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. Digit Meters with only recognized full digits (`0, 1, 2, 3, ... 9`)
|
||||
|
||||
Suggested Model: `dig-class11-*.tfl`
|
||||
|
||||
Reference in New Issue
Block a user