mixing channels
Macgman2000
Posts: 59
I am working on a skid steer (tank steering, with left and right motor drives) platform. I want to use 2 potentiometers one for X and Y so that I can mix motor drive1 with motor drive2 with varying proportions.
The following is the joystick position and drive logic:
stick north: motor1 and motor2 have identical proportional speed and direction
stick south: same as north with reverse direction
stick east: motor1 proportional drive
stick west: motor2 proportional drive
think of it as a flight RC remote control. I want to mix on one stick the function of a RC tank.
Are there any nifty ways of doing this that makes it slop resistant (mechanical joystick slop)?
I used case statements but seem to fall out if the stick is not in perfect alignment.
Nick
The following is the joystick position and drive logic:
stick north: motor1 and motor2 have identical proportional speed and direction
stick south: same as north with reverse direction
stick east: motor1 proportional drive
stick west: motor2 proportional drive
think of it as a flight RC remote control. I want to mix on one stick the function of a RC tank.
Are there any nifty ways of doing this that makes it slop resistant (mechanical joystick slop)?
I used case statements but seem to fall out if the stick is not in perfect alignment.
Nick
Comments
1) power supply stability for the analog supply (what you power the potentiometer with)
2) life-cycle of the potentiometer, especially when feathering (if you move the potentiometer in the same place, over time the wiper will literally grind away the resistor material)
3) Mechanical tolerances (how well the joystick handle is attached to the potentiometers, and how rigid the base is attached to the vehicle)
What you might consider, instead of potentiometers, is hall-effect sensors with digital outputs. Hall effect sensors come in various forms - the most useful to you would be one that detects the absolute rotational angle of a magnet and reports it with a quadrature or serial output. This way you take out of the reliability and consistency equation, the analog power supply, the potentiometer life cycle, and a A-to-D conversion that is probably temperature sensitive. The absolute position can be loaded at boot-up as some Hall sensors allow for an SPI absolute reading.
Take a look at the Melexis MLX90316. This is a rotary sensor that is available with an analog radiometric, PWM, or SPI output which you can get from Digikey for about $14US.
As for the mixing, try this pseudo code (assume 8-bit variables, "turn" input is assumed centered at 127, where input >127 indicates right turn, and <127 indicates left turn):
Be aware that the above example assumes a 0-255 single direction drive, and offers no protection of overflow protection (if a turn value of 34 is added to a speed value of 250, the output byte will not read 284, but rather 29 - this could cause a major problem with steering at speed. This code would also not allow my favorite feature of skid-steer - turning on a dime while not moving... More code would be needed to provide for these features. This would also make it difficult to ensure a straight line at high speed (there may be some drift). You may want to add a dead-band adjustment (a "center" that applies no effect on the two speed outputs). In the above example, this would be done by altering the "127" value - codewise this is best done by adding another variable and leaving the center point alone (of course, if you have a calibration feature for the center, this may even need to be altered).
When I was working for an electronics retailer doing loss prevention, our camera system's remote died (bad joystick design), and was not repairable. I ended up reverse engineering the CCTV PTZ controller device (using a Basic Stamp SX no less
If you let go of the joystick it should auto-center. You would then press a "calibrate" button, then you would then need to take the joystick and move it around the "center play" (just where the joystick moves without pushing on the centering spring). The software would watch the maximum and minimum readings from the X/Y axis and write them to a four dead-band values, and would then exit the routine upon another press of the calibrate button. Simply:
Using the same pseudo code I started with an edit would be:
If you use a part like the Melexis one listed above, you get 14-bits of positional data. This is a lot to work with, and during the initial setup you can have the joystick output a serial string that has the bit pattern for the position it is detecting. This can be used to physically rotate the sensor until it is centered. For the speed/direction axis, you can use the MSB to determine the direction, and the next 8 MSBs to determine the speed. Of course the above pseudo code still does not have overflow safeties, so will need to be protected against.
To prevent overflow, you can do a few simple checks, for example: assume SpeedInput = 250, TurnInput = +34
The above also has a side effect of limiting the amount of speed for aggressive turning movements (this can be very important on vehicles with higher centers of gravity, for roll-over stability), which will force the reduction of the overall speed of the vehicle during a turn at higher speeds - most electric forklifts and other industrial carts have this feature, only on a binary basis (i.e. once the turn is too great it can't be driven as fast). If you have a 0 - 255 speed register and a direction bit for the speed (9-bit speed/direction input), a little more code can ensure that a drive output will reverse an output that switches polarity (positive/negative) as it crosses zero. This enables the "turn on a dime" capability that's so attractive for skid steer.
[i]Where TurnInput is 8-bit (255 = Max Right, 127 = Center, 0 = Max left), DirInput is 1-bit (1=FW, 0=REV), SpeedInput is 8-bit (255 = Fastest, 0 = Stopped), LeftDir is 1-bit (1=FW, 0=REV), RightDir is 1-bit (1=FW, 0=REV), SpeedLeft is 8-bit (255 = Fastest, 0 = Stopped), SpeedRight is 8-bit (255 = Fastest, 0 = Stopped)[/i] :TrajectorySub If SpeedInput > SpeedMaxSlop SpeedInput = SpeedInput - SpeedMaxSlop Elseif Speed Input < SpeedMinSlop SpeedInput = SpeedMinSlop - SpeedInput Else Speed Input = 0 Endif MaxTurn = 255 - SpeedInput If TurnInput > TurnMaxSlop TurnInput = TurnInput - TurnMaxSlop If TurnInput > MaxTurn MaxTurn = TurnInput - MaxTurn SpeedInput = SpeedInput - MaxTurn Endif If TurnInput > SpeedInput LeftDir = DirInput XOR 1 Temp = TurnInput - Speedinput Else LeftDir = DirInput XOR 0 Temp = SpeedInput - Turninput Endif SpeedLeft = Temp RightDir = DirInput XOR 0 SpeedRight = SpeedInput + TurnInput ElseIf TurnInput < TurnMinSlop TurnInput = TurnMinSlop - TurnInput If TurnInput > MaxTurn MaxTurn = TurnInput - MaxTurn SpeedInput = SpeedInput - MaxTurn Endif If TurnInput > SpeedInput RightDir = DirInput XOR 1 Temp = TurnInput - Speedinput Else RightDir = DirInput XOR 0 Temp = SpeedInput - TurnInput Endif SpeedRight = Temp LeftDir = DirInput XOR 0 SpeedLeft = SpeedInput + TurnInput Else LeftDir = DirInput RightDir = DirInput SpeedLeft = SpeedInput SpeedRight = SpeedInput Endif Return :CalibEntry SpeedLeft = 0 SpeedRight = 0 Call DriveSub [i]; Hey, why not ensure the thing isn't moving before entering this loop right?[/i] TurnMaxSlop = 0 TurnMinSlop = 255 SpeedMaxSlop = 0 SpeedMinSlop = 255 :CalibSub If TurnInput > TurnMaxSlop then TurnMaxSlop = TurnInput If TurnInput < TurnMinSlop then TurnMinSlop = TurnInput If SpeedInput > SpeedMaxSlop then SpeedMaxSlop = SpeedInput If SpeedInput < SpeedMinSlop then SpeedMinSlop = SpeedInput if Calmode goto CalibSub [i]; "calmode" can be a button for simplicity - like the type you have to stick a paper clip in...[/i] ReturnThe above pseudo code omits the SPI communication that would have to occur with the Melexis part mentioned, and also does not include the output method to convey the speed and direction values to the chassis, but it should be a good start. It will give you four simple control outputs: Left Direction (Forwards/Backwards), Left Speed, Right Direction (Forwards/Backwards), Right Speed. These outputs should be enough to control a PWM output and polarity of an H-Bridge driver for an electric motor drive, or a 4-way hydraulic solenoid and a proportional hydraulic valve (via some form of servo) for a hydraulic drive.
If you are doing an electric drive, you can use a simple sub-routine to run the motor outputs:
[i]where CounterVar is 8-bit[/i] :DriveSub CounterVar = CounterVar + 1 If SpeedLeft > 0 If SpeedLeft >= CounterVar LeftPWMOutput = 1 Else LeftPWMOutput = 0 Endif Else LeftPWMOutput = 0 Endif If SpeedRight > 0 If SpeedRight >= CounterVar RightPWMOutput = 1 Else RightPWMOutput = 0 Endif Else RightPWMOutput = 0 Endif ReturnThis subroutine takes advantage of the overflow, so that if it it gets to 255, it will return to zero (writing the carry bit, which isn't used...). This type of subroutine, may have too high a frequency on the output, or may not be high enough. In the former case, running the other routines more will slow down the PWM fundamental frequency. In the latter case, ensuring the joystick read routine is balanced with the "TrajectorySub" (by the use of delays in the trajectorysub routine) the "DriveSub" routine can be called between the two other routines, for 2x the speed. You can also reduce the resolution of the PWM output from 8-bit to less, by changing the value it adds each time it's called (between 1-8, any more and it will really affect the PWM resolution...).
If you want to figure out the fundamental frequency of the PWM, you can add a line to the PWM routine, that toggles an output pin each time it's called (and divide the measured frequency by 128), like:
You would have to divide that pin's frequency by 128 as each rising or falling "edge" of the resulting square wave represents a subroutine call, and 256 total calls equals one complete PWM cycle (this is a "phase accumulator" type of PWM).
-Tim
Post Edited (GreyBox Tim) : 10/20/2008 7:12:41 AM GMT