search

Spartronics4915 / 2020-InfiniteRecharge

Spartronics 4915's code for the FRC 2020 game: Infinite Recharge
GNU General Public License v3.0
10 stars 15 forks source link

Add camera mounting measurements #151

Closed loqoman closed 4 years ago

loqoman commented 4 years ago

@dbadb Here are the coordinate system transforms that were measured today during the drive practice.

Additionally, @pietroglyph and I noticed on diagram in the comments of the Coordsysmanager was wrong, assuming the front of the robot (the intake) is in the positive X direction. The turret was drawn on the wrong side of the robot.

PR, because it's likely I messed something up somewhere. If my git status is too messed up, someone can just push the numbers directly from their own stable clone.

dbadb commented 4 years ago

On the question of mnt location: indeed I've never actually had the chance to sit with the robot, so I really don't know about the orientation of the turret other than hearsay.

On your change: 1) it doesn't compile due to the mis-hap between constants and member variables. These constants - kCamFlipX etc are declare public static final which means that they aren't member variables. I'll go ahead the commit, then fix, the code. The important thing is the actual measurements. On that front, I see one that seems curious. Is it true that the camera is mounted at the same height as the turret? ie: the Z offset is 0? (oops! I now see that its 2.25 up)

dbadb commented 4 years ago

checking in, even with compile failures... I'll check-in fixes imminently.

dbadb commented 4 years ago

here are the fixes - (mostly restoring public static final constants).

https://github.com/Spartronics4915/2020-InfiniteRecharge/commit/690ad7dd24bbff7d8d2b378b57c395fb61d53d67

dbadb commented 4 years ago

@loqoman - curious whether you were able to get any evaluation done of the accuracy / efficacy of the vision results?

loqoman commented 4 years ago

@dbadb During the drive meetings we have not done any vision integration testing with the EKF, mostly due to other items taking presidence. Few tidbits: 1) One of the model points we were testing with was incorrect, which was something I spotted during tuning 2) I added some baseline code to also report horizontal offset of the target in the 'PID' fashion (right of the screen is an error of 2, left is an error of 0. Ideally this would not be used in competition for tageting, but the way things are looking from a full systems integration standpoint, we may end up with a hacky solution at GP.

Other than what's being discussed in the Pi power thread, things have been relatively smooth sailing on my end.