Single Joystick Code Difficulties

[willie837]

OK, our programming team is made of three newbies who have not much idea of what they are doing. We have a few (lot) of main problems.

1. Our robot is super sensitive.
2. Our robot goes left when we push foward and right when we push back (as well as foward and backward, respectively)(we have a single joystick code).
3. Our robot goes right when we hit the trigger.

Thank you for any help that you offer!

[Alexander McGee]

Well, when you say "hit the trigger", does that mean "turn it on"?

If that is the case, you may need to calibrate your joystick(s).

Or do you mean the button on the joystick?

Sensitivity is due to the joystick you are using. The ones in the kit this year and last really suck. Buy and old flightstick on ebay for 10 bucks (we bought 4). They are set up for right and left hands as well!

Try using the dashboard to view the signals coming from your joystick when you move it to certain positions, and match those numbers with the single-joysitck code. It sounds like you just have somehting backwards.

I don't have much experience with single joystick code, but it probablly depends on the joystick you are using. I have always found driving with two joysticks to be the most enjoyable / simple way to do it.

[willie837]

Well, when you say "hit the trigger", does that mean "turn it on"?

I mean push the trigger button down on the back of the joystick.

And thanks for the help.

[Workaphobia]

Ok, if your robot turns when it should be moving straight, then the joystick might be somehow transposing the axes so that forward and backwards is read in as p1_x instead of p1_y. I'm not sure if that ever really happens though - the much more likely cause is that because of the way the motors were wired, one of them moves in the opposite direction from whichever way it's supposed to go, so that when the code thinks its moving both forward it's really turning. The solution is to go into the part of the code that maps inputs to outputs (Default_Routine in user_routines.c if you haven't changed it) and check out what's going on there.

"pwm01-04" are probably your motor outputs, "p1_y" and "p1_x" are your joystick axes. Both of them can range from 0 to 255 (ideally 254) with 127 being neutral. You can reverse the value of pwm01 by doing "pwm01 = 254 - pwm01;". Experiment with reversing the values of the outputs until both sides move forward when the joystick does.

Also be careful that you don't run two motors in opposition, if they are attached to one gear.


As for sensitivity, you can add a deadzone to the joystick so that within a certain center range it'll output no motion. Use an if() statement in your code to detect if its close to 127, and if so, set the pwms to 127.

I have no idea what would cause the robot to move when the trigger is pressed, but you can check and see if it's referred to in user_routines.c by the default code. Do a search for "p1_sw_trig".

[willie837]

our pwms are at 127...we just cant seem to get it. We want it to get REALLY slow...REALLY REALLY FREAKIN SLOW!!!! lol sorry...but if anyone has an idea please tell us.

our robot has two motors, one for the drive and one for the steering.

[Billfred]

IANAP, but I did find this white paper:

http://qin.laya.com/first/joystick.html

The code is in PBASIC, but you should be able to adapt it.

Hope this helps!

--Billfred

PS: Rabid acceleration sometimes just comes with the territory. You should've seen it when I hit the sticks on Ockham.

[Elemist315]

I'm in the same boat as Willie (Newbie team and sensitivity issues that is). I did try the dead zone thing but we didn't like it because we then had no fine control. We had the engineers create a formula for us to use to try to get an exponentially increasing acceleration but the compiler then refused to build it (grrr :mad: ). I think it has something to do with the answers coming out as decimals but I'm not sure as I don't know C that well (I'm just glad I wasn't on last year, would've had no clue on pbasic). Any insight would be great.

[Workaphobia]

You'll want to use a combination of both a small deadzone and a sensitivity curve - without the curve it'll just suddenly jump around when you start moving. I like sinusoidal functions for this, but because they use floating point arithmetic it's a tad slower than some other polynomial methods. Most of the time the processor is idle anyway, so it wouldn't make a huge difference.

Can you be a bit more specific about your compile problem? C can be annoying with calculations, but it's normally not too hard to get it to cooperate.


I'm a bit tired and am starting to lose track of what I've said in what thread, so I'm not going to give any lectures tonight. :)

[jgannon]

Here's one way of making your joystick a lot less sensitive, without cutting down your maximum speed:
http://www.chiefdelphi.com/forums/showpost.php?p=325714&postcount=5

[Hendrix]

ok, the problem with going right when you hit forward is, one of your motors is wired backwards... Simply swap the pos and neg on one of the motors to the speed controller and that will be fixed. (if you swap one and when you hit forward you go backwards, then you need to swap both of them again because you swapped the wrong one) As for the sensitivity, i don't know about that. It could be that your robot is geared to high and you have way more speed than you need anyways.

[Alan Anderson]

our robot has two motors, one for the drive and one for the steering.
That's unusual. Most robots have independent drive motors for the left and right sides of the chassis. Relatively few teams implement steerable wheels.

If you give more details about what those motors are connected to, both mechanically and electrically, we'll be better able to help you work out your control issues. What modifications to the default code have you made, if any? The color-tracking part of it is definitely not set up to handle mechanical steering.

(By the way, the joystick trigger is usually considered to be on the front.)

[Darkelement]

If you have one motor for drive and one for steering, you need to adapt your code so that the pwm inputs correspond to each other. i.e. pwm 1 matches pwm 1, etc.