Is there a “good” way of balancing our drive motors with labVIEW? if we use encoders, is there a way to scale the motor outputs based on those values without taking apart the tank/arcade/holonomic drive VIs? Right now i’m investigating pulling open the devref and adding a transform vi ref to each motor – but this seems like a very complicated solution for what strikes me as being a fairly common problem. Is there a nicer way?
It is possible and kinda complicated the best way to fix it would be a mechanical fix but if that isnt possible heres what you can do. Get the 4 encoder rate values and case if the rates are the same (i’d round if i were you) then do nothing to the value of the motors but if they arent the same then adjust the speed of the motors until they are.
Scale the motor inputs just before they get into the tank/arcade/holonomic drive vi’s. Using the LabVIEW PID functions.
It isn’t a common problem. If you are getting significantly different response on the two sides of your drive base, something is wrong with the hardware. It would be better to fix the cause rather than patch it with software.
But if you do want to mask the mechanical or electrical issue, you can use the gyro to modify the X axis input to the Arcade Drive function. Use the joystick as a rudder to determine the desired heading by applying a delta to the current heading as read from the gyro. Use that desired heading as the setpoint of a PID block that reads the current gyro angle and provides the X axis control.
When you’re not calling for a turn, the PID will apply whatever turn command is necessary to keep the robot facing the same direction.
It turned out that last year’s robot had a mechanical “boo boo” because of one jumper. One victor had jumpers for both the “brake” and “coast” options. We did not notice it until 2 weeks ago. So for the whole competition, we had one motor stopping and the other one stopping a few seconds after the other one… That explained why the autonomous mode last year for us really sucked. Like I say everytime: the problem is the hardware, not the software.
This is not physically possible. The Brake/Coast selection is made by installing a jumper between either the first and second or the second and third pins of a three-pin header.
If you did manage to connect both the Brake and Jumper pins to the control pin at the same time, you would short out the Victor’s 5 volt power.
…we had one motor stopping and the other one stopping a few seconds after the other one…
It sounds like one Victor was set to Brake and another was set to Coast.
i don’t know how much of a difference this makes, but we’re going 4WD (for omni/mecanum), so i assume any difference in motor output becomes a lot more noticeable more quickly than it would with plain tank. i would love for there to be a non-software solution for this, but it has plagued our last few bots and we don’t know where else to look.
ah, but how is this done? the PID suggestion seems interesting, but how do we actually get inside the devref to do all this? just unbundle and go through the Motors array? at that point scaling could be trivial (i.e. just multiply) but is there a nicer way to actually get that far?
I guess that was it. I never actually looked at the victors; the electronics guy told me that.
Don’t modify library code.
There’s certainly no reason to breakout the DevRef.
You are feeding the settings into the drIve vi’s now.
Modify them before you feed them in.
The default teleop.vi takes a joystick axes value and wires it into the Arcade Drive vi.
Put your new code between the Joystick axes and the Drive vi of your choice.
but, again, how do we do this for holonomic drive? there’s a lot of trig performed on the joystick inputs before it gets out to the motor set VI in the holonomic drive VI – breaking out the devref would give us direct access to the transform VI ref for each motor, which would let us do scaling like this. it seems like the only other option, barring rewriting the holonomic drive VI, would be to do all that math inversed on the axis values we’re giving it – and at that point we may as well just write our own drive VI.
in the mean time, i’ll double check for any mechanical/electrical issues on our old bots (e.g. mis-set coast/break jumpers) with my team, because it seems like this really isn’t a very common issue at all.
Don’t adjust the motor speeds explicitly. Adjust the drive control inputs. If you want to keep the robot going straight, put the PID between the joystick and the rotate input to the Drive vi. Use the gyro angle as the process variable and the desired heading as the control.