Conversation
Levercpu
requested review from
MikeKantrowitz,
armadilloz and
batchen1
as code owners
src/main/java/frc/robot/subsystems/swervedrive/SwerveSubsystem.java
Outdated
Show resolved
Hide resolved
| Constants.SET_MODULE_ENCODER_AUTO_SYNCHRONIZE_DEADBAND); // Enable if you want to resynchronize your absolute encoders and motor encoders periodically when they are not moving. | ||
| // swerveDrive.pushOffsetsToEncoders(); // Set the absolute encoder to be used over the internal encoder and push the offsets onto it. Throws warning if not possible | ||
|
|
||
| rawOdometry = new SwerveDriveOdometry( |
There was a problem hiding this comment.
Looking more closely at what we need to do, I am not certain we want raw odometry without vision. The YAGSL maintains a SwerveDrivePoseEstimator which wraps around a SwerveDriveOdometry which extends PoseEstimator which has support for vision measurements.
So it seems to me that when we are processing a vision input from the camera, we should be comparing it against the latest known position, including all the previous vision adjustments, to help us filter them odd ones out.
So I am no longer sure we need getOdom that only considers odometry from the swerve, certainly YAGSL does not maintain one.
Also, maintaining an extra odometry calculation seems expensive.
Am I missing something?
There was a problem hiding this comment.
our vision filter would need to be refactored then
There was a problem hiding this comment.
I don't see why. Maybe we should discuss so we can plan.
There was a problem hiding this comment.
maybe put in sim wrapper (with utility class)
| public double getError() { | ||
| return getPose().getTranslation().getDistance((getSimulationPose().get().getTranslation())); | ||
| } | ||
| public double getAverageError(){ |
There was a problem hiding this comment.
I'm curious to see whether this contains any non-zero values - AFAICT, the simulation pose is only applicable in simulation and the real pose is only available in non-simulation, so when would we be able to compare them?
There was a problem hiding this comment.
the getpose is the estimated pose from the vision measurements and drift adjusted odometry (trying to model real life performance)
There was a problem hiding this comment.
getPose is swerveDrive.getPose(), which is the combined vision and odometry. swerveDrive.getSimulationDriveTrainPose() is the pose during simulation. What does the difference between them tell us?
There was a problem hiding this comment.
the getpose has simulated error added on
There was a problem hiding this comment.
put in wrapper kept for now
|
|
||
| @Override | ||
| public void processQueue() { | ||
| double currentTime = Logger.getTimestamp()/1000000.0; |
There was a problem hiding this comment.
I don't see what these changes amount to: Other than more log entries, what is the purpose?
With all the details being change like variable names and locations, it's really hard to distill the semantics of what changed.
There was a problem hiding this comment.
easier to count how many tags we saw over the last second, allowing us to know if we had steady vision in the last second. (one thing that batchen said she wanted to be able to know)
There was a problem hiding this comment.
So we should ask BatChen what she asked for. Can you ping us both on Discord so we can discuss?
src/main/java/frc/robot/subsystems/swervedrive/vision/estimation/PoseManager.java
Outdated
Show resolved
Hide resolved
| FilterResult r = entry.getValue(); | ||
| for (Map.Entry<VisionMeasurement, FilterResult> filterEntry : filteredData.entrySet()) { | ||
| VisionMeasurement v = filterEntry.getKey(); | ||
| Apriltag tag = v.tag().tag(); |
There was a problem hiding this comment.
If I'm not mistaken, this is the only place where the TagPose class is used. I believe everything this class could be achieved by the AprilTag itself since it already has its own pose.
Also, since the pose is fixed per tag, logging the pose is not that interesting since it will always be the same.
There was a problem hiding this comment.
batchen said she wanted to be able to see the tag poses and tag ids together in one logging for easier lookup
There was a problem hiding this comment.
Lets discuss with her...
…ision_Simulation
…a_2026 into LS_Vision_Simulation_+Logging # Conflicts: # src/main/java/frc/robot/apriltags/SimApriltagIO.java # src/main/java/frc/robot/subsystems/swervedrive/SwerveSubsystem.java
…a_2026 into LS_Vision_Simulation_+Logging # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
…ision_Simulation
…ision_Simulation
…a_2026 into LS_Vision_Simulation_+Logging
…ision_Simulation_+Logging # Conflicts: # src/main/java/frc/robot/Robot.java # src/main/java/frc/robot/apriltags/SimApriltagIO.java # src/main/java/frc/robot/constants/GameConstants.java # src/main/java/frc/robot/subsystems/swervedrive/SwerveSubsystem.java
2 participants
No description provided.