Inductor and Smooth Joysticks

[Venkatesh]

I have been thinking about possible techniques to "smooth" out the accelleration of a robot, due to joystick movement. I know that its possible in software, and we were experimenting with that this year. However, would just simply placing an inductor in series with the joystick pin for the Y axis work?

[Matt Leese]

A better bet would be to place a capacitor in parallel with the joystick. This would act to smooth the change in voltage across the joystick (given that it acts as a variable resistor). It's probably a better bet to to simply do it in software as I'm not sure how the Operator Interface reacts to capacitive or inductive loads on the joystick inputs.

Matt

[Mark Hamilton]

I remember messing with an old controller from a previous robot that was laying around in the shop, and I noticed we had used caps to smooth the joysticks. I can't comment on how effective they were as it was from a year before I was driver. it's my opinion however that SW provides a better solution in anyway. There are several excellent and documented methods to do this in BASIC in the whitepapers section here as well as on the Innovation FIRST site. Software will be much easier to tweak and it will be one less thing to blame when your controller dies.

[miketwalker]

I know for years we have just used software. With some drive systems it's hard though cause you need to overcome static friction with the drive system, so if you are pushing up and accelerating, it could slow it down to the point where the motors are grinding yet they're not going quick enough to move the robot yet, and in the long run that could destroy a motor. I know we HAVE used software though and just simply put a loop to determine how much change in the joystick has happened since the previous loop and used a math equation to calculate how much it should go up each loop, and with software you can make constraints to avoid the motor problem I was talking about, whereras with a capacitor, that's going to modify it the whole time. Just my 2 cents, I might be wrong though.

[Al Skierkiewicz]

Hi All,
Using capacitors to simulate a ramp up is an interesting way to go for this solution. There is some interesting effects that take place though that would make their operation on robot function a little weird. If you are just thinking of a capacitor taking a finite amount of time to charge up to a value, than you are right. But a charged capacitor also takes a finite time to discharge and both the charge and discharge times are a function of the resistances in the joystick and the input circuit of the contoller. All in all, you would be more happy with the results when acceleration are handled by software.

[golf_cart_john]

I think you might end up regretting using a capacitor. If you do use one, the robot is liable to respond a little sluggishly, which you really don't want. My team had a similar problem 2 years ago, and we fixed it by just dividing the input of the joystick by a number. Software seems to be a better choice than a capacitor.

[KenWittlief]

what you really need to do is

instead of feeding your driver Mt Dew and hotdogs

bring some herbal tea and some carbohydrates, and a CD player with soothing music

and let your driver find his calm and happy place before each match.

Im really amused watching drivers in some matches, leaning into that joystick like they are pushing on the frame of the robot itself

COMEON GO! GO! GO!

Im surprized they dont snap in half :c)

[Matt Reiland]

Originally posted by KenWittlief
what you really need to do is

instead of feeding your driver Mt Dew and hotdogs

bring some herbal tea and some carbohydrates, and a CD player with soothing music

and let your driver find his calm and happy place before each match.

Im really amused watching drivers in some matches, leaning into that joystick like they are pushing on the frame of the robot itself

COMEON GO! GO! GO!

Im surprized they dont snap in half :c)

No Kidding, in fact I am surprised most teams even use a joystick, most drivers I watch could get by with a 3 position switch, Full Fwd, Full Reverse, or stop. Our driver last year would continuously go back and forth full throttle on the sticks when he got excited, poor gearboxes!!!! Programmers can really help out here and extend the life of the drivetrain.

On a similar note, has anyone noticed you can't do a neutral drop on a car these days?? Not that I would ever try......

[KenWittlief]

you mean reving the engine up in neutral and dropping it into drive?

yeah, you can still do it, but you have to be stepping on the brake at the same time

which kinda defeats the whole purpose.

I think this is do to several lawsuits where people shifted into gear while stepping on the gas instead of the brake and someone got injured - so now you cant shift into gear unless the brake pedal is pressed.

[Ian W.]

The best thing to do is not alter the code at all, and as said above, have a calm driver.

I've been a driver for two years now, and I know that it can get crazy. Hell, I've been almost smacked for not listening/responding to orders from the rest of the drive team I think . But the biggest thing I've noticed, you need to pretend that it's like your road test.

If you are the driver, just pretend that if you accelerate too fast, the robot will explode. Have a light hand, and keep every movement smooth, UNLESS your robot is designed to handle whatever you throw at it (see 810's robot from 2002). Listen to your drive team, because they can see stuff you won't, and they can beat you if you screw up . With a little practice, it's really not all that hard to get the robot to accelerate smoothly with no modifications to the software. And the less you change, the less that _might_ break. And no one ever complained about that .

[KenWittlief]

putting a filter in the control path (one way or another) really is a tradeoff. If you let the driver slam the controls back and forth, and the SW tells the motor to do exactly what the joystick says, then you can break shafts, rip gears apart, your breakers can open (disabling you for a few seconds)

but on the other hand, if you smooth out the commands so the motors rev up gradually, then you never know when the drive might really NEED to slam the motors full reverse, or push the machine to its limits, to win a match.

At our last few matches at our last regional we told the drivers "Tomorrow this robot will have absolutely no value to anyone, so if you have to destroy it to win the next match, then so be it"

everything in enginnering is a tradeoff - you make the robot more reliable, and that will cost you in performance.

[Kevin A]

I think its best in the programming. It would be interesting to put a cap in there though, see what happens.

As the driver, I will tell you that a sluggish robot sucks.

[RukkyG]

for those curious about the "software" method and theory: http://www.peci.org/papers/pid.pdf

[kmcclary]

Unfortunately, connecting caps, inductors, filters, et al to an OI input would constitute a "custom circuit". As of last year's rules, that is illegal (Section 3.2.7 "Custom Circuits and Additional Electronics", rule C29). Yea, yea, I know it would make sense in many ways, but until FIRST changes the rules, if they're interpreted strictly we just can't do it.

I'd like to see the rule if not abolished, at least relaxed to: "No ACTIVE circuitry on OI inputs", or "no computational elements beyond passive components and simple filtering allowed on OI inputs". That would at least allow things like what you are suggesting, along with cool tricks like R2R ladders and pushbutton combos on a Joystick analog input to expand the number of digital switches into an OI (we ran short last year).

Luckily, anything you can do with caps and inductors on input leads can easily be done in software.

Really though, the REAL problem is that until you convince the Drivers to lighten up, all the filtering in the world won't help much. In fact, we got into a Programmer vs Driver Behavior war over just that problem two years ago.

Our drivetrain kept breaking due to sudden operator motor reversals. So, the programmer kept increasing filtering elements to protect the hardware. But in response, the drivers unconsciously started slamming the controls more and more to compensate. No amount of training, begging, etc. could cancel that. After all, humans will unconsciously do WHATEVER is necessary with the controls to try to make the robot behave as they THINK it should.

It finally got to the point where the drivers started holding the BOTTOM of the joysticks with their thumb and forefingers. They were always slammed one way or another, and everyone was unhappy because the robot still wouldn't act as the drivers wished.

So I had the programmers give up. We stripped out ALL of the filtering code, and I warned the drivers that THEY are now responsible for keeping the machine intact, and if the bot now broke more than once from driver abuse, they risked being replaced.

Gee, for some odd reason that made them a LOT more cautious! The code became MUCH simpler. We only had to recscale a couple of joystick channels.

The robot ran just fine. It never once broke again due to driver control error. (Ditto this year with my new team.)

- Keith

[Al Skierkiewicz]

Keith,
You reminded me of a fix in a high school physics class....
The classes had progressed to using a ripple tank to experiment and demonstrate wave theory. For two weeks there was not a dry spot in the physics lab and the ceiling in the classroom below was threatening to fall from all the water seeping through the floor. The physics teacher walked in one day and announced that the next team to spill water on the floor would flunk the class. It was as if the Bounty paper towel company had come in, the floor was instantly dry and stayed that way through the remainder of the wave theory labs.