Not for immediate implementation, just some thoughts we'll want to consider and see how it evolves over the season. Feel free to collect comments here based on common roadblocks we find teams have.
We may want a section to talk some of the details of the software lifecycle. Namely:
1) During build season, keep up to date with latest releases - we expect improvements and bugfixes
2) Before you go to competition, lock down your functionality as best you can. Choose a date to freeze your software versions, and do your final testing and validation
3) During competition, have an offline copy of all the relevant files. This includes .jar's and pi images for both the version that you locked down, and any future releases that come out
4) Only perform the upgrade at competition if it's deemed critical ("change one variable at a time")
5) After competition, goto 2.
Probably want a separate section for "Tuning advice" where we talk through the "why" of the low-exposure
Retroreflective - you want dark image
APriltag - you want to minimize blur
Resolution comment might be misleading. The complete answer is "pick resolution whcih achieves your processing goals" and "use stream resolution to reduce bandwidth".
Order things chronologically as teams would walk through them in the build season (first HW selection, then tuning, then pre competition, at competition, etc....)
Not for immediate implementation, just some thoughts we'll want to consider and see how it evolves over the season. Feel free to collect comments here based on common roadblocks we find teams have.
Builds on the excellent start in https://github.com/PhotonVision/photonvision-docs/pull/203
We may want a section to talk some of the details of the software lifecycle. Namely:
1) During build season, keep up to date with latest releases - we expect improvements and bugfixes 2) Before you go to competition, lock down your functionality as best you can. Choose a date to freeze your software versions, and do your final testing and validation 3) During competition, have an offline copy of all the relevant files. This includes .jar's and pi images for both the version that you locked down, and any future releases that come out 4) Only perform the upgrade at competition if it's deemed critical ("change one variable at a time") 5) After competition, goto 2.
Probably want a separate section for "Tuning advice" where we talk through the "why" of the low-exposure
Resolution comment might be misleading. The complete answer is "pick resolution whcih achieves your processing goals" and "use stream resolution to reduce bandwidth".
Order things chronologically as teams would walk through them in the build season (first HW selection, then tuning, then pre competition, at competition, etc....)