You're welcome!

Roughly speaking torque * speed = power. So since the FTC motors have a fixed maximum power they can produce, you either can choose between low torque+high speed or high torque+low speed and everything in between. And that's done by selecting the appropriate gear box for the motor. If you don't have the exact motor+gearbox you need, you can further gear down your wheels by an external gear set or pulleys with a timing belt or sprockets with a (plastic) chain.

Yes it is portal reference

GoBilda off the shelf 1102 Series Flat Beams, 11 holes. Screws with locknuts to keep it flexible.

I hope it works reliably right now, but when it works we're using two hooks at the end of a lead screws that are powered by an Axon Max servo each. Pretty amazing that you can lift such a heavy robot with a couple of servos! This setup is fairly slow, but we only lift the robot off the ground by an inch. We have to extend the scoring slides to perfectly balance the robot though.

Glad to hear that! I hope you had a good time at the qualifier, that's what counts most.

you should pick us

Yes, I can think of several options here, though I don't have any hands-on experience on those. In essence you need to track 3 parameters of the robot, moving forward/backward, moving left/right and turning, so you also need 3 sensors in the general case, but you could get away with 2 sensors if you don't move the robot in all 3 orientations at the same time. If you have fixed wheels (not mecanum or omni) the robot can only go forward/backward and turn, but it cannot go sideways limiting the need of sensors to 2. We have use that in the past and it worked reasonably well for not too complex autonomous programs, by just using the motor encoders. If your robot uses a mecanum drive base, you could use the IMU in the controller to get the turn angle for the robot and use the two odometry sensors for x and y. However the IMU's angle tracking is not extremely accurate, but it may work just fine.

You should be able to upload new code onto the control hub without restarting it, at least most of the time. Occasionally, something gets stuck and requires a power cycle. If you have to restart your control hub each and every time you upload code, something's wrong. But that's impossible to troubleshoot with RU-vid comments. Contact another team close to where you live and ask them for help on site.

There is no official library or third party code that I could share. All you need is a class that holds the three variables for x, y and h (heading). See code in the description of the video. Getting the odometry values is one thing, following a path is something you need to add on top.

We were using the "regular" Pitsco batteries. REV has flat ones too. Pitsco has become very expensive, not sure who sell "legal" batteries in the $50s nowadays. Google it.

The short answer is no. Basically, I recommend some P or PID controller to follow a given path. There is no one-size-fits-all solution though. It depends on the hardware (mecanum vs. holonomic etc) and there is always a compromise between speed and accuracy.

you are asking about the equation or the code?

I'm having that problem too. I see that it is a class he had but I have little idea of what is inside it. By the way this video is amazing. I just started learn odometry and you made it so simple. Thanks.

I had to create that class. It wasn't too difficult or anything.

man I hate this part of texas 🙄

close my eyes, fantasize💥

three clicks and I’m home

when i get back i’ll lay around

@@pwipjh then I’ll get up and lay back down

will absolutely wreck it

an icon ❤

Fr on god

As the robot keeps turning, the heading or angle may increase to very high values. It's a good practice to keep them bounded within one rotation, let's say between +/-180 degrees or +/- pi in radians. That's what the normDiff function does. Keeping track of the heading is a tricky business as you turn the robot and needs careful thought. For instance if the robot points to -150 degrees and you want to turn it by 90 degrees clockwise, you will end up at -240 degrees which is the same as +120 degrees.

@@DrBatanga can we use atan2((y_goal - y_current),(x_goal - x_current))?

Good question. Yes, you can do odometry in many different ways, but the results will differ too, and it all depends on your drive base. When using motor encoders, you run into issues with wheel slippage and you don't register bumping into walls or other robots. We have looked at different approaches over the years and they all worked more or less: (1) 2 fixed drive wheels + 2 omni wheels or a caster wheel. There is a general closed mathematical solution for this type of robot which is somewhat complicated to implement, but you can divide your path into straight lines and tunes to make the software simple. We used that years ago on our Lego robots and early FTC robots. (2) Mecanum wheels + IMU. Mecanum wheels are fairly good driving, but strafing cannot be tracked reliably with encoder ticks from the motors. We have used mecanum wheels in conjunction with an IMU in the past and got fairly good results. (3) Holonomic drive base (4 omni wheels). Very inaccurate odometry based on drive wheel encoders. You'll need dead-wheel odometry. To answer you question, my gut feel is to go with either (1) or (2) or implement the complete 3 dead-wheel odometry. The latter one gave us the best results by far, but the other two can be programmed and tweaked good enough as well.

Team 6418 says hanks for the very prompt reply

Will do. We are currently wresting with path following and OpenCV and I'm hoping the dust will settle soon.

The short answer is no, but since you asked, I added the main odometry function from our live code to the video description. Hope this is enough to get you started.

Yes, they are set up as dcMotors and need to be named and defined in the REV controller accordingly. There are two ways of using the encoders: (1) They are plugged into a port to which a motor is also connected. In this case the motor cannot use its own encoder and has to run without encoder. You can still read the encoder values from the odometry encoder plugged into the port. To make the program more readable, assign a new variable to the existing motor: motorSlides2 = hardwareMap.dcMotor.get("motorSlides2"); motorSlides2.setDirection(DcMotorSimple.Direction.REVERSE); motorSlides2.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE); motorSlides2.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER); encoderLeft = motorSlides2; // encoderLeft shares a port with motorSlides2 (2) If you don't use all 8 motors on your robot, you can connect the odometry encoder to an open motor port. In this case we use this setup: encoderRight = hardwareMap.dcMotor.get("encoderRight"); encoderRight.setDirection(DcMotor.Direction.FORWARD); encoderRight.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE); encoderRight.setMode(DcMotor.RunMode.RUN_WITHOUT_ENCODER); Hope this helps. Good luck this season!

Yes, you can and we actually did. It's more accurate that measuring by hand. Before that, you also should drive the robot in a straight line and record the distance and encoder ticks. With that, you get the effective wheel diameter which may be off a bit from the nominal 60mm.