We built a turret this year and I want to have our turret turn to a home position after being used. We have a Pigeon on the turret and a NavX on the robot they are on the front side of the robot and turret is on the left and the Rio is on the right. I was planning to just subtract robotAngle from turretAngle. Trying this resulted in a very high value around 40-90 degrees. Could this be because of different gyros having different angles per a full rotation. Do you guys have any ideas?
Both gyros report angles relative to where they were when they turned on. If your turret is at different angles relative to the base each time you start, that would explain the difference.
You should also make sure that both gyros report positive rotation the same direction.
Not a solution, but a general problem solving strategy:
- Identify (or create) two variables in your code. One will represent “robot angle relative to field”, and the other will represent “turret angle relative to field”
- What units will each have? What will “0” mean for each? What will positive values mean for each? There are multiple possible correct answers, but you have to pick just one. I like “degrees” and “0 = straight toward opposing alliance station”.
- Print out the value of the units. SmartDashboard,
System.out.println(), Shuffleboard, debugger, etc. Get it so you can inspect the value of each variable at runtime.
- Set the robot on the field, in a certain orientation. Decide, before looking at the values, what you think they should be.
- Check if the values match your exceptions
- If yes, pick another orientation, and repeat.
- If no, start debugging. Which number is wrong? How is it wrong? Just units? Always zero? Correct magnitude, but wrong sign? Random and noisy? Each of these could suggest different root causes.
Once both numbers are behaving as you expect, then and only then do I agree that your general strategy will likely work.
Note that most folks I’ve talked to used encoders to determine turret orientation, not a gyro. However, i suspect for lots of cases, your solution will be sufficient.
They report both zero when the robot starts. I will check with the orientation and report again.
Also make sure that you know if clockwise is positive or counter clockwise is positive. If you like math, you’d make everything in your code use counter clockwise (CCW) as positive. If you don’t want to create a custom Gyro interface, then clockwise is fine. You just have to make sure when you add/subtract the angles you actually know what they represent.
If you posted code/logic, we may be able to help debug it.
This isn’t really a solution to OP’s current problem, but I see this as an opportunity to discuss the thought process behind sensor selection on robot subsystems (as brought up by @gerthworm).
In the case described, the desired measurement is the angle of the turret relative to a fixed angle on the robot base. Since rotation of the robot base should not change the relative angle, using a gyro on the turret seems like a bit of overkill. I would recommend exploring an encoder or potentiometer-based solution in the future as it will give you stable relative location information.
You may have noticed gyros have a tendency to drift over time so “zero” will not remain in the same location for very long. Various factors can make the drift better or worse, and all sensors will have different properties. This could lead to the robot IMU and the turret IMU disagreeing over the course of a match.
As @Joe_Ross mentioned, check how the values change as you rotate the robot. The navX and Pigeon are opposite. From the Pigeon docs
Moving counter-clockwise is interpreted as a positive change.
From experience, the navX is the opposite.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.