View Full Version : Programming Issues with Crab Drive System
So...... we finally got to test our new crab drive system today(actually last night :D )). However, we experienced some electrical/programming issues.
So this is how our programming works.
Our crab drive has two drive modules on left and right. (each module controls direction of each side, since two wheels are chained together)\
http://i236.photobucket.com/albums/ff305/bls0620/CrabDrive.png
Each side has absolute magnetic encoder attached to it. We use those encoders to measure the current value(angle) and get reference from a joystick to calculate the error for PID.
These are the issues we found so far:
1. Unsynchronized drive modules
2. Drive modules not turning fast enough (PID issues)
3. Overshoots (PID issues again...)
Is there some ways to improve our PID for fast and accurate control? Other than PID control, is there a way to synchronize both modules so they will turn at the same rate(in an efficient way)?
BTW, We are using LabVIEW
These could also be mechanical problems...What motors are you using for steering? What's the gear ratio from the steering motor to the module? There isn't really any motor in the kit ideal for crab steering as is. You have to play with gear ratios and things like that. My team burned out a Denso on the regolith last year with a 1:2 reduction, and I shudder to think what would happen on carpet with more friction, any more gearing down for torque and it would have turned too slow.
These could also be mechanical problems...What motors are you using for steering? What's the gear ratio from the steering motor to the module? There isn't really any motor in the kit ideal for crab steering as is. You have to play with gear ratios and things like that. My team burned out a Denso on the regolith last year with a 1:2 reduction, and I shudder to think what would happen on carpet with more friction, any more gearing down for torque and it would have turned too slow.
We are using window motors for our steering. I am not so sure about the gear ratio though. And we will change our wheels to have less friction, since it seems like motors are getting a lot of stress from it (one of them was HOT and it stopped functioning due to high temperature)
engunneer
24-01-2010, 11:14
Another important thing to do is to make sure you calibrate the PID with the correct load and friction conditions. Make sure your robot weight is approximately right, the CG is in about the right place, and there is no binding in any of the steering bits.
How are you calibrating the PID? Are you able to command a "step move" or velocity profile, then graph the "commanded" and "actual" positions?
Can you change your PID on the fly (without a re-download)? If you can do both of those, you have the tools to make a great PID controller.
Lastly, see if you can add some additional parameters into your PID loop. I suggest learning about Velocity Feed-Forward (adding some of the command velocity into the output, without waiting for the P, I, and D parameters to detect it) and Friction bias (always adding a small amount to the motor output in the same sign as the direction you are trying to turn.)
Post any graphs that you can, or any questions here, and i'll be happy to try to explain.
We had something similar last year, with each side slaved together in steering. (although we later separated the front and rear) We used Globe motors at around 3:1 or 2:1 reduction. In our testing, we initially used a simple proportional loop for our first test drives and it worked really well. We were using 5-turn pots, and had few problems with them.
How exactly are you relating joystick position to wheel position?
The window motors have thermal breakers in them, and will automatically shut down when they get too hot. That dosen't mean they are broken, it means you are overusing them.
Looking at the problems you found:
1. Do you mean the two drive modules are not turning to the same place? You need to set the centerpoint for your calculations for each side.
Also, if you mean they aren't turning the same way, all you can do is set the gains the same for both sides. If you have the same motors and the same sensors, they should need the same gains. We only calculated the gains for the left side of our robot, since the right side was a mirror of it.
2. If you aren't using I and D, set the P gain as high as it will go without excessive overshoot. IF you are using I and D, set the P gain so high it will oscillate. You probably don't need I and D unless you have problems with overshoot when the P gain is set reasonably.
3. Lower the P gain or add more I. If it twitches a bit, add D.
engunneer
24-01-2010, 13:19
Also, when adjusting the tuning, it's helpful to really understand what each parameter is for.
P's job is to get the motor moving to the target. It does most of the work. The higher the P, the faster it will go. If P is too high, it will overshoot (go past where it is supposed to go.
D's job is to slow it down as it gets where it is going. If you have overshoot (or oscillation) a little more D will help dampen it out. In most systems, D is between 0.01 to 0.1 times P, but can often be 0.
I's job is to correct any small error left at the end of the move. These are for the cases where the motor is /almost/ in the right place, so P can't help. I will eventually build up and nudge the motor the last little bit. In most systems, I is between 0.01 to 0.1 times D, but can often be 0.
VFF (feed forward) is a kick to get the motor moving faster at the beginning of the move. Think of it as getting a head start of moving the right direction before the final target is known. Many PID systems on CNC machines use this.
Friction gain is simple power assist. It overcomes the minimum power needed to get the motor moving, so the PID can just focus on the position control. It's usually not needed unless friction is accounting for a significant percentage of the power needed to move the motor.
Also, I would recommend tuning the two sides separately. Ideally they are identical, but if they aren't having the ability to tune them individually could keep you with a running robot in a pinch. The main goal is that they have the same /response/ which is that they react to a control signal in the same amount of time and move the same amount. Sometimes one side will need more P than the other (i.e. if the CG of the robot is not centered between them), or more I (if you have a bad bearing or one motor is not as well greased as the other)
Alan Anderson
24-01-2010, 14:35
Friction gain is simple power assist. It overcomes the minimum power needed to get the motor moving, so the PID can just focus on the position control. It's usually not needed unless friction is accounting for a significant percentage of the power needed to move the motor.
It (or something like it) can also be useful for getting past the built-in deadband on a Victor speed controller.
Al Skierkiewicz
24-01-2010, 14:55
And we will change our wheels to have less friction, since it seems like motors are getting a lot of stress from it (one of them was HOT and it stopped functioning due to high temperature)
If this motor was a drive motor, it is likely you have it running in the wrong direction and it is fighting the other motor.
If this is the window motor, it does have a temperature/thermal cutout. If you are driving the chain direct with this motor, it is likely that the chain is producing too high a side load on the output shaft. This produces significant currents in the motor and high temperature.
These could also be mechanical problems...What motors are you using for steering? What's the gear ratio from the steering motor to the module?
We are using window motors and the gear ratio is Motor:Wheel = 18:32
How exactly are you relating joystick position to wheel position?
We are using one joystick to control the wheel position. We used asin and acos to calculate desired angle and speed. From there, we use desired values to calculate the errors for PID.
How are you calibrating the PID? Are you able to command a "step move" or velocity profile, then graph the "commanded" and "actual" positions?
We are using LabVIEW to calibrate PID in realtime.
Also, I would recommend tuning the two sides separately. Ideally they are identical, but if they aren't having the ability to tune them individually could keep you with a running robot in a pinch. The main goal is that they have the same /response/ which is that they react to a control signal in the same amount of time and move the same amount. Sometimes one side will need more P than the other (i.e. if the CG of the robot is not centered between them), or more I (if you have a bad bearing or one motor is not as well greased as the other)
We do have two seperate(but identical) PIDs for each side. Left side of the motor turns fine with PID(with some exections) but right side of the robot takes longer to adjust itself.
Here are the pictures of our drive system.
http://picasaweb.google.com/sforceneo/Delphi#5430510233805923490
http://picasaweb.google.com/sforceneo/Delphi#5430510244648536130
http://picasaweb.google.com/sforceneo/Delphi#5430510252091849938
http://picasaweb.google.com/sforceneo/Delphi#5430510264649023858
Al Skierkiewicz
25-01-2010, 08:08
The pictures make a lot more sense of this. Are you having your greatest problems with the robot moving or just standing still? It appears that the sensor for the steering position is mounted with bearings taking the load which should be ok. The sensors are not known for being able to handle any kinds of side load. The tough part about this drive system is until the bearings break in, there is a lot of force to turn the modules particularly when the robot is moving. It does not appear you have any bearing plate low on the module to keep the modules from producing sides loads while turning, driving or being hit from the side. Any force applied to the module also translates to higher friction for the steering motors. If the drive chains are tight friction is also added by the side force applied to the top of the module. Unfortunately, window motors cannot be back driven so you will not be able to feel any additional friction on one side or the other. If you had some method to measure current in the two, I think you will find a much higher current in the side that you are tripping.
engunneer
25-01-2010, 09:31
If you are using the Jaguars over the CAN interface, you may be able to read the current being drawn by the motors with your software. Alternately, you can measure the current in the steering motor by putting an Amp meter in series with the motor.
Compare the current on both sides (Ideally with two meters) with and without the steering chain. This will help determine if the motors are not responding similarly, or if you have a mechanical assembly issue on the tight side.
If you are using the CAN interface, you could also consider using the encoder function, and possibly having the Jaguar do the PID control (I am not certain it has this function, but I thought it does). This would require switching to a quadrature encoder, IIRC.
How many quadrature encoders does the cRio support? I thought I read you only get 2 with 4x resolution. I am considering using rotary pots for this function as we will need the encoders for the wheels.
I don't think there is a limit on # of encoders, other than # of DIO ports free.
The jaguars can do PID with analog sensors such as potentiometers, not just quadrature encoders. There is an analog sensor port.
engunneer
25-01-2010, 10:25
the US digital sensors come in an analog output flavor that work much like a 360 degree pot, but have almost 0 deadzone.
I surprised the jaguar can do PID with analog and not quadrature...
the US digital sensors come in an analog output flavor that work much like a 360 degree pot, but have almost 0 deadzone.
I surprised the jaguar can do PID with analog and not quadrature...
All I see is the Channel A and Channel B outputs....I suppose you can use the digital counter but where would I get an analog signal?
Joe Ross
25-01-2010, 12:10
the US digital sensors come in an analog output flavor that work much like a 360 degree pot, but have almost 0 deadzone.
I surprised the jaguar can do PID with analog and not quadrature...
He said not just quadrature.
The jaguar does not support continuous pots, so the us digital sensors won't work.
The jaguar does not support continuous pots, so the us digital sensors won't work.
I was thinking of using the ABOB for that....but I only see a digital out for the US Digital encoders.
engunneer
25-01-2010, 14:29
Sorry, I read "just not" instead of "not just"
The kit came with a few optical encoders (which are quadrature, IIRC)
It probably could technically work with the US digital sensor, but going from 1% to 99% of travel would go the long way around, and if you ever hit the transition point, expect some bad results. It certainly would cause more problems than it would solve.
Your root problem still probably needs to be solved. the Crio does PID just fine, and you already have it working, so now you just need to get the motors to respond equally.
Unless WPILib has changed WRT this since last year, you can only have 4 quadrature encoders running simultaneously. Otherwise, only the last 4 you instantiated will tick properly, the ones before the last 4 will tick WITH the last one you instantiated. (We wanted to use 7 encoders last year, only to discover we couldn't).
Unless WPILib has changed WRT this since last year, you can only have 4 quadrature encoders running simultaneously. Otherwise, only the last 4 you instantiated will tick properly, the ones before the last 4 will tick WITH the last one you instantiated. (We wanted to use 7 encoders last year, only to discover we couldn't).
Thank you....that's what I thought....you could use the other channels for counters I presume.
Alan Ing
26-01-2010, 04:27
Hi All, thanks for responding to the questions that our student programmer has posted.
This is our first (and maybe last) attempt at a crab drive system. I am not a programmer, but can answer some of the questions related to the mechanical end of our machine. We decided to go with the denso window because of the limited motor selection this year. The denso motor is controlling two wheel modules each with an additional stage of reduction of 1.78:1 (18 tooth sprocket on the denso motor, 32 teeth on each wheel module. Yes, they are side loaded and flex quite a bit underload so that may be one of the issues. We attempted a quick fix by boring out the center of our sprocket to expose the unsupported metal shaft, machined a boss to go over the end of the shaft, and welded it to an aluminum plate that goes on top of the motor to support the free end of the non rotating motor shaft. The motor no longer appears to flex and twist, although we are still putting side pressure on the plastic spline.
You can't really see it, but the wheel modules themselves are held vertically by two sets of ball bearings. One in the upper plate, and one in a lower plate in combination with a roller thrust bearing. So I believe we are okay as far as any binding in the wheel module itself. It seems to rotate quite easily. These bearings are a bit close toghether, Maybe about 1-1/4". We could space them up to 2" if we made a riser for the upper plate to add stiffness, but it seems okay at the moment.
As mentioned we are using an absolute magnetic encoder. We mounted it on our idler gear at 1:1 with the wheel module. It also is supported by two sets of ball bearings. The encoder itself has no side loading.
We originally had one left and one right denso motor, but just changed it to two left motors. I figured if we used one left and one right, then we would have at least one spare for each side, but that could have been a mistake. fortunately, it only takes 5 minutes to change to the other motor.
The main reason we are considering different wheel material, is because our machine was having trouble turning in regular tank mode with the wheels set in the wide configuration. Right now, we are using 4" wheels with roughtop (aka andymark plaction) out of the toughbox (machined new plates) with double motors per transmission. Those roughtop treads seem to have too much traction even in a wide chassis configuration. We just switched to the wedge top and will see how they do.
Our biggest worry right now, is whether the denso motors are up to the task in general. Even with the 1.77:1 extra reduction, we have very limited experience with them. Gearing them down even more will be a real pain. Any thoughts? I suppose we could use FPs, but we'd rather use them to control the ball.
Worse comes to worse for the PID balance issue, we can still chain all wheel modules toghether, but of course we would lose some features that we wanted to do. Also, has anyone chained two denso motors toghether? We've coupled 3 motors of different types before, but never two window motors with seperate worm gearboxes. Just wondering if we can actually do this without a problem or will the gearboxes give us trouble. I guess I am worried that because they do not back drive well, two gearboxes could get out of sequence and bind with each other.
Our students have not yet atempted to tune the machine since the denso motor mount modifications and tread change. Hopefully that will do the trick.
Any help is greatly appreciated. I hope all your teams are doing well and are having an excellent build season!
Alan Ing
Engineering Mentor
Team 368 (Honolulu, Hawaii)
Al Skierkiewicz
26-01-2010, 07:56
Alan,
That takes care of many of my suspicions. You will find that using the high friction material will make any drive system very hard to turn in tank mode. A normal drive system will put the drive motors in near stall conditions during this move. With a high torque drive system, the robot will actually hop as the torque overcomes the friction with the carpet. Omni wheels would be indicated in a normal drive but not in crab. We have employed a "foot" in the past that has either non-driven omni wheels or just a nylon pad and descends between two of the wheels for changing direction. Going to a wheel that has less friction is the right way to go but you still need enough to climb the bump. The window motors do have some backlash in the gear box that may hamper your PID routines. I have not looked closely at this year's motors yet, but in the past there was a screw adjustment at the end of the worm gear to reduce the amount of backlash. There is a tradeoff though. The screw also makes back drive harder and gearbox friction higher. I don't think you should have any trouble with these motors for steering. Even with the ball bearings, there still can be incredible friction developed with the bearings that close together. We have used a bottom plate on our modules in the past, that overcame the short moment arm between the upper bearings. We have been using a simple bronze combination bearing for the top. It supplies both a normal bearing surface and the thrust needed to support the weight of the robot. The bottom plate then has a custom made delrin ring to provide the bearing surface at the bottom. This plate takes all side forces during drive and hits. If you can remove the window motors easily but leave all the chains in place (with tension), I would then see how smoothly the two sides turn without the motors. You may find it is a simple matter of changing the wheels and wearing in the bearings, chains, and sprockets.
By now you have realized that it is a complicated drive system that adds some weight. However, if your strategy will use crab effectively it is worth the effort. Ask questions anytime.
Joe Ross
26-01-2010, 09:40
Unless WPILib has changed WRT this since last year, you can only have 4 quadrature encoders running simultaneously. Otherwise, only the last 4 you instantiated will tick properly, the ones before the last 4 will tick WITH the last one you instantiated. (We wanted to use 7 encoders last year, only to discover we couldn't).
That's not entirely true. You can only have 4 encoders in 4x mode. You can have an additional 8 in 2x or 1x mode. Encoders in 2x or 1x mode are implemented as counters by the FPGA, but still use the encoder class.
We used 4 encoders in 1x mode and 1 encoder in 4x mode last year.
Alan Ing
27-01-2010, 04:30
Hi Al,
Thanks for the reply. Our students tried the chassis again with the modified window motor mounts. Seems a bit better, but unfortunately for us, the window motors overheated after about 5 minutes of somewhat light use and shut down again. I have a bad feeling they are just not the right motors to use this year. We are fortunate enough to have a clamp on meter that can read DC current and measured about 2-3 amps while turning in place. Under drive crab conditions, this shot up to 7 amps and peaked out around 10 intermitantly. After reading the motor specs, I finally realized that this motor is only rated for 13.25 Watts. Not good. We will check again, but it really doesn't appear that we are binding anywhere. Gearing down the window motors more than 1.78:1 will be difficult. Our options at this point are:
1. Add an additional window motor per side for a total of 26.5W. (Still worried if they will work well together since they have worm gears plus they will add more weight.)
2. Go with the FP motors (100W +) coupled to some 64:1 banebot P60 transmissions we have laying around from last year using the same sprocket combination for a total of 64x1.78:1 (114:1), uncorrected freespeed of around 137 RPM. I imagine that should be more than enough to handle the steering mechanism. The down side is that we wanted to use the FP to control a soccer ball. This would only leave us those weak Mabuchi motors which are approximately 18W and 9W. Worst comes to worst, we can combine those two for about 27W.
I would certainly appreciate your opinion on this. The FP solution is the quickest for us. Probably could do either of these with 2 days of after school work. Can't spend too much more time on this. My day job is killing me:eek:
Oh, by the way, what sort of deadband in degrees is acceptable for crab drives. The students have it set pretty high to me, like 10 degrees. I told them that could leave us with wheels pointing as much as 20 degrees apart.
Alan Ing
Engineering Mentor
Team 368
Alan,
We have been doing crab for many years. We have used 1 globe motor to drive each side (2 wheels). The window motors should be able to handle the same task as long as they are geared properly.
The window motors do have some backlash in the gear box that may hamper your PID routines. I have not looked closely at this year's motors yet, but in the past there was a screw adjustment at the end of the worm gear to reduce the amount of backlash. There is a tradeoff though. The screw also makes back drive harder and gearbox friction higher. Al was confusing the Van door motor with the window motor. Window motors do not an adjustment screw.
Al Skierkiewicz
27-01-2010, 08:27
Alan,
I submit to Raul for all things mechanical. In looking at the specs for the window motors, it would seem you are not near the stall current of 18 amps but you are still tripping the thermal breaker inside the motor. That leaves a bigger question. Perhaps your current meter is inaccurate on peaks. Under what conditions did the 7-10 amp peaks occur? This might give you an idea of what is causing the intermittent load. I am not a programmer but I do not believe we have had deadbands programmed into crab steering. Our auto modes in the past have been very accurate. 20 degrees seems like a lot of tolerance. I am guessing that this was an attempt to fix a PID issue and what it causes is high current corrections to get back to center when the error exceeds the deadband. If that is where you current peaks are occurring then maybe your answer lies there.
dyanoshak
27-01-2010, 10:33
the US digital sensors come in an analog output flavor that work much like a 360 degree pot, but have almost 0 deadzone.
I surprised the jaguar can do PID with analog and not quadrature...
The Jaguar has a digital quadrature encoder input as well as an analog input.
There are a couple modes that use these inputs, combined with PID, to control the output to the motor.
Speed Mode: Uses the encoder and PID to regulate the speed of the motor.
Position Mode; Uses either the encoder or the analog input (usually a pot) and PID to control the position. Pretty much servo control.
He said not just quadrature.
The jaguar does not support continuous pots, so the us digital sensors won't work.
The analog port has three terminals +, S, -. These are designed for use with a 10K potentiometer (continuous or not). See the Jaguar Getting Started (http://www.luminarymicro.com/index.php?option=com_remository&func=download&id=1358&chk=c79809dab41932574c50cb6754b0edf4&Itemid=591) Guide at www.luminarymicro.com/jaguar (http://www.luminarymicro.com/jaguar) for a diagram of recommended connections (pg. 22).
This doesn't mean that you cannot connect some other type of analog signal to the 'S' pin... :D check this post (http://www.chiefdelphi.com/forums/showpost.php?p=865263&postcount=56) out, specifically #4 in the list of features. I powered a US Digital Analog Encoder off of an external source and then scaled the output signal to the 0-3V range for the Jaguar.
Before doing this I would definitely read the rules about custom circuits.
-David
Alan Ing
27-01-2010, 14:08
Raul/Al,
It appears that our current spikes occur when the two modules become out of sync. Our students have yet to get them running together. Sometimes one leads the other or it oscillates.
This all occurs during very mild driving. Which does not give me much confidence that they will last during a match. We can't run it long enough to really tune it.
Has anyone used the denso motors to steer this system on carpet? If so what kind of reduction did you use? If I remember correctly aren't globe motors good for about 40W? The windows are only 13W or so. Getting anymore reduction than 1.78:1 will take some time. We will have to double reduce them which will mean finding the space to add and properly support a countershaft and at least two more sprockets. Maybe we can get about 3.56:1 at best. Thats a 40 RPM free speed which seems a bit slow. I imagine that would drop our current to half.
Regarding the deadband, I would think we would need to get it down to less than 5 degrees. Any thoughts?
Thanks!
Alan
Al Skierkiewicz
27-01-2010, 14:53
Alan,
It seems strange that the two sides do not run in sync. This sounds like a programming issue or it is the effect of the deadband you mentioned. (if the two sides get 20 degrees apart that is telling you something) If you are driving when this happens there will be some incredible side forces developed on the modules which increases the needed steering power and raises the current in your CIMs and window motors. I am just guessing here that the programming is tied together somehow for both sides and that is where some of your problems lie. The programming is fighting itself. If that is happening clear the code that does that and pull the breaker on one side. Tune up the other side until it acts the way you want without driving. Repeat for the disabled side. Our crab system would oscillate when the wheels were off the ground. The programmers were fine with this as most of it settled out when sitting on the floor. I know that we had to calibrate both sides when we used two motors so that they would center properly. We used a movable plate that the pots mounted on so we could set both pots at a specific value when all the wheels were facing forward. We also had chain adjustments to perform wheel alignment on the modules that were tied together.
Alan Ing
27-01-2010, 15:17
Our programmers have told me that both sides have independant PID control so they are already seperated. When the wheels are off the ground, the modules seem mostly in sync. When they are on the ground, thats when they sometimes get out of sync. Also, there is a strange situation when reversing. The two sides turn around 180 but go in opposite directions. Looks cool, but not a good thing. This does not happen while the wheels are off the ground.
I know that if they request the machine to turn more than 90 degrees, they make the wheels reverse instead assuming that it is quicker than trying to fully rotate the wheels with the wheels driving forward.
I was just asked another question by one of our mentors. Should the PWMs be in brake mode for steering or in coast. Our programmers think it should be set in brake mode so that's what its currently set for. Off the top of my head though, I would think that brake mode might interfere with the PID algorithm, but thats just my guess.
I suppose this should have been an off season project, but we knew it might be tough! It does go over the bump quite nicely though.
Alan
Al Skierkiewicz
27-01-2010, 15:29
I do not recommend brake mode for steering or driving. The brake mode will add unexpected damping to the system when no throttle command is being sent to the controllers. This damping is variable dependent on the speed of the motor when the zero throttle is sent. Essentially it puts a short on the motor. Your motor temperature rise may be partially caused by this mode. Current in the motor creates heat regardless of where it comes from, the battery or motion.
It would seem that the condition you describe with the modules turning requires some really high level programming. It also will make the drivers confused. Once you get the crab functioning it still requires a lot of driver practice. Take baby steps, get the modules to function as a normal tank drive then start moving up to crab.
Alan Ing
28-01-2010, 15:03
Al,
You were right, taking the pwms off of brake mode improved things quite a bit. The machine is much smoother now.
We also figured out why the modules rotated in two directions when reversing. The students attempted to use a single stick to control both direction and throttle. Which appears to work fine until you try to back up by pulling the stick in the direct opposite direction. Thinking they should probably split direction and throttle to two seperate sticks. Is that what everyone else does?
We remeasured everything with a fluke 337 DC clamp on true RMS meter with min and max peak memory. Window motors are drawing between 4 and 7 amps max now. As Raul suggested, we've decided to gear down the window motors and are going from 1.78 to 3.17 which should drop our current draw to a peak of about 4 amps or so. That means they will only spin at 25 RPM hopefully that will be fast enough. Of course, that means more weight.
Thanks for all the suggestions!
Alan
Al Skierkiewicz
28-01-2010, 15:15
It sounds like you are beginning to see the light at the end of the tunnel. Remember the key from now on is practice and feedback from drivers to programmers. Start with driving forward and from side to side. This will give your students a lot of trouble at first but they can do it. Have them practice with obstacles on the field. You can then move to carts being pushed by other students that act like other robots.
virtuald
28-01-2010, 16:38
Al,
We also figured out why the modules rotated in two directions when reversing. The students attempted to use a single stick to control both direction and throttle. Which appears to work fine until you try to back up by pulling the stick in the direct opposite direction. Thinking they should probably split direction and throttle to two seperate sticks. Is that what everyone else does?
Alan
We used a joystick that has a twist in it, so you would use the X and Y axis of the joystick to indicate speed in that direction relative to the robot, and then when you twist the joystick it would rotate the robot. It was reasonably intuitive.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.