I know this has probably been answered several times elsewhere in the forums, but I can’t for the life of me find where.
I am trying to reverse a motor in software. I have two motors connected to a single axle and want to reverse one of them. I want to use the y axis of joystick no. 2.
I realize that the same thing could be accomplished by reversing the + and - wires on one of the motors but IMHO it is better to do this in the code.
These might seem unrelated, but be sure to calibrate your speed controllers when you do this.
The reason is, the Victors don’t seem to behave exactly the same backwards and forwards out of the box. We’ve noticed that setting a PWM to 178 and 78 don’t produce close to the same speeds in opposite directions… until you calibrate the Victor.
That should be 254, not 255. The valid range of pwm values is 0-254, and the “neutral” value is 127.
True, but that’s not the desired function.
Your example numbers aren’t quite right. 178 is neutral plus 51, and 78 is neutral minus 49.
But you’re right about the problem – the Victor factory calibration is a little off from the IFI pwm outputs, with its actual neutral point at more like 132. That makes your forward value at plus 46, and your reverse value at minus 54…until you calibrate the Victor.
How is it not? The problem seemed to be very clear. There are 2 motors running on a shaft. One needs to run in the opposite direction of the other. They wanted to attack the problem in software.
I guess it’s already been posted, but the following should also work.
(all words in all caps are alliases, as I do not actually know the names of all the values)
I think switching the wires is the best way to go IMO, just because you don’t have to worry so much about calibrating, and any wrong software will do some damage to the motors for sure… but everything up there seems good lol I would just pwm01 = 254 - pwm01 like was said previous, if you really have a problem switching wires
It’s force of habit. We do all our logic on signed chars by subtracting 128 from the unsigned chars. It makes us off by 1 here and there, but we don’t risk over or underflowing on endpoints.
Slightly off-topic, since the new controllers were introduced in 2004, I haven’t had an issue with the full 0-255 range on PWM outputs. 255 seems to be a valid value, has anyone had any issues?
Any 255 set in the user code is converted by the Master to a 254 before it goes anywhere. So using 255 doesn’t cause any harm, but it really becomes a 254 as soon as you hand it off via Putdata().
You’ll never see an OI value of 255 arrive at your user code, no matter how hard you try.
You gave an alternative that yields the same value as 255-x. However, 255-x is not the desired function. The correct way to invert a motor value is to subtract it from 254.
You’ve received many answers to your question regarding how to reverse the motor in software, but in this case, I’d highly suggest that you implement a mechanical solution so that a software bug can’t possibly cause the two motors to run in different directions, or even at different speeds.
I would suggest using a single PWM output from the controller to control both of these motors. You can use a PWM “Y” cable to take a single PWM output from the robot controller to two separate victors. There were some of these cables in the kit of parts. Additional ones can be ordered from many different vendors. (See “CABLE-PWM-Y-2PK” at http://ifirobotics.com/accessories.shtml for an expensive source for these cables.) Since your motors are currently turning in opposite directions when given the same PWM value, you’ll need to reverse the motor leads on one of the motors.
The advantage of using the single “Y” cable to two victors is that it is not possible for a software bug to cause the motors to go in different directions or to run at different requested speeds. In the long run, the extra mechanical effort to eliminate potential future problems caused by the software will be time very well spent.
I was told that this was a historical limit on the master/slave processor serial bus interplay because xFF was used in the serial transmission sequence to signal the start & ending of a transmitted frame. With the use of INT0 to signal the start of frame transmission on the newer controllers I wonder if there is some other technical reason for continuing to do this (not allowing xFF in the transmitted data frames)?
There’s software in the Victors. It’s possible for them to be miscalibrated so that the same PWM signal from the Robot Controller causes different outputs to the motors. If you don’t want to explicitly calibrate two Victors controlling motors on the same gearbox, it would be a good idea to at least force the factory default calibration on them both.
Not on the master/slave communication, but on the radio packet traffic between the OI/RC. A double 255/255 flags the beginning of the radio packet data.