I would be floored if this were the case for anything short of experimentation. Motors on coast would be the only way to do this, and with a 6 motor limit for competition, that’s a huge disadvantage. Closest you can get is just using the motor counts, which is effectively what’s happening in most code anyway. I’m not sure that would qualify as odometry in the VRC sense of the word.
Funny you should say “all I want”. That’s definitely a big ask. I’ve been working with inconsistent autons for four months and haven’t come to a satisfactory solution. You have to take some of the blame, too, because I could barely figure out what your problem was until this morning.
Long story
If what you want is for it to make every ball 1/2 of the time, you could try the backing into a wall thing, but as I learned, that takes precious time, and time is worth points; if I’d had more time, I might have been able to get 77 instead of 61, but I didn’t. I was still happy, given that I’d written the program in one day and it worked almost perfectly on the first official try. I wasn’t content, though, because I had still missed one ball and two hadn’t counted because they shot 0.1 seconds too late. Now I’m back to other things.
@EngineerMike is definitely right:
Especially in the real world.
Odometry is just position tracking from a global reference frame. Why would using the wheel’s motor counts (plugged into the relevant forward kinematics equations) not be considered odometry?
The only difference between that and what ‘qualifies as odom in vrc’ is that wheel slip and gearbox slop is accounted for by suspending independent tracker wheels. The math is the same for both cases.
Ye so @242EProgrammer that could be my problem where it has to go 380 but the gap is 200. How could i easily fix this problem? Also I can try the caution tape robotics moving staright/turning thing, and I’ll debug from there. Ty @242EProgrammer
I use text and didn’t want to type Drivetrain.driveFor(forward, 12, inches); for basically every command, so I made my own functions for most of the drive commands. It’s not that important, but if I didn’t tell you, you’d get confused. This is the definition of fd() for my program:
void fd(double input) {
Drivetrain.driveFor(forward, input, inches);
}
So then instead of Drivetrain.driveFor(forward, 12, inches);, I say, fd(12); and it find the definition of fd() and executes all those commands. Just so you know. The example I gave is basically the same as all my other ones,
which I'll put here in case you're curious.
void fd(double in) {
Drivetrain.driveFor(forward, in, inches);
}
void bk(double in) {
Drivetrain.driveFor(reverse, in, inches);
}
void rt(double deg) { //deg short for degrees
Drivetrain.turnFor(right, deg, degrees);
}
void lt(double deg) {
Drivetrain.turnFor(left, deg, degrees);
}
I do have a couple of special ones, though. If I want to back into something, instead of saying, drive backward 3 inches, I say drive backward for 0.5 seconds. You’ll find there’s no block for this, which is why I made my own:
void fds(double sec) {
Drivetrain.drive(forward);
wait(sec, seconds);
Drivetrain.stop();
}
void bks(double sec) {
Drivetrain.drive(reverse);
wait(sec, seconds);
Drivetrain.stop();
}
This way the robot just blindly drives backward for sec seconds and then stops. It’s worked wonderfully for me. You can do much the same thing in blocks. They show you how at the beginning of the Caution Tape videos. You’ll only need one input, though.
I don’t do text, but I’m going to code it in a couple of min, and I’ll debug from there
Part of a programmer’s job is to communicate to other humans what their code is doing. I always encourage programmers to be more verbose than less. Judges will appreciate legible code whose purpose is clear.
Drivetrain.driveFor(forward, 12, inches);
Is unambiguous to anyone. You want the robot to move forward 12 inches, for whatever reason.
fds(12);
fd(12);
Could do anything. Now, I have to look up what fds and fd do in order to understand your code.
I’m all for encapsulation and abstraction. However, code really needs to be understandable to humans. Also another reason I’m not a fan of block programming as perhaps anything other than a hook to visually demonstrate control-flow concepts like loops and conditionals.