Drivetrain Control Systems

[z_beeblebrox]

Just curious and looking for ideas:

How does your team control your drivetrain? Tank, arcade or something different? What is your OI? Any feedback or closed-loop control? Extra features like automatic shifting, etc.? How do you control it in autonomous? Why did you do it like you did? How well does it work?

About my team:

Last year, we used the default arcade drive code with the turn and drive rate controls divided between the sticks of a gamepad. We had no autonomous driving or sensor feedback. Our control system worked OK, given the limitations (terrible turning) of the 4-wheel drive we built.
This year, we are using a 6-wheel dropped center wheel drivetrain with shifting transmissions. Based on the experience of our mentors and other successful Arizona teams, we decided to modify an RC pistol grip controller for our OI. (After driving it for a while, I never want to go back to gamepads) At first, we tried the same sort of arcade drive code as last year. It worked well enough to control the robot, but made it difficult to do smooth, fast movements (although lack of driver practice may have contributed to that).
Now, our control system is based on the pseudocode that a 254 mentor posted here (http://www.chiefdelphi.com/forums/showthread.php?t=107807&highlight=arcade+drive+254). This system lets you control turn radius instead of turn rate, making the robot behave more like a car. Everyone who drives the robot is impressed by its smooth, precise turning at high speeds.
Over the next few days, we plan on implementing PID speed control with left and right encoders to make the robot drive straight without operator corrections. We are also working on driving to pick up discs in the autonomous period. This will use a trapezoidal speed profile generator and a speed PID controller for each side.

[tcjinaz]

Hi Zaphod

Still got that extra head ?

We're experimenting right now, and comparing Arcade, Tank and 610 Mr Lim's Kaj (split Arcade) control setups with both Logitech Joysticks and, soon, the Logitech Gamepad.

The jury is still out. The most experienced driver is addicted to tank drive. The rookies are split between tank and Kaj.

Simultaneously, we are messing with filters, rate limits and the like on the inputs. It started with "debounce the operators," but has become interesting since.

[Mr. Lim]

I may be a bit biased... but "Kaj Drive" (split arcade, y-axis on the left stick, x-axis on the right stick) has been a staple on both 188 and 610 for quite some time.

Kaj refers to Kajeevan, a long-standing and well-decorated former driver for 188 who pushed hard for this drive layout as a grade 9 driver, and used it to great effect ever since.

It is best implemented on a gamepad like the Logitech Dual Action / F310s.

[ttldomination]

I may be a bit biased... but "Kaj Drive" (split arcade, y-axis on the left stick, x-axis on the right stick) has been a staple on both 188 and 610 for quite some time.

Kaj refers to Kajeevan, a long-standing and well-decorated former driver for 188 who pushed hard for this drive layout as a grade 9 driver, and used it to great effect ever since.

It is best implemented on a gamepad like the Logitech Dual Action / F310s.

My team refers to that as arcade drive, but I suppose there some ambiguity when it comes to arcade on one vs. two joysticks.

I will say that arcade on one joystick is extremely difficult to do. I'd recommend the "Halo Drive", or what Mr. Lim calls the "Kaj Drive". Just take the drive scheme off the Halo games. Literally the easiest system to implement and the easiest for someone to learn.

- Sunny G.

[Ether]

I'd recommend the "Halo Drive", or what Mr. Lim calls the "Kaj Drive".

I don't think the operator interface Mr Lim described is Halo.

I've never seen or used a Halo game (I'm not into video games), but from discussions here on CD, Halo has fwd/reverse on the Y axis, and strafe right/left (not rotate) on the X axis of the same joystick.

[ttldomination]

I don't think the operator interface Mr Lim described is Halo.

I've never seen or used a Halo game (I'm not into video games), but from discussions here on CD, Halo has fwd/reverse on the Y axis, and strafe right/left (not rotate) on the X axis of the same joystick.




Ah, thanks for that.

When talking to the students, if you say "Halo Drive", about 90% of then pick up on what I intended for it to mean, so I suppose that kind of sunk in.

- Sunny G.

[Brian Ha]

What Mr. Lim calls Kaj drive we actually call it RC Drive because technically that's is where it comes from. That is also the drive system that we use since i fought for it as driver.

[Ether]

we actually call it RC Drive because technically that's is where it comes from

It comes from RC? What's RC?

[Joe Ross]

It comes from RC? What's RC?

http://www.rcplanet.com/Futaba_2DR_2_Channel_AM_S3003_Servos_p/futj25-asterisk--asterisk-.htm Notice how the joysticks are constrained to one axis each.

[apalrd]

When we run 'halo', we do the following:

-If the robot can strafe (some of our VRC robots can), we map the left stick as Translation and the right stick X as rotation. Idealy we would have a translation vector and rotation power, and map everything nicely and correctly, but in the real world we just use a our 'normal' 2-stick non-strafe halo drive and map the left X to the strafe wheel (in a 5-wheel H drive). One Vex robot in particular was really fun to drive, since the gains worked out nicely so the axis of rotation while strafing and rotating fully (e.g. left stuck straight left, right stick straight right) would rotate around the tip of the collector.

-If the robot cannot strafe, we remove the left X (in software, not physically) and use the left Y as 'Throttle' and right X as 'Wheel'. We then use a variant of the Cheesy Poofs algorithm which switches to 'quick-turn' when Throttle is very small. This is what we usually call a 'Halo drive'. Our drivers all liked this algorithm, and I liked it also.

We are actually running something different this year, but I can't talk about it. Ask our pit crew or me about it at a competition.

[Ether]

http://www.rcplanet.com/Futaba_2DR_2_Channel_AM_S3003_Servos_p/futj25-asterisk--asterisk-.htm Notice how the joysticks are constrained to one axis each.

OK, so with an RC Drive you could put either strafe or rotation on the X axis. So RC Drive would be a superset of Kaj, not a synonym.

[Iaquinto.Joe]

This year we decided to create a new control system. We bought a flight controller joystick and mapped the thrust to power, while the right joystick controls rotation and translation values. So if the thrust = 0 and the right joystick is moving, the robot does not move. But if the thrust = 1 and you move the joystick, the robot travels with 100% power to the victors.

[Johnbot]

2607, for the past two years, have used "Kaj drive." It started with Logo Motion, when we tried to use Mecanum wheels for the first time. Forward/Reverse was on the Y axis on the left stick, strafing was on the X axis on the left stick, and turning was on the X axis on the right stick.

Well, we only supported our Mecanum wheels on one side, so the shafts holding them were terribly bent up by our second regional, so we couldn't strafe much at all, leaving us with turning on the right stick, and drive on the left stick.
We decided to keep it for Rebound Rumble, and it worked well.

This year, however, I am looking into other methods for controlling our robot. Our current design has a frame of 37"x19", and it has a 40" tower in the front, so it is pretty tippy. I'm playing around with voltage ramping with our Jaguars to make sure we don't flip from changing direction too quickly. Also, I'm trying to add an accelerometer to the tower to correct itself if it ever begins to tip. We also want to mess around with the idea of automatically changing from break to coast depending on our current state of motion.

[tcjinaz]

Kajeevan apparently fly some planes along the way :)

I think we actually implemented Inverse Kaj, I was winging it with a bad memory. We will try True Kaj on Saturday.

[Gregor]

We use the "Kaj" drive on joysticks/xbox controllers.

[bvisness]

Our driver definitely prefers the Kaj drive. We had a shifting drivetrain last year, and this year we will be trying to shift automatically (although the code is currently untested.) We use two Logitech Attack3 joysticks for driving. (I cannot imagine trying to drive with a gamepad.)

We'll be using a 6-wheel dropped center drivetrain this year. Last year's drivetrain was actually much more interesting - we had 10 4-inch wheels, with the middle 3 on each side dropped.

We'll probably put parking brakes on our robot again this year for good measure.

[apalrd]

and this year we will be trying to shift automatically (although the code is currently untested.)

Shifting automatically is hard.

I speak as a person who has done exactly that on an FRC robot, and someone who has actually read the logic of a real automatic transmission.

There are a lot of variables to consider, and a lot of shift points to calibrate for each variable.

There are many specific conditions to autoshift and many specific conditions to not autoshift. You have to detect all or the majority of them and act accordingly.

[toastnbacon]

We've used several different controls. We had a holonomic drive one year, we were constantly switching between an Xbox controller and a KOP joystick. We've started using tank drive when our programmer became our driver as well. I think it really helps when you know what the code is doing, almost everyone else has trouble with tank drive. It could also just be the fact we have a really young team.

As for the actual drive train,we don't go too crazy. We used casters a few years ago, and the amount of success (or lack there of) we had has made us a little nervous about using an incredibly innovative drive train.

[Saberbot]

For those of you that do kan on a Logitech gamepad, what kind of scaling/filtering do you do on the joystick outputs? We've found that there is a pretty loose tolerance on the zero position (up to +/-.3). We've thought about recalibrating the sticks to 0 in initialization, but we're curious about what has worked for other teams.

[z_beeblebrox]

For those of you that do kan on a Logitech gamepad, what kind of scaling/filtering do you do on the joystick outputs? We've found that there is a pretty loose tolerance on the zero position (up to +/-.3). We've thought about recalibrating the sticks to 0 in initialization, but we're curious about what has worked for other teams.

I'm using an RC car controller, but I've been taking the square root of the x axis and multiplying it by .75. This gives better control at more normal turn rates and keeps the robot from spinning at ludicrous speeds. I've also added a .1 deadband to the joysticks to eliminate unintended slow movements.

[Ether]

This (http://www.chiefdelphi.com/media/papers/2421) might be of interest to readers of this thread.

[Brian Ha]

I think i'm going to have to agree with Andrew on this one. Going down the auto shifting path is one you don't want to try. If it isn't done perfect, your driver will have some issues and eventually your shifters will be kaput. Just my word of advice. Your driver should be able to multi-manage enough that they can shift himself, and if they can't, practice.

[Mr. Lim]

For those of you that do kan on a Logitech gamepad, what kind of scaling/filtering do you do on the joystick outputs? We've found that there is a pretty loose tolerance on the zero position (up to +/-.3). We've thought about recalibrating the sticks to 0 in initialization, but we're curious about what has worked for other teams.

Most years, we just cube the raw values from the joystick axes before doing any math with them (i.e. Kaj Drive).

This makes the zero-centered position a bit "bigger," but also makes fine motions and turns available throughout a bigger range of motion on the sticks. It also still allows full power when you push all the way.

It's not perfect, but it's quick and it works pretty well.

[bvisness]

Shifting automatically is hard.

I speak as a person who has done exactly that on an FRC robot, and someone who has actually read the logic of a real automatic transmission.

There are a lot of variables to consider, and a lot of shift points to calibrate for each variable.

There are many specific conditions to autoshift and many specific conditions to not autoshift. You have to detect all or the majority of them and act accordingly.

Well, interestingly, we're actually using an adapted version of your code (http://www.chiefdelphi.com/forums/showpost.php?p=1205172&postcount=3) to run our autoshifting. :) How well did it work for you? I like that you thought through the different cases so well, but I'm not sure how it will work on our bot.

[apalrd]

It works pretty well.

The calibration takes a little while for all of the terms. We were unable to get the downshifts to be nice enough to use in competition, but the upshifts were awesome.

The algorihm really only works for open-field games with long runs when you gear the robot to accelerate for high speed and don't want to launch in high.

The kickdowns are the hardest to calibrate, since you have to cal an acceleration term. The upshifts have an accel term also, but it's easier to model. The purpose of the kickdown accel term is to downshift if you crash into something or another robot. The coastdown logic gets you back into low gear when you slow down to a stop.