The question we have is can the Navx mxp be used with other drive classes like drive, arcade, and tank. We are not using mecanum wheels this year.
The code samples on the Navx mxp site are using
MecanumDrive_Cartesian(stick.GetX(), stick.GetY(), currentRotationRate ,ahrs->GetAngle());
It’s not clear to me if it can be adapted to other classes.
The NavX MXP can definitely be useful in autonomous, no matter what drive train you are using. Even drives like tank and west coast drive will not go perfectly straight, and you can use it to adjust your angle as you drive.
The NavX MXP is probably less useful in teleop, where a person can correct for any inaccuracies in the robot’s travel. If you wanted to implement a button that makes the robot just go straight forward/back or turn a certain amount it could be useful.
Thank you for your reply. What classes are you using with your Navx mxp?
Team 2465 has added four buttons to our driver station:
While we use a holonomic drive system (Mecanum), as long as your robot can spin, you can use during this during teleop when your robot is standing still. And you can get that to work while driving (to, say, ensure you are driving in a straight line) by working out the commands to your drive class that would cause it to turn a bit while driving in the current direction.
I’m not aware of any drop-in code for these features on a tank-drive style robot.
However, if you think it’d be helpful, I can point you to some FTC code that uses navX-Micro to control a two-wheeled tank-drive robot to “drive straight” using a PID controller - just let me know if you think that might be helpful. With some work, you might be able to port that to a FRC robot using the WPI Library.
The question I have is can this work well with the other classes, like arcade.
The RobotDrive arcadeDrive(double moveValue, double rotateValue) method can be used. The rotateValue would be derived from the yaw value from the navX-MXP. Since rotateValue is in units of -1 to 1, this value should be acquired from a PID controller. The navX-MXP AHRS class implements the PIDSource interface. So you can pass the AHRS class instance into the constructor of your PIDController object. Then, whenever you want to call arcadeDrive(), you’d ask your PID controller for it’s latest output value, and pass that as the rotateValue to arcadeDrive().
To rotate in place, the moveValue would be 0, the rotateValue would be the output from the PID controller.
To drive straight (or rotate while moving), the moveValue would be the speed to move ahead, and the rotateValue would be the output from the PID controller.
The feedback that you get from a quality gyro can be used in many different situations. For our 2014 bot, we used the yaw data from a Nav6 (the predecessor to the NavX) in our 2-ball autonomous routines; this was a 6WD bot that used a custom version of arcade drive (shout out to Team 254). Our bot drove straight that year, so we didn’t need to use it to correct for a drive-train that listed to one side or the other. However, in 2015, we used the yaw data from the Nav6 to drive straight when we wanted to and to strafe perfectly sideways when we wanted to; this was a 5-wheel omni drive system (holonomic drive). While these goals can be achieved with any quality gyro, we like the way that the Nav6 performed, so we have decided to move on to the NavX this year and in future years. You can look at our codebase (sorry for any trouble deciphering it) to see how we used it, but the important takeaway is that the Nav6/NavX is a quality sensor that can enable your bot to determine its orientation relative to the field throughout a 2:30 match, regardless of which type of drivetrain you use. The promotional materials emphasize certain drivetrains because you can get really interesting behaviour out of a mechanum or swerve drive when you incorporate a gyro; however, it is useful in a variety of scenarios. (We also used the Nav6 to achieve field-centric control on a summer project that has a swerve drive.)
TL;DR: if you want quality yaw data, this is a great sensor that has minimal drift over the course of an FRC match. It doesn’t matter what drivetrain you use; we have used it (with great results) on a 6wD, an omni drive (H-drive), and a swerve drive. The only thing that we actually haven’t used it on is a mechanum drive (which might be next…but definitely after 2016).
Thank you both for replying and sharing your advise and experience. We were actually able to jump to arcade and implement it with PID on the 2016 bot and were able to run it on the 2015 bot using mecanum Cartesian on the rotate to angle. Both robots used omnimount too. I am very impressed with Navx and hope that we have an appropriate use case. The quality of their site is impressive, and the customer service is excellent.