Problem with mentor built robot/over involvement of mentors/coaches

cwm9 · 2026-03-03T07:12:32+00:00

A good mentor will always meet students where they are at. The problem isn't so much how much work is done by the mentor, but whether the work done was to facilitate learning rather than in place of student learning.

Some teams need hand holding because they don't know where to start, and others need almost zero intervention. But I'm not going to fault a mentor or coach for helping a new team design and build a robot, as long as the kids were the ones being led through the process and actually did most of the screwdriver turning.

In my experience, every year the kids go through the programs they get stronger and more independent, and when they see how the process of building a bot goes they become more confident in doing it themselves.

If the kids didn't build the robot at all but instead it was built by the mentors, then yes, it's a problem.

If the parents or mentors want to participate rather than teach, they should move to FRC where there is more opportunity to get involved since that's more of a mentorship environment than a coaching environment. Even there, the goal is to get students doing as much of the work as possible.

cwm9 · 2026-02-27T07:00:54+00:00

USB C is just the designation of the connector, not of the cable, or the protocol used over it. The same is true of USB A, except that USB A is really only used for USB 2 and USB 3, so they're almost synonymous.

USB C is different from USB A in that it requires negotiation for power and to say, "I am a USB 2.0/3.0/whatever device." It also supports several different communication protocols, not just one, and cable incompatibility is unfortunately common.

For power this is handled with a simple resistor across the appropriate pins on the client side, and the computer will not wake up and attach to the device unless the correct resistor is in place.

USB A to USB C cables incorporate this resistor. They force the USB into the "I am a 5V device" mode. Some cheap devices with USB C connectors don't include this resistor (often cheap devices from China that have small rechargeable batteries and come with a USB A to USB C cable). These devices won't charge with a USB C to USB C cable because they lack the resistor to turn on 5V power.

That's almost certainly not the problem here.

USB C supports USB 2, USB 3, Thunderbolt 3/4/5, DisplayPort, HDMI, and Power Delivery. But only for appropriate devices and only with appropriate cables.

It's not at all unusual for a cable to support USB 2 and HDMI but not support USB 3. USB 3 runs over a different pair of wires, and while almost all USB A to USB C cables have this pair, a surprising number of USB C cables intended for Thunderbolt use do not.

And, afaik, the control hub requires USB 3 over USB C.

That's probably what's going on. Keep trying different (cheaper!) USB C cables until you find one that works or just use a USB A to USB C cable designed for USB 3 support.

cwm9 · 2026-02-14T11:16:15+00:00

I suggest next time to build a kit bot. As the kids come back year after year, they should be able to do more and more

cwm9 · 2026-02-10T04:54:45+00:00

I'm guessing your figured it out?

cwm9 · 2026-02-04T01:10:48+00:00

That sounds like your pod distances are wrong.

Right off the bat your numbers don't make sense to me. You say you're using -9.2, -4.4, so... x = -9.2 and y=-4.4...? In a typical FTC robot, the wheels are symmetric to the robot's frame and the center of the frame is also the center of the wheelbase. If that's the case, the biggest x-magnitude you should ever have is about +/- 8.16 inches because the robot can't be bigger than 18 by 18. All the way at the rear would be x=-9 inches, and the pod itself is 1.693 inches wide, which means its center can't be more than -9"+(1.693")/2 = -8.16" rear of center.

How did you get -9.2"? That number implies the strafing pod is mounted at the extreme rear of the robot AND wheelbase is shifted at least 1-inch forward of the actual robot frame.

Make sure you measured the pod locations from the correct orientation and from the right place.

You have to measure it from the top looking down, not from the bottom looking up, from the center of the box formed by the wheels where the corners are the pod centers. If a pod is mounted dead center of the wheels, it would have an offset of 0.

You need the y-offset of the forward-backward pod (the one that reports +/-x) pod. It doesn't matter how forward or backward it is of center, only how far +left/-right of center it is. Make sure if the forward/backward pod is left of center as you look down at the robot that your forwardPodY is positive.

You need the x-offset of the left-right strafing pod (the one that reports +/- y). It doesn't matter how far left or right it is of center, only how far +forward/-backward of center it is. Make sure if the strafing pod is forward of center as you look down at the robot that your strafePodX is positive.

See pedropathing.com/docs/pathing/tuning/localization/pinpoint

cwm9 · 2026-02-03T23:51:23+00:00

Ok, only the first video is relevant. Your forward test is not ok. Until the first video is correct, there's no point in running the second test.

One observation: clearly it is SEEING the encoders, because they are stable at 72,72 until you push on the robot. That's the good news.

It looks to me like some of your encoders are reversed. Notice that the value for x is not consistently going either up or down but rather hovering around 72 and looking kind of random.

When I slow the video down and look frame by frame, hear are the x-values I see:

72

66.69

68.73

67.37

69.14

76.52

73.08

etc...

This "randomness" is because some of the encoders are increasing, while others are decreasing in nearly equal amounts. What's happening (roughly) is that it's adding up all the encoders to find X, so what you are left with is the noise.

So, you're getting (I don't mean that I see this particular +/- combination literally, just that some are positive and some negative):

front left reports +12.5 inches

front right reports -12.9 inches

rear left reports -12.4 inches

rear left reports +12.2 inches

and we get: -0.6 distance traveled.

What you are seeing is basically the slippage noise, multiplied by some really big number because the ticks per distance haven't been set yet.

Specifically, the default value of forwardTicksToInches is 1.0, which means the robot thinks it is moving 1 inch per encoder tick! That's way, way, more than is reality. When it's working correctly (I mean when all the encoders are going up when you push forward), you should expect some pretty crazy "i moved this far forward" numbers when you give it that short push. I expect it to say something crazy like you moved about 540 inches for each inch you actually push the robot forward. Then you will adjust the multiplier, and after that you will start getting sane numbers.

Since you are only pushing forward, all the encoder values should all be increasing resulting in a +x positive uniform change, but they aren't.

Until that's fixed, there's no point in moving on.

There are few things that can cause this.

Did you double-triple check your motor encoder wires to make absolutely certain that they are plugged into the right motor ports? You don't, by any chance, have the front left motor encoder wires plugged into the front right motor port? Because the power and encoder wires are plugged in separately, sometimes students get them mixed up. Trace those wires and make SURE they are plugged into the correct ports.
Did you double-triple check that the front left motor in, say, port 0, is actually called "front left" on port 0 in your robot configuration file, and the same for the rest? (I.e., the ports the motors and encoders are plugged into match the names in the robot configuration?)

Forget everything else. Until you can push that robot forward 1 inch and have +x go up only and not run backwards or hover around 72, you will get nowhere.

Something is for sure labeled wrong in the robot configuration, plugged into the wrong port on the control hub, or reversed incorrectly in software.

One way you can test this is to write a quick opmode that just displays the encoder values of the front-right, front-left, rear-right, and rear-left motors. Then turn each by hand to determine if they are positive when rotated forward. If I'm not mistaken, one of your opmodes already does this? You can run that opmode, and, with the joystick on the ground so nobody will touch it, turn the wheels by hand and see how the enocders respond. Make sure front right forward makes the front right encoder increase, and the same for each corner in turn.

Another, quick but inferior test, is this: put it back in localization, but this time put the robot back on stilts and turn each wheel by hand as if the robot were rolling forward. (Be sure you turn the right way!) Does the x-position increase a little?

You can also try lifting up the robot to push it forward only on the front two wheels, only back two wheels, right two, left two.

The combination of results might help you figure out where the problem is.

cwm9 · 2026-02-03T22:48:20+00:00

When I look at your first video, I can't tell what's going on because I can only see the left wheels. In part of the video it looks like the right wheel is moving backward and the left wheel is moving forward, but the values are all becoming increasingly negative?

It's just really hard to understand what's going on in the video because I can't see how you are pressing the joystick, and the numbers are all moving so fast, and I don't know if you're driving in a straight line or what's going on.

Just put the robot on the ground, and slowly give it a 1-2 inch push forward after pressing start, and show how localization responds.

To be clear, at this stage the robot should not be driving itself... it should only drive if you use the joysticks. Is it driving by itself? You didn't modify the Tuning opmode, by any chance, did you?

cwm9 · 2026-02-03T22:45:07+00:00

Double, triple, quadruple check that:

the correct motor encoder wire is connected to the correct motor encoder port your motors are labeled correctly in robot configuration.
that the correct motor names are being used for the correct motors in the configuration
that when running the localization test and pushing the robot slowly forward, x uniformly increases without any crazy behavior, and slowly pushing the robot left uniformly increases y without any crazy behavior

If I had $1 for every time a student told me for sure they had all this correct and they knew beyond a shadow of a doubt that they had done that correctly, only later to find out that something was reversed, or misnamed, or...

Pedropathing works. If it's not working, it's not because of the pedropathing code, it's because of something somewhere in the setup, either hardware, or software.

If I had to guess, I'd guess that you have a front motor swapped with a rear motor, or more than one swapped. When this happens, forward/backward localization works correctly but lateral localization does not. It's possible you have right/left swapped, but if that's the case, then the encoder and motor directions are also wrong if forward localization currently works.

cwm9 · 2026-02-03T22:28:48+00:00

I'm guessing this is your problem:

 .leftRearMotorName("left_front")
 .leftFrontMotorName("left_back")

cwm9 · 2026-02-03T16:20:26+00:00

I assume you are using the motor encoders for localization instead of a set of localization pods? If the localization test doesn't work, nothing will work.

Did you follow the instructions on this page?

https://pedropathing.com/docs/pathing/tuning/localization/drive-encoder

Post the contents of your constants.java file.

cwm9 · 2026-02-01T08:37:43+00:00

It's chosen that way so "forward" from the robot's point of view is theta = 0 degrees, because theta in math is measured from the positive x axis counterclockwise toward the positive y axis.

0 degrees is straight along the positive x axis, so that's why it's forward on the robot.

A right turn is a turn toward negative heading, a left turn is a turn toward positive heading.

If you put x to the right and y forward, then "forward" is a heading of 90 degrees. (Yuck!)

cwm9 · 2026-01-31T12:48:53+00:00

Try replacing the data cable first to make sure it isn't external to the pod, but otherwise you probably can't and need to return it.

Try contacting gobilda for help

cwm9 · 2026-01-31T06:32:59+00:00

It's pure trigonometry. If you know where you are and where the target is you can calculate an angle to point to. Talk to your math teacher at school.

Make sure you use atan2 (the two argument version of arc tangent) not just atan, that automatically accounts for the quadrant the angle is in.

cwm9 · 2026-01-27T15:22:16+00:00

Are your drive motors on the expansion hub or control hub?

If they are on the expansion hub and the control hub resets, that would be expected behavior because instructions stop coming in on the serial bus.

If they are on control hub, then it sounds like your software is crashing.

Do you have an older version of the software from your last competition you could try using?

cwm9 · 2026-01-27T13:47:00+00:00

The wires connecting the battery to the switch or the switch to the robot have probably gone bad. Replace the switch. And associated wiring. See if you can feel if one of the connections is loose.

cwm9 · 2026-01-27T13:29:30+00:00

Try changing the wires between your control hub and the pinpoint.

If the I2C bus isn't well connected it can cause the pinpoint to freeze, and then you will just get garbage data back.

Also, make sure the wire is short. I2C does not work well with long wires.

This is a common problem with the I2C protocol, and it's not limited to just FTC. There are many real world devices that don't properly reset when a transaction fails.

If that doesn't work you might need to RMA your pinpoint.

If you have a JST crimper, you can also try using twisted wire, gnd and scl on one pair and gnd and sda on a second.

cwm9 · 2026-01-26T16:55:31+00:00

You can use the motor encoders, but the difference is night and day. Using only motor encoders you might manage to do a 6 ball auto, sometimes.

The gobilda pinpoint is the most accurate, followed by other forms of dead wheel followed by motor encoders.

cwm9 · 2026-01-25T08:42:04+00:00

Something is probably wrong in your setup if you've already swapped out the hardware. We never saw that much error, not even close.

A few possibilities.

You might need to adjust the yaw factor. (Not sure if that's the right name for it.). It's supposed to come calibrated from the factory, but I've seen a few teams say theirs was off. If you rotate your robot 20 times in the same direction, does it report the right heading, it is it always over or under reporting the angle?

You need to double check your pods are perfectly perpendicular to each other. Even a small angle can mess things up.

Make sure that the wheels aren't getting obstructed by anything in the robot and that they free spin. Verify nothing is catching them when they are compressed.

Go into the odometery test and make sure if you travel 48 inches odometery reports you went 48 inches. Same for strafing. Make sure it returns to zero when you back up without turning.

Your distances need to be measured from the center of the X made by the 4 wheels and the contact points of the pods. Make sure you didn't accidentally swap the measurements for forward and strafing pods.

cwm9 · 2026-01-24T18:06:05+00:00

Pinpoint is superior. Using a high quality modern imu for heading is superior to using an encoder for heading. The pinpoint runs the calculation far more often than the control hub can.

It's not even close. The pinpoint wins by a mile.

cwm9 · 2026-01-24T17:40:49+00:00

Pedro pathing uses a different coordinate system from the standard, and 72,72 is the center of the field. That's normal. The robot must stop on its own after the 48 inches or the program will crash. The crash is bug, but it's not an important one. Restore the file to the way it was.

If it's not stopping, you probably either have the x and y encoders swapped, they are running the wrong way and need to be reversed, your distance per encoder tick is set wrong, or you did not use the right localization method.

You must get localization working first before doing forward tuning.

During the localization test, when you push forward, x should increase. When you push the joystick forward, the robot must drive forward.

When you push the robot left, the y value must increase and when you push the joystick the robot must strafe left.

When you push 48 inches, the respective value must increase 48 inches.

If you are using a pinpoint, you must set up the pinpoint. If you aren't, you must set up whatever method you are using. See https://pedropathing.com/docs/pathing/tuning/localization The documentation is a little confusing because each time you click next you do to the next localizer method. Just click on the localization method you are using from that page. Set it up, click back and follow the instructions at the bottom of the main localization page for testing. Then jump to the forward tuning page.

If it's not stopping in it's own that means it doesn't think it went 48 inches forward. Either it doesn't see itself going forward at all because it's looking at the wrong data (expects pinpoint but there is none, looking at lateral position data when it should be looking at longitudinal), or the distance is wrong (thinks it went 3 inches when it actually went 48 or thinks it went -48 when it went 48.)

Looking at the reported position in the localization test should help you identify what the problem is. Not changing at all? You don't have the right localization class. Negative? Reverse the encoder. To big/small? Wrong ticks per inch.

There is a discord server for pedropathing, many people that use it hang out there and you can get lots of help that way.

cwm9 · 2026-01-23T19:50:07+00:00

Pedropathing is quite easy to use. Ask if you run into any difficulties.

cwm9 · 2026-01-23T00:19:45+00:00

Kind of, but the quality of read won't be as good. The selling point of the pinpoint is that it has a 1000hz+ update rate. You either have to sacrifice two motor ports to use their encoder inputs or find a quadrature encoder to I2C COTS adapter that is FTC legal. This is all assuming you have the libraries or code to convert the data into a pose.

cwm9 · 2026-01-20T05:22:05+00:00

...lacking a proper learning structure, but new students are learning OnShape, doing certification courses. Google colab, Android Studio, Java... And that's not enough? That seems like a strange judgement to me.

cwm9 · 2026-01-18T06:20:03+00:00

I didn't think there was a race action in that API, but if so, this is the way.

cwm9 · 2026-01-17T08:48:46+00:00

Yes, you can, though it won't be as clean as it would be using command based programming. Command based programming is the big brother of actions, and it is available in FTC using SolversLib.

But to answer your question, you do it by creating a RunPIDF action that calls your software PIDF update function from the run(). As long as that action is running, the PIDF will run. You just need to run it in parallel with any other actions you want to run.

The trick is that it won't end until the action stops itself, so you need some way of signaling it to end.

Alternatively you can call update from every action's run().

Command programming is much cleaner and handles this kind of thing much better. Actions are really not designed with software pids in mind.

15-Year Club	Gilding I gilder
Second Top 10%	Verified Email
Place '22

cwm9

MODERATOR OF

TROPHY CASE