Joysticks with circular motion

[Tom Line]

We are using our joystick to control our turret. However, like most joysticks manufactured today, the joystick has a square restrictor that forces a square motion. Short of opening the joystick and machining a restrictor to allow only circular motion, is there another joystick currently on the market that is set up this way for USB and is a reasonable price?

The square motion causes issues with aiming the turret - when you are in one of the corners you have fine control and your amplitude is larger. When you are in either the x or y axis, however, the turret is more sensitive because your distance from center is smaller and a change creates a larger actual angle change (we convert the joystick to polar coordinates).

We really don't have time to change what we have, but perhaps we can be ready for next season.

[Jared Russell]

May I ask why you need two joystick axes for turret control?

For example, our turret is controlled solely by the X axis of the operator's joystick. Alternatively, you could use a stick with a yaw axis (Z or twist).

[Tom Line]

Because we have our joystick set up to handle the turret similar to how crab is programmed - push in a direction and the turret turns to that direction.

[Jared Russell]

Do you need magnitude from the stick, or just direction? In the latter case you could use a continuous pot or encoder with a knob.

[Tom Line]

We started out with that as one of our designs. However, we like to simplify the controls system as much as possible, and the joystick's integrated buttons made that chore much easier. We already have a knob for the left hand that sets distance for the turret system :).

[Bob Steele]

I would suggest that you use one of the joystick controllers that allows yaw control by twisting the joystick.

We use this to control our crab/swerve drive... twist one way turn that way
twist the other way and turn the other way...

Just make sure and find one that will work with the present system.

[The Lucas]

Do you need magnitude from the stick, or just direction? In the latter case you could use a continuous pot or encoder with a knob.

We started out with that as one of our designs. However, we like to simplify the controls system as much as possible, and the joystick's integrated buttons made that chore much easier. We already have a knob for the left hand that sets distance for the turret system :).

How about using the joytick's throttle, it will stay in place? If you aren't satisfied with the small throttle on the kit joystick you can buy a better one or just a USB throttle. My team uses the Saitek AV8R (http://www.buy.com/prod/saitek-ps33-aviator-joystick-saitek-aviator-joystick-cable-usb-ps33/q/loc/108/203277896.html) (Only $35 w/ free shipping right now) for the past 2 years. Its not circular, but has 5 axis (x, y, twist, dual throttle) and 12 well located buttons.

[Lil' Lavery]

I would suggest that you use one of the joystick controllers that allows yaw control by twisting the joystick.

We use this to control our crab/swerve drive... twist one way turn that way
twist the other way and turn the other way...

Just make sure and find one that will work with the present system.

I concur, a three-axis joystick with the z "rotational" axis being used to "throttle" would seem like an ideal method. The problem is that 3-axis joysticks are often made for industrial purposes, and tend to be pricey. A quick google search only yielded a few results for 3-axis USB joysticks. :(

edit: see below.

[Cory]

I concur, a three-axis joystick with the z "rotational" axis being used to "throttle" would seem like an ideal method. The problem is that 3-axis joysticks are often made for industrial purposes, and tend to be pricey. A quick google search only yielded a few results for 3-axis USB joysticks. :(

Really?

I have a Microsoft Sidewinder from ~10 years ago that has the twist function on the Z. It couldn't have been more than $50 then.

I'd have imagined that would only be more widespread now than in 1999.

[Joe Ross]

I concur, a three-axis joystick with the z "rotational" axis being used to "throttle" would seem like an ideal method. The problem is that 3-axis joysticks are often made for industrial purposes, and tend to be pricey. A quick google search only yielded a few results for 3-axis USB joysticks. :(

We're using the Logitech 3D pro (http://www.bestbuy.com/site/olspage.jsp?skuId=5796515&st=joystick&lp=4&type=product&cp=1&id=1058188350464). The joystick Brian linked to earlier has it too.

[Lil' Lavery]

Hmm, perhaps I should have searched amazon/best buy/etc instead of google. I see that there are a number that I was unable to find. :o

[JesseK]

How about using the joytick's throttle, it will stay in place? If you aren't satisfied with the small throttle on the kit joystick you can buy a better one or just a USB throttle. My team uses the Saitek AV8R (http://www.buy.com/prod/saitek-ps33-aviator-joystick-saitek-aviator-joystick-cable-usb-ps33/q/loc/108/203277896.html) (Only $35 w/ free shipping right now) for the past 2 years. Its not circular, but has 5 axis (x, y, twist, dual throttle) and 12 well located buttons.

These things looked sick in person :D We could probably find a practical and intuitive use for all of those axes too, hmm.

[Tom Line]

I think I need to clarify a bit.

Our turret looks at the gyro and initial heading of the robot to determine absolute angle to the field.

If the joystick is pushed to the west - the turret turns and aims west. If the joystick is pushed north - the turret turns and aims north. Regardless of what direction the robot is facing.

That is why I need the circular range of motion joystick. Adjusting the gain of the turret for angles close to the x and y axis result in the turret being very slow in the corners because the joystick is much further from the center. Adjusting for the corners makes it touchy when the joystick is pushed in the direction of x and y axis.

Potentionally we could use an encoder and calibrate it - continous turn pots have too much of a dead zone to be desirable. However we have many functions that are tied to joystick buttons that are simply too late to change.

Perhaps we'll just machine a 2 part collar that will fit around the top of the joystick to limit it to circular motion.

[Jared Russell]

What do you do if (when) the joystick returns to center?

[Lil' Lavery]

What do you do if (when) the joystick returns to center?

Ditto on that question. I'm assuming it stays in whatever the last position it was told to goto was?

A "field-centric" turret control is possibly one of the coolest things I've seen done control wise in FIRST. A number of teams have done field-centric drives (especially holonomic and mecanums), which is perhaps even more daunting, but you're the first I know of to do field-centric turret control.

I don't know of any circular range of motion joysticks, and was unable to find one (although I did run into customizable joysticks designed for arcade machine enthusiasts, which may or may not be useful to you). Depending on how you have your code written (namely the return to center question), it might be possible to use a trackball though. You'd have to fine tune it for the trackball control and your driver would have to relearn the system, but it could potentially work well.

[Al Skierkiewicz]

Why not just use a pot?

[Jetweb]

We are using this joystick this year for our crab drive. It has a circular restrainer and works great. It even has twist.

http://www.logitech.com/index.cfm/gaming/pc_gaming/joysticks/devices/291&cl=us,en

[Joe Ross]

We are using this joystick this year for our crab drive. It has a circular restrainer and works great. It even has twist.

http://www.logitech.com/index.cfm/gaming/pc_gaming/joysticks/devices/291&cl=us,en

Ours definitely moves in a square.

[Tom Line]

With regards to what happens when the joystick returns to center - the turret simply stays at the last angle it was directed to go to. We use the magnitude (the R value coming out of the Labview rect => polar coversion vi) to add a deadzone to the joystick.

Seeing this thing in action the first time (in our room) dropped the jaws of many team members. I have to give all the kudos to the two Junior programmers and the two sophmore programmers who did it. The math is far easier than I thought it would be when we started.

The neatest part of it was when we put the robot on a turntable. You could push the joystick in a direction and release it. From then on, no matter how you turned the robot on the turntable, the turret always pointed in the same direction. I was amazed.

It allows anyone to walk up to our gunner station and have intuitive control. Push the joystick toward the target robot, and you're on target. We're going to let judges play with it to see if they're as startled by the performance as we were :) .

Al - we considered a pot - like a 10 turn. However, I was concerned about what would happen in the off-instance where the gunner reached the end of the turns in a critical situation and had to spin it around the other way. I like trying to simplify and plan for every eventuality, and that created a problem I didn't want our gunner to have to deal with.

[EricVanWyk]

I'm really liking this idea - I hope I get a chance to try it.

Do you use |R| just for a dead zone, or do you also use it to vary the speed with which it approaches the intended direction?

Again, cool!

[Tom Line]

Ditto on that question. I'm assuming it stays in whatever the last position it was told to goto was?

A "field-centric" turret control is possibly one of the coolest things I've seen done control wise in FIRST. A number of teams have done field-centric drives (especially holonomic and mecanums), which is perhaps even more daunting, but you're the first I know of to do field-centric turret control.

I don't know of any circular range of motion joysticks, and was unable to find one (although I did run into customizable joysticks designed for arcade machine enthusiasts, which may or may not be useful to you). Depending on how you have your code written (namely the return to center question), it might be possible to use a trackball though. You'd have to fine tune it for the trackball control and your driver would have to relearn the system, but it could potentially work well.

One of the members on the team who uses NX3 and Inventor was pushing us to use a spaceball for it. The control board would look awesome, but I wasn't completely sold on ease of use :D

http://www.gamedev.net/features/reviews/productreview.asp?productid=509

[Joe Ross]

Al - we considered a pot - like a 10 turn. However, I was concerned about what would happen in the off-instance where the gunner reached the end of the turns in a critical situation and had to spin it around the other way. I like trying to simplify and plan for every eventuality, and that created a problem I didn't want our gunner to have to deal with.

This should work well: http://usdigital.com/products/encoders/absolute/rotary/shaft/ma3/

[Tom Line]

I'm really liking this idea - I hope I get a chance to try it.

Do you use |R| just for a dead zone, or do you also use it to vary the speed with which it approaches the intended direction?

Again, cool!

We use R as the dead zone. We take the polar angle of the joystick, and compare it to an angle calculated from a 10 turn pot connected to the turret. We feed them into a PID loop that handles pointing the turret. It's generally within a degree of where you push the joystick, and gets full 270 degree rotation in 2 seconds.

Shooter speed is controled by a knob with foot graduations.

Again - I have to credit the programming team. The mentors said "wouldn't it be cool" and the team ran with it. I answered a couple of math questions for them, but I just watched over their shoulders while they figured out the "comparator code" to relate the angles.

I guess I'll spill the beans on the whole control system setup. The camera is mounted on the turret and constantly tries to track anything in the FOV that it can lock on to. However, it doesn't control the turret motions.

The gunner can pull the trigger and fire while aiming - that will fire balls with manual aim. Or pull the trigger and push the top button on the joystick while aiming. That allows the camera to take control of the turret - but only if it has a lock. The assumption is that the gunner continues to aim as best he can, so if the camera loses lock it immediately reverts to the angle the gunner is telling the turret to go to.

It took a lot of programming time to get the transitions between the modes seamless, but now you can barely tell when the gunner is using either method. The neatest part (I think) is that the gyro code that keeps the turret at an angle is tied into the camera code too - so if the bot turns, the camera has little trouble staying on target.

[Tom Line]

This should work well: http://usdigital.com/products/encoders/absolute/rotary/shaft/ma3/

Oh my. Maybe we'll play with implementing that between regionals.

[SmokeTest]

Team 116 uses the MA3. We also use the KOP gyro to give field-centric turret aiming. In addition, we put a simple toggle switch on the OI as a fallback (in case the gyro stops working) which gives our 2nd driver clockwise/counter-clockwise rotate controls. He told us last night that he actually prefers this to the field-centric knob, but I suspect he hasn't tried aiming the turret with the robot heading toward him (which reverses the relative aiming directions).

-Mike Youmans

[Tom Line]

He probably also didn't try to aim from 50 feet away with 5 other robots interfereing in his field of view :D

[JesseK]

Team 116 uses the MA3. We also use the KOP gyro to give field-centric turret aiming. In addition, we put a simple toggle switch on the OI as a fallback (in case the gyro stops working) which gives our 2nd driver clockwise/counter-clockwise rotate controls. He told us last night that he actually prefers this to the field-centric knob, but I suspect he hasn't tried aiming the turret with the robot heading toward him (which reverses the relative aiming directions).

-Mike Youmans

Alot of video game addicts (or ex-addicts) who have played 3rd person shooters prefer robot-centric control rather than field-centric. We're just used to processing it in reverse if the bot is coming towards us, and doing it the other way around simply boggles our minds sometimes ... silly video games :rolleyes: .

[SmokeTest]

This is bit off-topic, but I think the reason the MA3 isn't more popular is that all prior Operator Interface controllers had a dead band programmed into it. The IFI Robotics manual says:
---
Digital value response for approximate analog input values: Digital 127 for 0.0v to 0.1v.
Digital 0 for 0.11v to 0.52v. Increasing from digital 1 to 254 for 0.53v to 4.99v.
---
Imagine rotating the knob from from 4.8V, 4.9V, 5.0V, 0.0V, 0.1V, 0.2V, etc. The OI software reports 252, 253, 254, 127(!), 0, 0, 0, ... then finally starts incrementing past 0 after about 40 degrees. This kind of behavior makes sense for a joystick, but not for the MA3. [The reason 127 corresponds to 0V is to stop a motor controlled by a Victor when a joystick gets unplugged.]

How to avoid this dead zone had me stumped all during build season last year, but I finally figured out a simple kluge to change the voltage at the analog input to avoid the 0V - 0.52V dead band. I added a diode (forward biased) between the ground lead of the MA3 and the ground pin of the OI. At the 16 mA current drawn by the MA3, the diode's forward voltage was about 0.6V. This made the minimum voltage at the input pin (output of the MA3) about 0.6V relative to the OI. From the MA3's point of view, it thought it was going between 0V and 4.4V, but it's shifted by 0.6V because of the diode's (relatively) constant voltage drop. US Digital specifies a minimum supply voltage of 4.5V for the MA3, but it worked for me at 4.4V. (That's why I call it a kluge.)

As I said, this might be a little off-topic now with the new Driver Station controller, but if anyone wants to retrofit an IFI Operator Interface controller with the MA3, you might want to try this trick.

[AmoryG]

With regards to what happens when the joystick returns to center - the turret simply stays at the last angle it was directed to go to. We use the magnitude (the R value coming out of the Labview rect => polar coversion vi) to add a deadzone to the joystick.

Seeing this thing in action the first time (in our room) dropped the jaws of many team members. I have to give all the kudos to the two Junior programmers and the two sophmore programmers who did it. The math is far easier than I thought it would be when we started.

The neatest part of it was when we put the robot on a turntable. You could push the joystick in a direction and release it. From then on, no matter how you turned the robot on the turntable, the turret always pointed in the same direction. I was amazed.

It allows anyone to walk up to our gunner station and have intuitive control. Push the joystick toward the target robot, and you're on target. We're going to let judges play with it to see if they're as startled by the performance as we were :) .

Al - we considered a pot - like a 10 turn. However, I was concerned about what would happen in the off-instance where the gunner reached the end of the turns in a critical situation and had to spin it around the other way. I like trying to simplify and plan for every eventuality, and that created a problem I didn't want our gunner to have to deal with.

Our team uses a system similar to what you guys have, but the joystick doesn't rotate our shooter, but our whole robot's base. We have a crab drive, so our robot can rotate its base without affecting its movement.