This repository was archived by the owner on Oct 8, 2024. It is now read-only.
Update vision to (mostly) match Zoloto - #352
Merged
Merged
Conversation
The SR vision API now uses radians due to moving to `zoloto`. This commit does not change the shape of the API, just the units, so that the API shape changes can happen separately. This converts all computation and APIs, however keeps degrees in the tests and other places where humans need to eyeball the numbers to understand them.
Previously this information was provided via the API, however it isn't any more. Our vision logic does need some handling for this so we keep some basic support for it internally.
This has some places where we're missing stuff, as well as places where we're not yet computing the right values, however this mostly gets the types into the right shapes. Given Zoloto's limitations around Spherical types I've kept our existing PolarCoords type around for now.
PeterJCLaw
marked this pull request as ready for review
October 21, 2022 14:29
This probably isn't the ideal robot to be using, but it's the one that's here.
This is based on how they were previously, with tweaks to update them for the latest webots and ensure they're in the right positions in the arena.
This isn't perfect, as bigger markers ought to be visible from further away, but is better than not limitting it.
This changes how we filter these out and now relies on the orientation of the object in Webots, however there were already couplings between the marker definitions and the code so this shouldn't be an issue.
PeterJCLaw
force-pushed
the
update-vision
branch
from
October 21, 2022 14:56
3e5f344 to
05e0fa1
Compare
This presents a much more cohesive approach which should match how markers will behave in reality rather than assuming that they're cubes. For speed I've left a lot of the existing naming alone even though it's now a bit confusing.
This is unlikely to be important at Kickstart and as long as it's clear that it could change, fixing it later allows us to prioritise other things right now.
PeterJCLaw
force-pushed
the
update-vision
branch
from
October 21, 2022 16:27
05e0fa1 to
d165539
Compare
Adimote
approved these changes
Oct 21, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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, RealOrangeOne/zoloto#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.