Compute the detection cone for triangulation

[MateoLostanlen]

Hello API team!

The firefighters have requested a triangulation feature, so we are currently developing it on the platform side. The principle is quite simple: if two stations detect the same fire, we can estimate the location by calculating the overlap of their detection cones.

As a reminder, on the platform, the detection cones are computed in the following function. Using the camera's field of view, its central azimuth, and the detection bounding box, we can infer the detection center azimuth and its angular opening.

Until now, calculating this on the platform side wasn’t an issue because we only displayed the cone for a single sequence—the one shown on the screen—for which we had already retrieved all the necessary information.

Now, to perform triangulation, we need to find matching sequences, which requires detection cone information for each sequence. If I do this on the platform side, I would have to load the detections for each sequence to extract a bounding box and compute these parameters, which is inefficient.

I propose moving this calculation to the API side. When a new sequence is created, we simply take the first non-null bounding box and compute the detection cone parameters. I suggest adding a new column, detection_cone_parameter, to the sequence table, storing this value as a tuple (detection_azimuth, detection_opening_angle).

Is this okay for you?

[MateoLostanlen]

@frgfm Is this issue okay for you? I just want to make sure everything is good before my holiday break, even though I'll remain available

[frgfm]

My apologies, I read it first and thought I need to think about it a bit more before answering!
Reading your issue again, I think I need to clarify something: when you say "triangulation" do you mean only providing the vision cone for the frontend display? or do you mean actually locating the wildfire center with GPS coords?

If this is the vision cone, I'm not sure I follow.
If this is GPS coord of the wildfire, here is what needs to be done regardless of where the computation happens:

1. when a new sequence is created, we check for intersecting ongoing sequences using the vision cone (GPS of camera + angle of view + azimuth more or less)
2. if at least one, we refine the intersection and mark the GPS coords of the approx location (barycenter of overlapping vision cones)

Is my understanding correct?

[MateoLostanlen]

We've discussed this before, I believe you're still confusing the camera's field of view (which we previously displayed on the platform) with the detection cone (calculated from the bounding box that we currently display on the platform). I recommend rereading the previous message 🙂

Our goal is to display the intersection of the detection cones without having to load an entire sequence

[frgfm]

We've discussed this before, I believe you're still confusing the camera's field of view (which we previously displayed on the platform) with the detection cone (calculated from the bounding box that we currently display on the platform).

You're correct, I should have said GPS of camera + detection cone, my bad! But my question stands 😅 Correcting the wording, can you confirm the following (again, regardless of where we'll do the computation):

1. when a new sequence is created, we check for intersecting ongoing sequences using the detection cone (I imagine we can assume the detection cone is the same for the entire sequence right?)
2. if there is at least one, we refine the intersection and mark the GPS coords of the approx location (barycenter of overlapping vision cones)

I'm trying to make sure we agree on the logic before discussing where this should be done 😃

[MateoLostanlen]

Hi @frgfm sorry for the late reply I was on vacation

Yes!

We compute the detection cone for each sequence. It's not exactly the same because the bounding box changes, but let's take the first one—it should localize the wildfire better.
We compute the intersection.
We display both the cone and intersection on the platform, and why not an approximate location using the barycenter.
I want to do at least the first step on the API, we can discuss the others

[frgfm]

Alright, let's do this!
Few last questions so that I can handle this quickly: how do we define the detection cone exactly?

• GPS + left azimuth + right azimuth
• GPS + left azimuth + right azimuth + top tilt angle + bottom tilt angle

Assuming this is for display on a map, I imagine we can go for GPS + left azimuth + right azimuth but then, since it's meant for intersection, we can't have it go to infinity. How should we define the "range" ? (how far does that cone go ?)

I suggest:

• detection cone definition: GPS + left azimuth + right azimuth (no range since we don't yet know how to compute it automatically)
• intersections: without range conditions, this becomes easy equation resolution (instead of polygon resolution). And then we'll only have to filter out intersection that are "too far from their origin cameras" (say 40km)

Ideally we'd like an automatic range per camera with computer vision calibration but for now, let's see how that fares

Let me know if that's good for you @MateoLostanlen 👌

[MateoLostanlen]

Hello @frgfm

On the API side, you just need to return a cone. We’ll handle the intersection on the platform side for more flexibility

So ideally, if you can return a tuple (detection_azimuth, detection_opening_angle) for each sequence, that would be perfect

For that, I refer you back to my first message: when creating a sequence, you take the first bounding box and compute the cone using this function. You can then add the tuple to the sequence table

Let me know if you have any other questions 😃

[frgfm]

Gotcha, so the detection cone is actually: azimuth of the left boundary of the detected bbox + azimuth of the right boundary of the detected bbox. If so, that's pretty straightforward to implement

(since the GPS is available for the camera)