Implementing a "global" grid movement

Not sure how to phrase it, but has anyone tried to implement like a global movement system, so that if you move left on the joystick, the robot moves left (in relation to you, rather than in relation to the bot) irregardless of its rotation.

I was just thinking about this in terms of quality of life, rather than having to think about what direction the robot in facing, and therefore adjusting what direction you try to move, you instead have a sort of global movement so you only have to worry about rotating the robot and moving in a predefined grid.

I assume you’d need a drive that can drive in all directions, like X drive or mecanum, and you’d either need odometry or at least an inertial sensor to tell rotation of the robot.

Would it even be worth it? Or would it be worth just learning how to drive properly

2 Likes

An inertial sensor is all you need. Someone in our organization has done this before; he called it “field centric control”, and I eventually was able to replicate his code. Put simply, all you need is an inertial sensor to give you the heading, and then you can use trigonometry (sine and cosine) based on the heading you’re given to alter the joystick values accordingly such that the robot moves relative to the field rather than its current perspective. Theoretically, you could only really do this with a holonomic base because of the layout of the controls, but maybe it’s possible with a tank drive depending on the layout?

4 Likes

How well did it work?

I assume you’d need holonomic, since tank drive doesn’t have the ability to strafe, so it wouldn’t be able to move left if it wasn’t facing left (unless some weird thing with it turning before moving)

Was it useful, did it help with the actual gameplay, or was it just a feature that was novelty but didn’t end up helping.

Never thought about it that way of changing the joystick values rather than just some way of moving the robot separate from the joysticks

1 Like

I will say it was a matter of preference. I personally do not find it more intuitive to use that form of control, but the person who initially coded it did feel like it was more intuitive. The actual concept worked perfectly, it just depended on the person driving to determine whether it’s actually useful or not.

1 Like

I don’t mean to interrupt but as the head programmer of my team I really found all this really interesting! I’ve thought about this kind of coding before, but the driver in me doesn’t see it being super helpful, at least to me. You kind of learn to see the field from the robots perspective, and if you’ve been driving long enough, it’s almost like instinct to drive based on the orientation of your robot. That’s just me though! you’re right, it’s more of a preference thing it seems.

1 Like

Yeah I understand that.
I personally preferred arcade drive, but forced myself to learn tank drive last season, since my programmer knew how to do tank drive, and because we were constantly rebuilding, we never had the opportunity to test arcade to see if it worked well (or for the programmer to learn to code arcade since he’d never done it before)

I don’t know if I’m going to go through with this idea, it seems better at first glance (at least for me personally) but I also know how to drive keeping the orientation of the robot from last season as well as messing around with RC cars.

It seems like an interesting idea to experiment with if I get the chance though (also looks good for notebook lol)

the judges would certainly like to see that in your book! And arcade drive isn’t difficult to learn to code, I’m sure your programmer can figure it out easily

This is generally referred to as “Field Oriented” control.

And many others from the Google Machine.

5 Likes

I made a slide show explaining something like this back when I was in eight grade, with some demonstration code included How to code a Mecanum or X-base - Google Slides

1 Like

This is what you want to do. But if you are not using swerve drive, you need a much complex math to calculate each motor’s output. My team will try to figure this out, because our driver suck(me).

1 Like

Also, Okapi recently added field-oriented control to their API as seen here:

So you can use okapi to code the field oriented control by doing something like this:

std::shared_ptr<ChassisController> chassis = ChassisControllerBuilder()
    .withMotors(INSERT_MOTORS)
    .build(); 

std::shared_ptr<XDriveModel> model = std::static_pointer_cast<XDriveModel> (chassis->getModel());

while(true) {
    model->fieldOrientedXArcade(LEFT_Y_AXIS, LEFT_X_AXIS, RIGHT_X_AXIS, IMU_ANGLE)
    pros::delay(10);
}
4 Likes

shameless self plug?

On a side note, don’t think you’ll need the static pointer cast. The chassis should already be built with the correct model if you give the motors correctly.

I would certainly recommend field oriented control to anyone who haven’t tried it before (if i recall the math were not too complex, just some rotation matrix to shift the robot’s frame of reference). Essentially, it separates a holonomic drive’s translation from its rotation. This means that you can actually use some control algorithms to automatically control the heading of the drive. For example, it is possible make it so that the robot automatically aims toward the goal while you drive.

Personally, I don’t think using field oriented control will automatically make you better at driving. The only thing that will make you better is practice. However, if you are willing to invest time into developing some driver assisting control, it might help to an extent

8 Likes

ofc :joy:

I’ve tried that before and it didn’t work…

1 Like