DynAIkonTrap issueshttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues2022-01-26T11:23:09Zhttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/13Raspbian Bullseye install fails2022-01-26T11:23:09ZRoss GardinerRaspbian Bullseye install fails### Summary
Install for Dyntrap on Raspbian bullseye fails.
### Steps to reproduce
- Install latest Raspbian release image can be done with Raspberry Pi Imager or otherwise.
- Follow installation instructions
### What is the curre...### Summary
Install for Dyntrap on Raspbian bullseye fails.
### Steps to reproduce
- Install latest Raspbian release image can be done with Raspberry Pi Imager or otherwise.
- Follow installation instructions
### What is the current *bug* behavior?
Install script fails. Complains cannot find some packages.
### What is the expected *correct* behavior?
Successful install message
### Possible fixes
In the short term, make sure to install Raspbian Buster v10. At time of writing, this is the "Legacy" version of Raspbian installable from the RPi imager.
To update dynaikontrap for the latest version, the install script should be modified to accommodate for raspbian bullseye. This would likely result in changing some required apt packages. TFLite runtimes must also be re-built for python 3.9. Support for PiCamera on Raspbian Bullseye must also be investigated. The whole system should be re-tested with these changes made and in python 3.9http://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/12Retrain SSDLite TFlite models on 320x320 input size data2021-12-08T12:15:04ZRoss GardinerRetrain SSDLite TFlite models on 320x320 input size data
### Summary
Picamera requires that output images must be sized in a multiple of 32. This was not known when model input size was fixed at 300x300px. This creates some messyness.
### Necessity/problem to solve
As a result, a hack is ...
### Summary
Picamera requires that output images must be sized in a multiple of 32. This was not known when model input size was fixed at 300x300px. This creates some messyness.
### Necessity/problem to solve
As a result, a hack is used to size the saved raw data to 320x320px, and then scale down before inference. This is needless extra compute for every raw frame, takes up more disk space than is required and is generally messy.
### Details
An attempt has been made to simply resize the input of the model before quantisation. However, this has resulted in precision/recall loss when compared with the original.
### Expected effort
The proper fix to this is to re-train SSDLite Mobilenet v2 models with an input buffer sized 320x320. This should create a model with the correct input buffer size, without as much accuracy loss.
**Person hours**:
I suspect this would take a couple of days
**Difficulty**:
Not too difficult if TF OD API is set up.
### I could work on this
Yes, I intend to at some point in the future.Ross GardinerRoss Gardinerhttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/11Don't distirbute JSON with trap code2021-08-30T13:15:06ZMiklas RiechmannDon't distirbute JSON with trap code<!---
Please read this!
Use this template if you have a suggestion to improve the project.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "suggestion" label:
https://gitlab.dynaikon.com/...<!---
Please read this!
Use this template if you have a suggestion to improve the project.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "suggestion" label:
https://gitlab.dynaikon.com/c4c/dynaikontrap/issues?label_name%5B%5D=suggestion
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
Don't distribute a default settings.json with our code. The system loads defaults anyway.
### Necessity/problem to solve
Changes between versions (new fields/functionality) meant we had introduced a `"version"` field to the JSON to verify the JSON will be compatible between camera trap versions. The problem is that this means every update requires us to maintain the version field in the JSON. If we forget to do this, it would result in the default JSON that not working with the current code version (an error/warning is displayed and default values used instead).
### Details
I would suggest simply removing the JSON from the repo to reduce overheads for us and reduce the risk of a non-functioning default system. This means users can generate a JSON if they want to modify settings. If they want to keep their custom settings between versions they would need to regenerate the file with the newest tuner.py (as would be the case anyway). The difference is that we can't accidentally provide an "incompatible" JSON due to an incorrect `"version"` field.
This could be followed up at some point with an updated tuner.py that handles old settings.json files and tries to use them with the newest version.
### Expected effort
<!-- Use the following two headings to indicate effort needed. Type "-" for each if you aren't able to estimate this -->
**Person hours**:
<1
**Difficulty**:
Easy -- remove a file
### I could work on this
YesMiklas RiechmannMiklas Riechmannhttp://gitlab.dynaikon.com/dynaikontrap/dynaikontrap/-/issues/4Make default motion filter use SoV2021-07-08T17:41:49ZMiklas RiechmannMake default motion filter use SoV<!---
Please read this!
Use this template to report a bug/error.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label:
https://gitlab.dynaikon.com/c4c/dynaikontrap/issues?label_nam...<!---
Please read this!
Use this template to report a bug/error.
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label:
https://gitlab.dynaikon.com/c4c/dynaikontrap/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
The default behaviour of the motion filter still uses the SoTV approach. As we determined that performance was better with SoV, the latter approach should be the default. It may be desirable to completely remove SoTV functions and make SoV the only approach.
### Steps to reproduce
Run system with non-zero `"small_threshold"` in settings.json
### What is the current *bug* behaviour?
System applies SoTV method instead of SoV
### What is the expected *correct* behaviour?
Out of the box use SoV
### Relevant logs and/or screenshots
-/-
### Possible fixes
There are two fixes:
- *[Quick & less invasive]* Make `"small_threshold"` zero by default, effectively disabling the small vector thresholding
- *[Preferred]* Change `run_raw()` in motion.py to be something like:
```python
def run_raw(self, motion_frame: np.ndarray) -> float:
x_sum = sum(sum(motion_frame['x'].astype(int)))
y_sum = sum(sum(motion_frame['y'].astype(int)))
x_sum = self.x_iir_filter.filter(x_sum)
y_sum = self.y_iir_filter.filter(y_sum)
return math.sqrt(x_sum ** 2 + y_sum ** 2)
```