Conversation
There was a problem hiding this comment.
main comment about the thread and simulation. Otherwise looks good. I still think moving the Vision system into its own subsystem and then maybe centralizing the "state" for odometry and stuff like a few other teams have done may declutter things a little.
| new Thread(() -> { | ||
| Timer timer = new Timer(); | ||
| while (true) { | ||
| if (timer.advanceIfElapsed(10.0) && !isPhotonOk.get()) { | ||
| try { | ||
| uploadSettings(cameraIP + ":5800", | ||
| new File(Filesystem.getDeployDirectory().getAbsoluteFile(), | ||
| "photon-configs/" + cameraName + ".zip")); | ||
| } catch (IOException e) { | ||
| e.printStackTrace(); | ||
| } | ||
| } | ||
| Thread.yield(); | ||
| } | ||
| }).start(); | ||
| } |
There was a problem hiding this comment.
Should only do this if in simulation mode.
There was a problem hiding this comment.
Probably. Agreed on the separate "Vision" subsystem.
| var res = inputs.result; | ||
| if (res == null || inputs.timeSinceLastHeartbeat > 0.5) { | ||
| var res = this.camera.getLatestResult(); | ||
| if (res == null || Timer.getFPGATimestamp() - res.getTimestampSeconds() > 0.5) { |
There was a problem hiding this comment.
U should be able to use latency() > 0.5 since u have the same function below
There was a problem hiding this comment.
I think latency is actually different from this (calculated pi-side). I'll check, but I agree it should be consistent whatever we do here.
2 participants
As we've seen with simulation stuff, not having an actual
PhotonCamerais a big barrier for using much of PhotonVision's API. This update gets us roughly the same behavior as the oldPhotonIO, but as an extension ofPhotonCamerainstead of a replacement. NowPhotonCameraWrappercontains an instance ofPhotonCamerathat could be used for simulation.