What is the optimal drivetrain speed for Vex Gateway?

VEX V5 General Discussion General Forum
#1

Gateway is all about scoring fast. Scoring before the opponent is worth more points and scoring all your pieces first allows you time to prevent them from doing the same.

However, there is also the need to be able to hold one’s ground in Gateway. Smart defenders will simply sit in front of important goals to prevent scoring. Teams are often pushing compeating for position on the 30" middle goal, and in top level play the ability to push allows you to defend your doubler barrels from being taken off/put somewhere else/negated.

So… What is the optimal drivetrain speed? Is it better to slow down your top speed a bit to retain some pushing ability? Do you want a blazing fast drivetrain that can’t really push? Or should you gear down so you can slowly but steadily make your way to a goal and push anyone and everyone out of your way to get there?

Also, how do these options change when you are starting in the interaction zone vesus the isolation zone? When using a 4 motor drive vs a 6 motor drive? (or even 8 if your especially crazy)

One last thing, being new to vex I don’t really know what kinds of speeds actually qualify as fast and slow.
Right now I’m pretty much of the mindset that approximatly:
slow=1.5fps medium=2.5fps and fast<3fps
If anone cares to confirm or correct those assumptions that would be great.

I look forward to reading all of your arguments for speed vs torque in Vex Gateway!

Regards, Bryan

#2

Please note that the following is just from the experience that I had at the Southwestern Michigan Autodesk VEX Qualifier and may not be true of other competitions.

During our time there, we noticed that going fast wasn’t necessary. We were probably in between slow and medium and had no trouble at all. On the contrary, it may have been better to have a slow drive train as we had no trouble lining up to the goal whereas other teams had minor issues with movement. (Which I realize can be fixed relatively easily with programming)

That isn’t too say that going fast can’t be advantageous. I am simply stating that from the conditions we were faced with being slow was not an issue.

I may be completely incorrect with my assumptions as they are only relevant to the matches that I personally drove in.

#3

I personally think its best to have a bit of both, which is why I’m building a two speed gearbox, one ratio at 7:3 (speed) and the other at 1:1 on large omnis - if I had to choose one, I would choose speed as the faster you drive, the faster you score, and hey, you can always drive around the slow pushing robots…

#4

I think it depends on where you are competing. At smaller or early less competitive competitions the consistency of slow and steadiness will be advantageous.

However, at highly competitive competitions where all of the goals will be stuffed quickly, getting the bonus for scoring in a goal first will be be a bigger part. Also because some teams can fill a goal (or two) with one dump you may not have a chance to put anything in that goal if you aren’t there first.

#5

faster is better (if its still controllable that is)
our drive right now is 1.6 : 1 on 4" wheels which is in the “middle” of speed and torque

in the first competition, weve had robots that just shadowed our every move and kept on “bumping” us
we didnt shove back, or yell “pinning!!!”, we just drove around them every time and continue playing the game
i would like our speed to be 2:1 but they might not support the robots own weight for very long

our C team has a 2.3:1 ratio on a dual tank tread pickup
but it was fast as a demon, but it was too uncontrollable at that speed
if he had more practice, he would have scored around us in circles

i think this all comes down to driver skill (with programming aid)

#6

At World Cup, we had 6 motor drive (4 x 393 and 2 x 269) at 1.67 on our interaction robot and 6 motor drive (2 x 393 + 4 x 269) at 1.3 on our isolation robot. We felt that these ratios gave us sufficient speed (especially on our interaction robot) whilst still maintaining enough torque to get out of trouble if we needed to.

The design philosophy was that the isolation robot did not have to travel as far as the interaction one, and hence did not need to go as fast. It also had a faster 1:5 lift than our interaction robot.

We did our fair share of pushing at World Cup, and to put it from our chairperson’s perspective, it was an “expensive competition”. Off the top of my head we broke about 5 motors total (mostly 393 internals).

We had a great discussion with Paul from VEX about linear filtering, that is smoothing out power supplied to motors so that motors do not get maximum power applied from a standing start, reducing wear on the motors. It is likely that this saved us many parts, and if designing high torque drivetrains I would recommend this method.

So what is the point of all this? Really, it comes down to your playstyle, and what you want out of your robots. There are situations in which both speed and torque are important, and designing one that suits you, in my opinion, is one of the hardest challenges of the VEX competition. There were successful teams at World Cup that had high speed drives, and ones with high torque drives, so really it is up to you.

#7

Did you say linear filtering? Is that like incrementally increasing the power to the motors?

#8

I think speed is the key. Right now, I’m prototyping a 10 motor drivetrain (figure that one out ;)) geared 2:1 speed. So that has power and speed.

#9

I’m not positive, but I think linear filtering would be something you do in the code that limits the power output as a function of motor rpm, essentially reducing the stall torque of the motor and the total current (which will make the motor happier).

#10

We have the same thing! It is the way to go!

#11

Team 1492Z beat you to it. Their 10-drive-motor robot competed on Nov. 5 at the Redmond Jump Start event.

#12

I like the way you think! :wink:

We considered using all 12 of our motors on the drive train. We have found that 8 will probably have to do, maybe a little less. Oh well. We are not sure what kind of speed or power we are going to have yet, currently working on a lot of school stuff. Maybe we will have an update later, not sure.

  • Andrew
#13

You are only allowed to use 10 motors for VEX. Are you with another program?

#14

Linear filter is basically a system of slowing the rate that the power is applied to the motors, so that power cannot be applied to the motors so fast that they break.

A simple explanation follows:

Say you have a three element array, all containing zeros. The average of this array is zero, so no power is applied to the motors. The array is [0 0 0].

We assume that the driver is “binary” and that either no power, full forwards or full reverse is applied to the motors.

When the command to send power is received (from the controller), on the first cycle the first element in the array becomes a 1, and the average of the array is 1/3, so the power applied is 1/3 * coefficient. The array is [1 0 0]

On the next cycle, the first element becomes the second element, and the second becomes the third. The signal is still high, so the first element is still one, meaning that the array is now [1 1 0], and power to the motors is 2/3 * coefficient.

On the next cycle, the signal is still high, and the elements step one along in the array to make the array [1 1 1], and then the power would be 1 * coefficient.

When the signal goes low (no command to power the motors is received from the controller), the first element to be added to the array would be a 0. The array would become [0 1 1], then [0 0 1], then [0 0 0] as power scales to 0.

Using this method, you can see that it takes at least 3 cycles for full power to be sent to the motors, reducing wear. A 3 stage filter is not the only way to reduce motor wear, more stages would slow the time to get to full power, but keep in mind that driver would mean more “lag” as it takes time for the robot to accelerate.

Thanks to Paul for explaining this to us, it reduced motor wear greatly when using a large number of drive motors.

As for 8 / 10 /12 motor drive, I say just this: make sure all of the motors are correctly oriented otherwise one will get eaten with the others.

There are 12 motors in the college competition, 2 extra 269s.

#15

On linear filters (and other filters), I was just talking with BJC on this topic (and the topic of drive speeds).

We were questioning what curve we wanted for filtering (we have the code for a linear ramp filter, and a low-pass filter). Anyone have opinions with actual use to back it up?

Our implementation of a linear ramp filter is quite simple, we literally just:
-Take the delta between the last output and the requested power
-See if this is exceeding a predefined ramp rate
-Cap the delta on the output to the ramp rate constant.

Since code is iterative, the ramp rate is defined as counts per cycle, so having a decent idea of the loop time is good (we run it along with our backend state-machine and control code in a 25ms repeating timer). No arrays needed, we store only the current request and last output as signed chars.

The low-pass is a bit more complicated, but gives us what we think could be a nicer curve. We have yet to do significant testing.

#16

I have written code that does some type of ramping. it probably isn’t the best but it is basically 2 threads (one for each wheel) running that contains a for loop that increments the motor speed. I am willing to share my code if you are more interested. Any luck for me to get your code?

#17

I do everything in a single thread (at 25ms), since there is no reason to run multiple threads when everything needs the same time interval (this same thread also runs some drive math, the roller logic, and the state machine/PID for the arm.)

The code I am releasing from kbmath.c:


//This is just a snippet of kbmath.c, the rest is not relevant to this discussion
#include "API.h"
#include "kbmath.h"
//Ramp PWM values
signed char ramp_pwm(int input, int output, int ramp_step)
{
if (input >= (output + ramp_step)){
        output = output + ramp_step; }
else if (input <= ramp_step){  // extra case added to protect for underflow
        output = input;}
else if (input <= (output - ramp_step)){
        output = output - ramp_step; }
else {output = input;}

return (signed char)limit(output,127,-127);
}

//Limit function - Common use function for general limiting
int limit(int input, int upper_lim, int lower_lim)
{
        if (input < lower_lim){
                return lower_lim;
        }
        else if (input > upper_lim){
                return upper_lim;
        }
        else {
                return input;
        }
}

The relevant code from kbmath.h:


//Function Prototypes
signed char ramp_pwm(int input, int output, int ramp_step);
int limit(int input, int upper_lim, int lower_lim);

And, when I need to use it, I:


pwmLeft = ramp_pwm(jsLeft,pwmLeft,DT_RAMP_CONST);

where I have a signed char pwmLeft which stores the value to be output to the motor, and another signed char jsLeft which stores the input from the joystick (or elsewhere). DT_RAMP_CONST is #defined in the drivetrain header file.

#18

how do you score effectively with a robot that has 10 motors on the drive train? all you can do is push the objects in the corner goals and play D. unless you work a arm and manipulator on pneumatics :rolleyes:

#19

How about a transmission? (Just a guess…)

//Andrew

#20

We played with 1492Z as one of our partners that competition in the elimination matches, and no it doesn’t really score. On the other hand, that wasn’t really the point; it just needed to be really good at pushing other robots and getting in the way. That was a really interesting robot (I think it had 1HS and reg motor on each wheel of a holo drive, plus 2 more motors on 2 forward facing wheels in the center of the bot.)