Store azimuth(s) of camera positions in camera table

[fe51]

Context

First, some vocabulary to try to make it clear, usualy in our context, the "azimuth" refers to the azimuth of a camera's position ie : a camera can have, either only one azimuth (fixed cameras) or multiple azimuths (360 cameras where multiple defined poses are used with one azimuth for each pose)

To date, information relating to a camera's azimuth only reaches the alert API when a detection is sent.

On the alert management platform side, it is by consuming information on sequences (built on detections) that we retrieve the azimuth information for a camera (to be distinguished from the azimuth of the ‘average’ direction of a sequence of detections called "cone_azimuth")

Problem

Today, I would tend to think that this approach has limitations for various (future but required) uses :

Issues related to pages on the alert management platform:

• Camera dashboard, what we would like to do:

  • display the visibility cones of the different camera positions -> make it easier to select a camera from the dashboard map and get a quick view. -> Currently not possible
  • View or modify the occlusion mask for a given camera position -> Currently not possible

• Live Streaming : The azimuth information for the camera positions is only known because the platform has access to an API available on the Raspberry Pi -> why not, but a bit convoluted.

Other issue related to visibility analysis

Knowing the camera's azimuth, combined with information on its location and viewing angle, allows us to compute the precise coverage of our camera network -> it would seems logical to be able to access this information from the API. However, at present, it is necessary to combine the information from this API with information located elsewhere (in this case, stored in an Ansible configuration file and on the devices).

Expectations

Suggestion : Add the azimuth information for the camera positions as a new attribute in the camera table -> may be an array --> This would provide a solution for the issues described above.

I am aware that this topic raises, among other things, the issue of redundancy of certain information in the API.

What do you think ?

Happy to discuss it ! 🙂

[fe51]

@frgfm @MateoLostanlen

[RonanMorgan]

for me it's linked to this one : #499

I think it's better to have data in the table than in files.

[frgfm]

Hey there 👋

I'll try to give two options:

1. What I think we should do long-term: we'll have plenty of different cameras connected to the same API, perhaps some with 360 degrees, perhaps rotating cameras. We'll spend too much energy accommodating all of that, so I would suggest to simplify: only store the information that wouldn't change in a while. For me that information is the type of camera (you can stay it's bound to the resource & physical object). However, the angle can be changed with manual intervention, perhaps the GPS coordinates, and for rotating cameras as well. The responsibility of annotating the angle for a given picture sent through the API is the responsibility of the camera, not the backend API for wildfire detection in my opinion. (not speaking of any backend that can control the cameras, where that could be relevant though). And I really think we need hardware instrumentation to avoid manual input of azimuth
2. What could be done now: implement the logic you mention in the backend that controls the camera.

The recurring theme of "oh we have a new camera, can we add data to the database" is a dangerous road I think. We need to accommodate more cases each time, and migrations become more and more complex, while in theory the detection pipeline (vs. camera control) shouldn't be any different

What do you guys think? :)

[MateoLostanlen]

Hey @frgfm , I'm not sure I fully get your point

Right now, when we add a camera, we already have to define values like name, location, field of view angles, etc ....
If we just add an azimuth field with a tuple, it doesn’t fundamentally change the process, does it?

@fe51 by the way:
With Matias we’re running some auto-calibration tests, and it seems that the patrol isn’t perfectly accurate on Reolink cameras (we don’t end up exactly on the same position)
We still need to study the frequency to see whether we get mostly good positions with a few outliers, or a Gaussian-like spread around the target point since that could definitely impact this discussion

[frgfm]

Right now, when we add a camera, we already have to define values like name, location, field of view angles, etc .... If we just add an azimuth field with a tuple, it doesn’t fundamentally change the process, does it?

Depends how you see it, I'm on the mindset of having things in tables that are almost constant (gps coord yes, azimuth for a controlled camera not really). In that spirit:

• having a list/tuple of azimuths isn't very useful on its own in my opinion, we want to know what each picture azimuth is
• the camera control mechanism makes the potential azimuth of a picture almost non discrete
• however, wherever the control information is can always communicate in which position the picture was taken
  And reversely, if picture has an azimuth + camera_id, you can trace back in which position the camera was at that time.

Not sure I see how having azimuth in detection table is limiting (since we can join table for queries) apart from display purposes. The purest source of information for the vision cone display is what controls it --> remote camera control pipeline.

More or so, what I suggest:

• source the camera vision cone from the control pipeline (happy to chat about merging the control API + detection API but if we keep them separate, we need to take the information where it originates from)
• if fixed azimuth (meaning 1 value in camera same value for all detections) --> it should be in the camera table / if it's controllable or rotating --> shouldn't be in camera table but only on detections table

[fe51]

closed by #528