So… we finally got to test our new crab drive system today(actually last night )). 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)
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:
Unsynchronized drive modules
Drive modules not turning fast enough (PID issues)
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)?
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)
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:
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.
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.
Lower the P gain or add more I. If it twitches a bit, add D.
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)
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.
We are using window motors and the gear ratio is Motor:Wheel = 18:32
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.
We are using LabVIEW to calibrate PID in realtime.
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.
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.
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.
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).
)). However, we experienced some electrical/programming issues.