Our team is new to swerve and we’re designing the swerve code for the 2023/2024 season using several different code repos as our guides.
One common theme we see in these repos - they have a switch for the field centric vs robot centric swerve.
The question I have - do you really need both? More importantly - if the field-centric swerve is working, why would you ever want to switch to the robot-centric one? Use cases would be appreciated. In our case over the years the drivers seem to mostly ignore the driver cameras during the game (even though we were able to get little-to-no-lag stream in the last few years), so perhaps my opinion is a little biased.
The reason why I ask - we’re making the code simple, and we do not want to have logic there that is actually not used. Hence, current version we develop is all about field centric swerve. But we can certainly put the robot centric logic back if needed.
Not for this field, we didn’t use anything but field centric. If you had lots of visual obstructions possibly, but I don’t have any great examples. I don’t think it was necessary last year either, but maybe some used it for the back side of the goal. Maybe if they added sandstorm back robot centric camera driving would be helpful.
We had both to start but removed the button for robot centric entirely. I feel visual obstructions would make it even more likely to use just field centric, as I don’t need to see the robot to knnow which direction I’m trying to go. As @ngreen said, I could see it being useful if the driver was using a camera to drive/line up. That’s about the only use case I think of currently.
I imagine if you’re driving the robot not on the field (parade), you would find a use out of it.
If your gyro breaks somehow, which would be weird, then you could use it.
If your drivers ever operate the robot by using an onboard camera that streams a view to the driver station, then robot centric controls are useful. Such a scheme could be useful if it is difficult to see certain areas on the field or if there was something like the 2019 sandstorm period.
The only time(s) we had that was when we had CAN break, and that results in many more issues than just IMU.
I believe Rio has its own built-in gyro. It’s crappy, but can be used as a backup if you want to account for that.
So, based on the replies so far, I guess it’s safe for us to exclude the robot-centric code for now.
We will see what the next game brings, but it would be easy to add it back in.
Robot-centric mode is essential if your drivers are ever going to look drive while looking through a robot camera. In that case, they need left to move robot (and camera) left. The same functionality can make programming autos easier in certain cases such as when a path has to be generated on the fly based on machine vision.
That said, get field-centric working first. It’s by far the most valuable driving mode.
Field centric is good if you as a driver can see the robot at all times or most of the times. Robot centric is good for the 2019 Sandstrom period or in a game where the robot is out of your line of sight for more than 2-5 seconds and you drive using a camera/HUD.
I drove swerve this season and I don’t think I used robot-centric a single time during a match. I did use it almost any time we went on a practice field or did functionals in the pit though, since you don’t always know the orientation the gyro zeroed at.
We had a toggle for robot centric in case our gyro failed. Robot centric was also sometimes nice if we needed to line up with something, but most of the time we didn’t use it anyway.
Not quite the same, but we had a jumbotron centric drive (field centric but rotated) during sandstorm then it switched to field centric during teleop.
This was our first year with swerve. We had a button that the driver could use to toggle between field-centric and robot-centric drive. He rarely used the robot-centric drive, but it was mostly useful in cases where the driver was positioning based on camera feed. If you are trying to pickup a game piece on the floor behind a field element (thinking of games like 2016 or 2018) then robot-centric could be advantageous (though certainly not the only way to achieve that objective).
Just as a counterpoint here…
What are you really saving? Field centric is exactly robot centric, plus a tiny bit of coordinate transformation, based on a data point from an IMU. Robot centric is a natural step along the way, and a nice fallback if the IMU stops working or winds up being off for whatever reason. Robot centric is using the coordinate system you need for aligning the modules, and probably the one you will use any time the robot is up on blocks, for debugging, etc. Having both options could also be helpful in autonomous in some cases.
Taking this out strikes me as a false savings – you save literally a couple of lines of code, but you lose quite a bit in the balance. You can always choose not to allow the operator to switch out of field centric, but even this seems unwise in my experience.
Robot centric was pretty big last year. If the other alliance had no robot centric, camera driven robots available, you could plop a few balls behind the hub and they would likely not be touched the whole match. One of our autons did this and it was extremely useful.
By contrast we implemented a robot centric button and it occasionally gave us 1-2 extra cycles. Worth it.
I wish we had robot-centric mode for ground pickups this year. Especially cones.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.