This updates the vision API to mostly match the portions of Zoloto which are exposed by the sr.robot3 API. The main exception here is that orientation data is different to Zoloto as well as having an incomplete API. There's probably enough here to be useful for Kickstart though.
For reference, https://github.com/RealOrangeOne/zoloto/pull/312 adds documentation to the Zoloto types for what their axes are and it's that PR that I've used as reference for what the simulator should do.
I'm hoping that we can fully re-evaluate the state of the vision API after Kickstart and end up with the two APIs in agreement. For now the simulator emits a warning about the differences if the relevant code is used.
As part of this change I've reinstated the arena wall markers, though note that the approach for these is a bit different now, added a camera to the robot and also added markers to one of the token types (again see details below).
This also changes how the vision system approaches markers. In particular there is support here for flat (i.e: essentially zero-width) markers which are distinct from the object they are attached to. This means that all markers are now achieved like wall markers -- as a separate entity attached to the face where we want a marker. In turn this enables having different sized markers than the objects they're on, allowing for better modelling at the expense of slightly more effort in setting up the models.
This fixes #83 but trades off against less accurate occlusion handling as our vision system no longer knows the size of the object. This feels like the right trade-off given the Webots ought to be doing the occlusion anyway, so if we want to change that we should look to configure it better there. In general this change pushes more of the physical modelling into Webots, which is probably a good thing.
To aid with the modelling there are now a series of PROTO files here which add the models for the markers. For demonstration purposes, I've done the addition to the "Gold" token that remained from previous years and added a couple of them to the arena.
They now more obviously have a marker on them, though even better might be to find an actual marker texture we can use there.
For anyone developing an arena, the main changes are that the model of a marker should now always match F\d{2} in order to indicate that it is one of the newer style flat markers. Support for the older "box" style remains, as B\d{2}, though we should remove that at some point.
This updates the vision API to mostly match the portions of Zoloto which are exposed by the
sr.robot3API. The main exception here is that orientation data is different to Zoloto as well as having an incomplete API. There's probably enough here to be useful for Kickstart though.For reference, https://github.com/RealOrangeOne/zoloto/pull/312 adds documentation to the Zoloto types for what their axes are and it's that PR that I've used as reference for what the simulator should do.
I'm hoping that we can fully re-evaluate the state of the vision API after Kickstart and end up with the two APIs in agreement. For now the simulator emits a warning about the differences if the relevant code is used.
As part of this change I've reinstated the arena wall markers, though note that the approach for these is a bit different now, added a camera to the robot and also added markers to one of the token types (again see details below).
This also changes how the vision system approaches markers. In particular there is support here for flat (i.e: essentially zero-width) markers which are distinct from the object they are attached to. This means that all markers are now achieved like wall markers -- as a separate entity attached to the face where we want a marker. In turn this enables having different sized markers than the objects they're on, allowing for better modelling at the expense of slightly more effort in setting up the models.
This fixes #83 but trades off against less accurate occlusion handling as our vision system no longer knows the size of the object. This feels like the right trade-off given the Webots ought to be doing the occlusion anyway, so if we want to change that we should look to configure it better there. In general this change pushes more of the physical modelling into Webots, which is probably a good thing.
To aid with the modelling there are now a series of PROTO files here which add the models for the markers. For demonstration purposes, I've done the addition to the "Gold" token that remained from previous years and added a couple of them to the arena. They now more obviously have a marker on them, though even better might be to find an actual marker texture we can use there.
For anyone developing an arena, the main changes are that the
modelof a marker should now always matchF\d{2}in order to indicate that it is one of the newer style flat markers. Support for the older "box" style remains, asB\d{2}, though we should remove that at some point.