The DifferentialDrive class used internally automatically inverts one side. You should set all motors to the same inversion. Try all False, and if that goes backwards, set all to True.
Itâs not going backwards though, itâs turning. Also, we just tried setting everything to True, and our motors just make a really weird noise. Iâm not sure exactly what it is, possibly they are fighting each other or something, but the robot just doesnât move. It doesnât sound like fighting, and you can still move the wheels manually. All I know is that I donât think both should be set to True on the same side, because that doesnât seem to work. When we run with all false, the robot turns with each side turning a different direction.
What kind of gearbox do you have, do you your motors on the same side of the drivetrain need to rotate in opposite directions?
We struggled with the the tool a little to get the bot moving an rotating in the right direction too, but I think our struggles were different. We ended up just modifying the generated project to invert the value coming from the network table. double autospeed = -autoSpeedEntry.getDouble(0);
Weâre using the gearboxes from the KOP. One side of the drivetrain needs to be rotated in the opposite direction to go forward.
Whenever we try to set a side to inverted: [True, True], that side doesnât move. Only the sides that are not inverted end up moving, so the robot turns. If we set both sides to [True, True], nothing happens, but the SparkMax motor controllers still show that they are moving (green/red blink lights).
When we set both sides to [False, False], then both sides of the robot just end up moving in opposite directions
Youâre using the NEO project. As mentioned in the comments in the config file, slave inversion for the NEO project is opposite master. So, [True, True] means the master is inverted, and the slave is also inverted with respect to the master. In a KOP gearbox, thatâll result in the behavior youâve seen (and is not healthy for the motors/gearbox, to boot).
What you want is for one side to be [True, False].
1 Like
Thank you, we will try this tomorrow! One thing Iâm noticing is that if both motor controllers are [False, False], then in the actual code, both the left and right motor controllers will be set to motor.setInverted(false). But, if I set only the left side to [True, False] and leave the right side as [False, False], in the code, it changes both the left and right motor controllers to motor.setInverted(true).
Is this supposed to happen?
This was a bug previously, but has been fixed in recent versions. Be sure to update your version with pip install --upgrade.
We are upgraded to frc-characterization-2020.243 which appears to be the latest, but we are still experiencing this bug. Is there a later version?
Ah, apparently we had only fixed it in the brushed spark max project. Itâs fixed now.
2 Likes
Just to confirm, what are your polarities set to when itâs turning? Having no movement, as yâall recognized, most likely means that they are trying to fight each other.
That said, if you can also spin the motors freely while characterization is running, it means that brake mode isnât being activatedâmeaning that either your characterization routine is erroring somewhere, or that you arenât addressing the correct motors.
Could you post the generated project, perhaps? If you are sure the motors arenât fighting each other, and that the ports for the motors youâre addressing our correct, there may be some more niche error thatâs popping up.
Maybe I missed the answer in this thread, but what is the difference between the two options? Brushed/brushless?
Correct.
So just to be sure, âNeoâ means brushed, and âSparkMaxâ means Brushless?
No, thatâs backwards, but I assume you meant it the other way around, as well 
Sorry, Iâm a bit confused 
. You mean I wrote it the other way around? So âNeoâ means brushed, and âSparkMaxâ means brushless?
âNeoâ means brushless, because Neo motors are brushless. You wrote ââNeoâ means brushedâ in your original post, but I assume that was a typo.
1 Like
OK, now I understand (that was not a typo ). That actually makes a lot more sense.
Sorry for the hassle and thanks!
If we wanted to use the characterization suite with a SparkMax and NEO using an external encoder, do you recommend we simply just edit the code directly to use getAlternateEncoder() instead of getEncoder()? Or is there something else we will need to change/a different process we should go through
Not worth it; just do the characterization with the internal encoder and use the external encoder in your actual code. The empirical constants donât depend on the encoder.
If you really want to do characterization with an external encoder on a NEO, modifying the generated project is your best bet.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.