We’re having an issue with our Ramsete commands in relation to our gyro and field odometry that we’ve been spinning on for the last week. If we set our gyro to be counter-clockwise positive, our odometry looks correct, but the Ramsete commands spin out of control. It almost appears that the robot is trying to correct itself rotationally, but opposite to the direction it should be going. When we invert the gyro heading output to counter-clockwise negative, our Ramsete commands work “correctly”, but our Y is flipped on those operations and our headings are reversed in the odometry object.
We’ve scoured Chief Delphi, trying recommendation we’ve seen like flipping the voltage on one of the tank drive outputs, but we’re at a loss at this point and looking for guidance.
If someone has time to take a look, the main relevant files are our drive train code and our Ramsete command. Any recommendations would be greatly appreciated
Yes, all of them and unfortunately nothing helped … We either go counter-clockwise negative from the Pigeon and everything drives “perfectly” as far as distances go, except left is right, or go counter-clockwise positive and odometry displays correctly in shuffleboard, but the robot spins violently out of control. There’s got to be something that we’re missing in regards to orientation, some kind of mismatch, but we’re at a loss to find it after way too many hours of trying.
So I had something like this happen. Somehow I’d setup my CAN ids to drive controllers incorrectly flipping the left and right side. Might check and it is a way to change y direction if not able to actually fix it. It should otherwise be the positive encoder direction. And the config for the trajectory being the right way.
I didn’t find anything with your trajectory code that was incorrect.
I did see you don’t invert the speed in your arcade drive. I have to do that because the joystick y axis is -1 in the full forward position. So I still think you may have right and left sides in can ids flipped. Check that the motors are on the expected sides, you can identity them in the tuner if necessary. Then you can add invert to xspeed to account for joystick for teleop driving. I assume it is driving normally in teleop because that isn’t inverted.
The Y axis is -1 when pushed up, and 1 when pulled down. The X axis is -1 when pushed left, and 1 when pushed right. So, normally you would invert the Y axis so the robot drives forward when you push up, but you would not invert the X axis because you want the robot to spin right when you push right. If you need to invert X to get the correct behavior something isn’t right with your IDs or motor inversion or wiring.
I was thinking that it might be motor inversion. We did look at that, but I don’t think we were methodical enough in our testing. I’ll put the drivetrain on blocks tomorrow and check in test mode; confirming feed forward voltages vs encoder values. Thanks for the recommendation and fingers crossed.
That sounds like you’re going to check sensor phase. Since you are using the TalonFX integrated encoder it cannot be out of phase. Even so, sensor phase would not explain why you have to invert the XBox controller’s X axis.
I suggest you put the bot on blocks. Use Phoenix Tuner to verify the IDs for your motors; select the controllers by ID as defined in your RobotMap and blink them. Make sure what you think is the right side is, in fact, the right side. As @ngreen pointed out, I bet you will find that what you thought was the right side is actually the left side. You’ll just need to correct your IDs and remove the X axis inversion in your teleop code.