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.
Currently, to replace the apriltag layout, it has to be manually done by coprocessor/photon instance. With WPICal being added to WPILib, teams are going to be using new layouts much more frequently, as they can now scan the field and get the real tag layout at an event. Further, if they are using a practice field that is setup/torn down every day, then they may be scanning a new tag layout every day. This would result in time lost at every meeting, which will add up over the course of a season.
This also means that it's impossible to have multiple layouts decided upon at runtime, such as in the case of using a layout anchored on the red goal vs one anchored on the blue goal. Such a layout would be desirable so that the more accurate and relevant map can be used depending on which alliance you're playing on, which is only determined at runtime typically.
Describe the solution you'd like
Being able to, from user code on the roborio, push an apriltag layout to Photon instances would solve both of these problems. Such an api would, at minimum, need to be able to take a json string (or a file location) and send the json string over network to a camera. This could be something like camera.useAprilTagLayout(String fileName);.
Describe alternatives you've considered
One possible solution could be to have a way to bulk update the tag layout file on Photon instances. This however seems impractical as it'd require some new tool to somehow connect to all photon instances and push the file.
Additional context
Previously, this was much less of an issue, as there was no easily available tool to scan apriltag layouts in the real world, but with the addition of WPICal, this is going to be something happening much more frequently, as having the actual tag layout (not just the theoretical one) allows greater accuracy and lower reprojection error.
As an aside, this sort of feature could be useful to send pipelines to the cameras at runtime as well. This would allow better version control of camera pipelines, removing the manual element to upload the pipeline to each camera. However, this has less utility than the ability to push apriltag layouts.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, to replace the apriltag layout, it has to be manually done by coprocessor/photon instance. With WPICal being added to WPILib, teams are going to be using new layouts much more frequently, as they can now scan the field and get the real tag layout at an event. Further, if they are using a practice field that is setup/torn down every day, then they may be scanning a new tag layout every day. This would result in time lost at every meeting, which will add up over the course of a season.
This also means that it's impossible to have multiple layouts decided upon at runtime, such as in the case of using a layout anchored on the red goal vs one anchored on the blue goal. Such a layout would be desirable so that the more accurate and relevant map can be used depending on which alliance you're playing on, which is only determined at runtime typically.
Describe the solution you'd like
Being able to, from user code on the roborio, push an apriltag layout to Photon instances would solve both of these problems. Such an api would, at minimum, need to be able to take a json string (or a file location) and send the json string over network to a camera. This could be something like
camera.useAprilTagLayout(String fileName);
.Describe alternatives you've considered
One possible solution could be to have a way to bulk update the tag layout file on Photon instances. This however seems impractical as it'd require some new tool to somehow connect to all photon instances and push the file.
Additional context
Previously, this was much less of an issue, as there was no easily available tool to scan apriltag layouts in the real world, but with the addition of WPICal, this is going to be something happening much more frequently, as having the actual tag layout (not just the theoretical one) allows greater accuracy and lower reprojection error.
As an aside, this sort of feature could be useful to send pipelines to the cameras at runtime as well. This would allow better version control of camera pipelines, removing the manual element to upload the pipeline to each camera. However, this has less utility than the ability to push apriltag layouts.
The text was updated successfully, but these errors were encountered: