search

PhotonVision / photonvision

PhotonVision is the free, fast, and easy-to-use computer vision solution for the FIRST Robotics Competition.
https://photonvision.org
GNU General Public License v3.0
264 stars 180 forks source link

Simulation does not increase timestamp if nothing changes #1180

Open prensing opened 7 months ago

prensing commented 7 months ago

Describe the bug As best as I can tell, in the simulation, if everything is static (no user input, etc), the PV simulation returns the same result without incrementing the solution timestamp. This happens even when the robot is seeing multiple tags. If you tweak the robot pose by just a little, it bumps the timestamp for a cycle or two.

To Reproduce Run simulation, have the robot looking at a tag but not moving at all. Odometry updates stop working because it believes it has handled that frame. I will post our code repo shortly.

Platform:

prensing commented 7 months ago

If anyone wants to see, our code is here. Use the "visionFixes" branch. https://github.com/ligerbots/Crescendo2024/tree/visionFixes

I will try to do some debugging in PV, but need a break for now.

mcm001 commented 7 months ago

Skull.png

mcm001 commented 7 months ago

Skull.png

prensing commented 7 months ago

OK, this looks like an inconsistency or maybe bug in Networktables. The code in PhotonCameraCim.submitProcessedFrame() is updating lots of values with the timestamp: ts.targetYawEntry.set(bestTarget.getYaw(), receiveTimestamp); The only one that is actually changing is the heartbeat. Looking in OutlineViewer, all the timestamp values are not changing except for heartbeat.

I am not sure I can get beyond that. The NT.set() call immediately goes into a JNI call.

prensing commented 7 months ago

I assume that there is no method in NT to force it to update the timestamp. However, I added a small amount of uncertainty by setting some calibration error (SimCameraProperties.setCalibError()), and now my simulation updates every loop, even when I am not touching the controls.

Should the default camera always have a small amount of error? I tested: prop.setCalibError(0.001, 0.0005); and that was enough. The values like targetArea and angles were changing in the 3-4th decimal place, so that really is well below real error.