You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We receive a proto object from vision/simulator that describes the field. We convert it to our own Field type which is easier to use. But what if our received object contains missing information? And what if the received data is inconsistent? Filtering needs to be applied to ensure we use correct Field information, but that is not done at the moment.
Describe the solution you'd like
I suggest moving the conversion from the AI code to Observer code, as this is exactly why Observer exists. After that, Observer can apply filtering to make sure we have a proper representation of the Field.
Additional context
I suggest waiting until this PR is merged so having a reference of a Field is a bit more simple.
To send the filtered Field from Observer to AI, a new proto object that matches our way of describing a Field is probably very convenient, so I also suggest doing that. (I would be very willing to fix that part!)
The text was updated successfully, but these errors were encountered:
@Florisheinen1 Maybe a few points of discussion before I would start fixing this:
What to do in case we have not yet received a field from vision? There's basically 2 options:
Use a 'default field' with sensible sizes (e.g. the default division A sizes for example)
Do not pass a field at all/pass a null field.
I don't have a particularly strong opinion for either as I don't know enough about the AI, but I can imagine that in some situations having a field available is crucial. It also reduces the (mental) overhead of having to check if the field is present every time.
In my opinion we should use the last known field or pass a null field if nothing has been sent yet. Checking whether the field is present should be done anyway as not having a field does impact our winning chances. Also we would only have to check one time per game, since we can assume that the field will not change during the game.
Is your feature request related to a problem? Please describe.
We receive a proto object from vision/simulator that describes the field. We convert it to our own Field type which is easier to use. But what if our received object contains missing information? And what if the received data is inconsistent? Filtering needs to be applied to ensure we use correct Field information, but that is not done at the moment.
Describe the solution you'd like
I suggest moving the conversion from the AI code to Observer code, as this is exactly why Observer exists. After that, Observer can apply filtering to make sure we have a proper representation of the Field.
Additional context
I suggest waiting until this PR is merged so having a reference of a Field is a bit more simple.
To send the filtered Field from Observer to AI, a new proto object that matches our way of describing a Field is probably very convenient, so I also suggest doing that. (I would be very willing to fix that part!)
The text was updated successfully, but these errors were encountered: