Inertial object turn type

I’m working on my Odom function and I’ve gotten it to work with PID for both turning and when moving in a singular direction, however it doesn’t work when I tell it to move to X and Y. After looking back at my functions and testing every change, one in particular is odd. To get my turn to point function to work I went into the robot config file and set my inertial sensor’s turn type to left. This made the function work, however it changes how my odom function interprets X; instead of X decreasing from the origin (bottom left corner) it was increasing.

My question is what does passing the turn type do to the inertial sensor?

normally the inertial sensor will increase the value of rotation when turning clockwise (ie. to the right), changing turn type to left will reverse that behavior. It’s probably not a great thing to do. We have that capability for compatibility with some older sensors on other platforms.

lets say the robot has turned 45 degrees clockwise, instead of returning 45 as the rotation angle it would return (-45).

4 Likes

Isn’t this how trig works with angles: degrees increasing while going counter-clockwise and decreasing going clockwise?

Choice for the IMU was NED. The old yaw rate gyro was the same, that’s why default is turn type right.

1 Like

For any sort of math-related stuff you’re going to have to convert heading to an angle system that works with your localization coordinates. This usually means CCW-positive, and most existing libraries do this already.

That looks something like this (cpp):

std::fmod((360.0 - imu.heading(vex::degrees)) + offset, 360.0);

I prefer to do this over setting turnType from a library standpoint, since it’s better to not mutably control user hardware that might be used for other stuff, especially when devices can be copied across threads and whatnot yet still use shared state.

To be honest, its kind of painful dealing with NED (Z-down), since it doesn’t work with cartesian coordinate systems by default, especially when VEXCode’s drivetrain APIs teach people to think using these angles… It’s been a point of contention in LemLib’s development, which started with NED angles for public APIs but converted them internally, resulting in a mess between user-facing functions and internal stuff with incompatible angle returns.

There’s also conflicting axis labeling (notice how the first set of images are Z-up) on VEX’s official documentation which doesn’t really help the confusion either :stuck_out_tongue:

5 Likes