You have the command to start the motor, but there is no command to stop the motor when you let go of the button. You need to include motor[port??] = 0; somewhere in the code to tell the motor to turn off when you release the button.
Unfortunately due to large delay between reading question, starting to answer, OP posting his code, and (then returning from meeting) hitting submit. Props to @winstryg but the threshold code was in error as well. Now back off to the weeds …
This is correct for use of the buttons, but the main issue with the joystick (what was asked) is indeed due to not taking the absolute value of the joystick value.
jpearman pointed out where this is applicable in the joystick code and supplied the solution.
The drive power never updates when the joystick is <= 10, so it will never go backwards.
My Excuse is… I had 5 Bugs to Squash in a Product that needed to ship out Today, Overnight delivery… So I spent, 30-45 Seconds looking at the Code and posting, in haste an answer…
I will be forward and up front here… I now have Licenses for Three Versions of RobotC, Four Versions of EasyC, and MPLAB with C18… But know the least about implementing RobotC…
So… I was assuming that the OP, knows what their doing, and that they are truly concerned about the Motors, leftMotor and rightMotor, controlled with the Joystick, by focusing on just this code:
Since these seem to be the Only Relevant lines related to Joysticks and Moving Forward ( and Backwards )… These didn’t make much sense to me, but I figured that this was something Special in RobotC or achieving some sort of particular Control Mode I had not seen before…
First Off… Ditto on the Kudos to winstryg, yes you need motor[port??] = 0; to stop the motors… OR… some, very close approximation…
This is a Summation of what went wrong…
Second, jgraber, what was your understanding ( before you Scrolled Down ) on why this was “inapplicable (stick vs button) tangents about thresholds and calibration”?? I am curious what you thought was happening… Since, I really don’t understand much about RobotC…
Now, jpearman, After you added the abs() to the Channel Return Values, then that made sense to me… You are Creating a Dead Band, of ±10 Counts, which is setting neither Forward or Backward direction… And the else, sets the Motors to OFF, as winstryg pointed out was needed to Stop the Motors…
Also, I understand that Read Post, GoTo Meeting, Post Response, Retract Mistakes, Apologize for Haste, Fall on Sword in Shame, while Working…
And last in the postings ( at this time ), dontworryaboutit, * summarizes* what I was focusing on in connor776’s Code, “The drive power never updates when the joystick is <= 10, so it will never go backwards.”
Because if there was no Threshold Check, the Two Joystick Axises, could achieve a result close to ( or exactly ) Zero, and stop the Motors…
So, Now… I have one Final Question…
The Comments show, " // (y + x)/2 and // (y - x)/2 ". I see the “(y + x)” and “(y - x)”, but where does the “/2” happen??? Just for my own education…
Now this works just fine, except for the fact that forward motion is limited to half speed as (127 + 0) / 2 = 63.5 (where the full speed of the motor is defined as being 127), so many roboteers modify the code to remove the “/2” but forget to update the comment. The downside to this is values may exceed the maximum that the motors can handle. Luckily ROBOTC limits motor control values for the user although I still prefer to add explicit clipping.
Mark, I’m sure you already knew this but it’s worth explaining for others that may be wondering.
Right… I’m a Tank Drive Man, myself, but I should recognize an Arcade Drive Algorithm…
I would think a High Order Truncation would occur, ( An IBM’ism referring to the Most Significant Bits being Lost Learned as the result of a misspent youth, learning Business Programming Languages… ] ), so Over-driving the Motors would be of Minimal concern…
What I see as an Issue, is making turns Slow, because of the Minimal Difference in Motor Speeds… Or am I thinking this Through Incorrectly??
Comparing the Above Code to your Threshold Code, Below:
Your Code will Execute in a lot less time, with Two Less calls to abs(), Two Multiples by -1 and Two additional Logical Tests by AND ( && ). I see that as a Win, All the Way Around…
I was not quite Thinking it Through… Maybe I can claim, I was in a hurry, Officer… I didn’t see the Ramification…
Without scrolling, the initial RobotC code I saw showed that all
the VexRT references are to digital Buttons UP/DN, (not sticks),
and all the motor speeds were +115 or -115.
With scrolling, there is an arcade drive code that sets the same motors,
I may not have even noticed the threshold problem if I had seen the code.
I put my own foot-in-mouth with my snarky comment, by not reading the full post.
Speaking of calibration/threshold/deadband,
I’ve previously posted this workaround to use a button to auto-center the joysticks values:
Its not as good as full calibration, but its handy to easily stop annoying motor hum or wheel creep.
I did Scroll, and Ignored the Buttons, because the OP mentioned Joysticks…
I noticed the Threshold for Channels 1 and 2, but did not know what the Threshold was limiting, so I did not notice a problem with it either… ( Score: -1 )
Well, it can happen to anyone… I seriously only gave the whole code a 30-45 Second look over… I had an extremely large chance of putting my own foot-in-mouth… In retrospect, I look competent, but Not Expert level.
Nice Work… With an explanation and the Note to Use a Spread Sheet and Plot it for our Visual Learners… I might add a little to it… Maybe make it a Library… Include a Picture of the Graph Plot…
Thanks for the After Action Review ( AAR ). I am still getting use to some of RobotC’s way of doing things…
Lot’s of fun on this thread while I was tied up in meetings all morning.
One further point I don’t think anyone has noticed (or perhaps they have) is that “right” and “left” are not motors but servos, thats presumably why 0 is never sent to them, they are directed to one end or the other.