Holonomic Drive Issues With Strafing

[minisolarclown]

Originally Posted by Ether

Does this happen when you trying strafing to the right, or to the left?

It does the exact same thing when trying to strafe either direction.

[GeeTwo]

Originally Posted by Ether

Does this happen when you trying strafing to the right, or to the left?

Originally Posted by minisolarclown

It does the exact same thing when trying to strafe either direction.

Please double check that - do the spin towards each other when strafing left and away from each other when strafing right, vice versa, or always away from each other?

If either of the first two cases, it sounds like the front and rear wheels on one side are swapped, as for rotation and driving forward/reverse, the two wheels on each side do the same thing.

Edit: The simplest scenario I can think of for the last case is if you are squaring the strafe joystick instead of cubing it. (or some other even power) on top of having one side wheels swapped.

[minisolarclown]

When trying to move left and right, the wheel always move towards each other. The exponent is three, so it's not a parabola when you graph it. The exponent is to give more control over the lower speeds. At my next robotics practice, I'll try switching motors around.

[GeeTwo]

Originally Posted by minisolarclown

..when I try strafing, both sets of wheels spin away from each other..

Originally Posted by minisolarclown

When trying to move left and right, the wheel always move towards each other.

Both of these conditions will result in no net movement, but they are not the same. Put the robot on blocks and attempt a strafe to the right. The front left wheel and rear right wheels should drive forward, and the other two in reverse. If I'm understanding you at all, two of these will be the opposite of what they should be. Swap these two motors. Whether you do this through declarations in software, swapping of PWM cables, or swapping of power cables from the motor controllers to the motors will not make any functional difference, but you should double check that the wiring and software match each other; hopefully you will find the problem on inspection and fix the "right" thing. If you swap the "wrong" things, it will work for now, but you will be even further confused if you ever encounter another issue, or if someone notices that the documentation and wiring don't match and quietly "fix" the problem by making reality match the documentation.

Originally Posted by minisolarclown

The exponent is three, so it's not a parabola when you graph it. The exponent is to give more control over the lower speeds.

Yes, I have seen the "raising to power" solution to enhance sensitivity at the low end. The biggest downside of this seems to be expansion of the deadband. The Victor SSP has a 4% deadband, and the Victor 888 a 5.4% deadband. If the joystick inputs are cubed, this gives the SSP an effective 34% deadband, and the 888 an effective 38% deadband. If, instead, you square the results but preserve sign (e.g. with joy * abs(joy)), the deadbands are only expanded to 20% and 23%, which are still rather large. I recall once writing a "joystick_adj" function which allowed me to tune the amount of gain. On that occasion, I wound up using something like:

double joystick_adj(double raw)
{
    return raw * pow(abs(raw),0.3);
}

Which would have given a dead band of 8.4% or 10.6% for these victors, but which still resulted in considerably more effective sensitivity at the low end. The neat thing about the form above is that you can modify that 0.3 up or down until your drivers are most happy with it.

[Ether]

Originally Posted by minisolarclown

The exponent is three, so it's not a parabola when you graph it. The exponent is to give more control over the lower speeds.

https://www.chiefdelphi.com/media/papers/2421

[minisolarclown]

Thank you guys so much for helping me! All I had to do was invert the motors on the right and change some parameters