I am submitting a request to have the VEXCODE group look at implementing the changes necessary to allow teams to have a 2-Speed drive system without having to develop their own drive system.
To be consistent with the Drivetrain commands that set Drive Speed and Turn Speed, define two new commands to limit the controller axis by setting a percentage specified by the Drive and Turn percentage. (Use those same commands?) The percentage can be applied after reading the controller axis. Axes 1 and 4 control the turning, AXIS 3 and 2 control the drive speed, regardless of controller configuration used. Set the default percentage to 100% for compatibility, If a team wants to limit their robots drive or turn speed under certain situations, they can use a button on their controller to change the percentage of the joystick axis for driving or turning by setting the new command’s value as needed. In our testing, rather than percentages, we use whole numbers and divide the axis value by the proper variable, our robot is so fast turning, the normal turn value is 2 (or 50%) and when we need to slow down for aligning to score, we use 4 (or 25%).
It makes the team’s robot so much easier to handle when lining up to score cubes. Our current implementation is very complicated and subject to error and it would be great if other teams could take advantage of this capability, The forum has teams asking about it.
You have a problem, and you can make your own solution.
Or put “site:vexforum.com exponential drive” or something like that into Google search.
The resources above are related to “exponential drive,” mapping joystick positions to motor power using a non-linear expression/function/graph (idk lol). It solves your problem and is easier to implement than the “two-speed drive system.”
Thanks for the solution for those of us that are capable of uding C++ or python.
I was suggesting a solution for those block coders that are not yet ready (or capable) of jumping into C++.
Since the block coders can control the drivetrain speeds (drive, trun) it seemed logical to extend tat capability to the joysticks. I have a couple of solutions alreadyl
@rs1 linked a old (but still very relevant) post of mine
I am happy to share some thoughts.
For context, we faced the same engineering problem in the 2018-2019 season Vex Turning Point. We needed to be fast enough to drive around the field, dodge defense, and shoot flags. We needed precision while aiming for flags and the parking platforms.
I will summarize a few simple work arounds that have been mentioned.
Holding a slow mode button down. The logic is simple, if a button is pressed, then multiply the max_speed by a factor n. This factor can be a fraction (slowing speed down) or a whole number (increasing speed). Depends on what preference you have. Like you mentioned it is very crude and difficult to customize more than 2 speeds, although we did use it at early comps pretty successfully. Simple and effective wins often.
Use two drivers. Hard and chaotic tbh. Especially from a former driver, programmer, and drive coach 's perspective. Driver should focus on driving and their reaction time is limited by communicating with drive coach / co-driver. From a programming perspective, this is a hard problem. Two inputs controlling one hardware resource. Could be come a recipe for disaster without carefully written code. Could become a huge point of argument during the pressure of a competition. I have only used two drivers where each one controlled different subsystems with no overlap
Now, we can think about a generalized answer to the question you originally posed: Is there a way to have 2 drive sensitivities? What about n drive sensitivities? Note: I am intentionally use the word sensitivity. This is because joystick values are continuous rather than just “two values”. Sure you can have two max speeds, but that is not an elegant solution. Instead, its better to think about it like this. In “slow mode” If I push the joysticks half way, I only move at quarter of the max speed. In “fast mode” if I push the joysticks half way, I move at half speed. Slow mode should give you more “resolution” to hit lower speed values. So how do we get “slow mode” and “fast mode” to move at full speed when the joysticks all the way?
We can use a function! A continuous function like you might see in early algebra classes. Take a look at this post I wrote:
You can see that these functions all start at (0,0) and intersect (1,1).
This means, when you don’t push the joysticks you have 0 speed. When you push the joysticks all the way, you have full speed. The change in slope between 0 to 1 is what matters. When implemented, it really makes a noticeable difference!
Now, in terms of code in blocks you just have to do some multiplication and division to the joystick value before sending it to the motor block. You can even skip the exponents by using repeated multiplication. Don’t forget that even powered functions cannot be negative. So should probably do all the math inside an abs value and then multiply by the sign of the joystick.
If I were using scratch and wanted to model the quadratic curve, it would look like the following. Note: max_speed must be the max value that the motor takes in. It could be 1, 100, 127 etc depending on which environment you are using.
I think the best multi-purpose speed setup was right stick arcade with left stick as the speed muliplyer. In a center position, all directions full stick ran at 30% of full speed. Moving the left stick forward multiplied just the forward speed, turns were still slow. (Forward on this robot was easily ludicrous speed, it was prone to tip at high speed turns. ) Backwards was at the low speed.
If you put the left stick in either the upper left or right quadrants turns would also get the max speed muliplyer.
Lacking eye - hand coordination, I always drove not touching the left stick. But the good drivers were magical.
There was an earlier feature that on left stick full down/back it would feed 100% reverse power for 2 seconds to act as a super break. On a 100lb robot it worked a few times and then motors were toasted so it was removed.
