Hey, so my team’s turret software is going to be maintaining a static position. Basically, if our drivetrain moves forward by some amount, or rotates by some amount, the turret has to account for that movement and adjust so that it maintains it’s original position. I’ve been given robot gyro data and turret position (angle) data, but I’m having a hard time coming up with the solution.
Does anybody have any ideas?
If you have encoders on your wheels, you can combine them with your gyro to track your robot’s location on the field in what’s called odometry. If you’re programming using WPILib, you can use DifferentialDriveOdometry to do that easily (Java, C++).
However, although the sensors are quite accurate, note that over long periods of time your odometry will become less and less accurate and will drift. If you use vision processing on your robot, you can use it to “reset” the odometry every time your robot sees the target.
I believe you have all the sensory data you need to achieve this(Although using odometry with encoders should be more accurate since you would be using 2 sensors instead of just 1). Judging by the fact that you know the angle of the turret, I assume that you have an encoder on that. You can write a PID loop that uses your robot angle as a setpoint (-robot angle). To examplify it, if your robot turned 30 degrees, your turret PID should have a setpoint of -30 degrees therefore turret is set to 0 degrees from your starting config. But be careful about gyro drift because it may cause up to 6-7 degrees of error near the endgame. You might want to reset your gyro position time to time as @dan suggested.
Maybe I’m missing something, but if for example the robot drives directly backward, the gyro measurement won’t change but your turret will still need to point somewhere else.
That is absolutely correct, to get around that you need to use an accelerometer then integrate over time to find the distance travelled. I do believe that the simplest way to track the goal would be to use vision. Everything else here is fancy dead reckoning, add a camera and then you have on input not related to the robots motion frame.
Oh, I totally misunderstood what you guys were trying to achieve with “static turret position”. In that case, @dan’s idea is the only logical way I can think of.
You have me confused with original poster. Both of our icons are an A but that is it. I can only guess at what they are trying to achieve.
Ps
I just realized encoders can be used to find distance travelled and then trig can be utilized to adjust the turret from there. Again all dead reckoning which is often harder to tune and gives meh results compared to external sensing.
I’m planning on using odometry to point at the target when the robot is driving around the field, and then using a limelight to aim when we’re ready to shoot, and then using the limelight data to update the odometry. I have code for this but most of it is untested still. If you want to look at it, it’s here: https://github.com/phlogiston1/frc-3461-2020/blob/master/src/main/java/frc/robot/RobotState.java
So you know: Angle of the robot relative to the floor, angle of the turret relative to the robot.
Using this, can you get the angle of the turret relative to the floor? Yes, you can.
Now, have your control loop control this combined angle as its input, and as its output adjust the turret position.
If you do this right (get the +/- signs right and everything), your turret will change relative position based on the orientation of the robot you get from the gyro, in order to maintain the actual position. It may not be instantaneous, it may lag behind the robot a little, but it’ll work and you can tune from here.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.