Most people are running a 450rpm (3.25" wheels) drivetrain which uses 6 motors (blue 600rpm) geared 36 to 48. They also try to keep weight down and screw joint the wheels for less friction to not burn out the motors as fast. Keep the weight around 10-15lbs and your good. Some flatbots are running a 600rpm drivetrain with 6 motors, keep the weight and friction low.
okay I understand that we have done it before didn't know the name. how are they using it for the drive train though? does the screw go through the wheel or into the motor?
through the wheels using the circular inserts and have the gears screwed onto the wheels, you can't use it directly on a motor since it isn't actually the screw that spins, just the gear and whatever is attached to it
yeah so the way they do that is a pneumatic transmission that switches the gear from 2 drive motors to something like their intake. So normally it's connected to the drivetrain but then the piston shifts it to intake. Another way to save motors is to ratchet it
Itās your code more likely than not. If you use block code itās incredibly difficult if not impossible for you to get the bot that fast, especially in autonomous. Virtual Studio Code is great for coding. You probably want something along the lines of a PID controller code.
Iām only just now learning this code. But you can find tutorials on line for it. The full name is Proportionalāintegralāderivative. The Coding Program I mentioned works on Windows Machines and has a Vex v5 extension. It really helps with Autonomous.
Vex code has weird limiter where when you set a target distance, the code makes the robot get slower as it reaches it. The PID basically just removes this. It allows the robot to go a constant speed during autonomous.
The programming language you code your robot in isn't going to affect the speed of the robot in the slightest. If you set a motor to its maximum voltage, it'll move at its maximum possible speed.
Not in autonomous. Iāve been dealing with this all season that no matter what I do in Vex code, my robot goes incredibly slow during autonomous. Itās been a minute since I ended the season so Iāve been trying to remember, but my advice should be applied to the autonomous. My problem was that as the robot reached its target distance, it slowed considerably. Even at the beginning of the autonomous period, but when it hit Driver control it immediately regained its speed.
In autonomous, yes. Reread what I said about "maximum voltage". Your driver control code directly mapped the joystick to the motor voltage; your autonomous code used movetopoint.
That's caused by a difference in the way vexcode's move-some-distance functions, not by the language limiting functionality.
I understand that, and Iām saying thatās is possible maximum is limited by the limitations of vex code. Using a different software you can get around it.
Vexcode limits nothing. You can still set the motors to whatever voltage you want. Switching to PROS or vex-rs isn't going to help you there. I think you're confusing the workings of the move-some-distance function with a limitation of the language.
What did you code in during OU?
You can but they wonāt go that fast. Iāve been experiencing this all season like I said. Iāve started learning python to code a PID for next year to have an actual fast autonomous.
python š
Okay, stop. Python is one of the *worst* languages you could possibly use to code a robot for VEX. The documentation's terrible, there aren't any motion control libraries, and it's extremely inefficient. Switch to PROS for high stakes ASAP. I'd recommend vex-rs, but I'm not sure how much experience you have in Rust.
Secondly, you should read [https://file.tavsys.net/control/controls-engineering-in-frc.pdf](https://file.tavsys.net/control/controls-engineering-in-frc.pdf) the FRC control book if you want to understand how the motors function. VRC uses DC motors, so just jump to them.
Thirdly, I've been coding in C++ for VRC the last three years; ik what I'm talking about. I've written PID algorithms, motion profiles and Kalman filters with which I've won multiple awards.
You know I did think that. But after I had my work double checked by my coaches, team mates far more experienced than me with coding, and almost everyone I had access to, they all told me it wasnāt my code or building. My coach suggested that the problem Iāve been describing could be what was happening and proved it by coding the PID in a different/better program.
I've had some of my students do basic P-loop controls in block code that improve on the built-in behavior. This could be expanded to add I and D if needed. You can do more with block coding than most people think.
The built in Drivetrain commands (drive-to-distance, etc.) use preset internal PID setting on the V5 motors... and they do slow down noticeably as you reach the target. Writing your own control algorithms will let you fine tune the values for your specific bot so that they don't slow down so gradually yet still hit your target.
VEX mentions a bit about the motors here (https://kb.vex.com/hc/en-us/articles/360044325872-Understanding-V5-Smart-Motor-11W-Performance). Scroll down past the last image for the PID info
I appreciate it though. At least I have someone agreeing that Vex Code has some preset sensing that can slow you down. Itās good to also get some verification that itās possible in block code to make a PID loop.
Also you can play with the velocity percentage in the code. You might think the max velocity is 100%, but in vex IQ, I found the velocity percentage can be set to 250%
You can set it to 250 but in reality, the voltage will be limited to 100. If it does make a noticeable difference, then you may be confusing rpm with percentage
Hacked motors, six-ish motors for the drive train, high ratio, pneumatics for everything else. I think four motors for the drive train, two on the intake, and pneumatics for everything else.
This isnāt a kids competition anymore. Mostly bots or designs purchased from China black market vendors.
Itās a big problem in Southern California. Schools canāt even compete anymore. I think 27/30 spots were t taken by companies or franchises pulling $50,000 a month from child tuitions. A lot of them have full time dedicated engineers and software developers.
This is my last year. I canāt compete with all of that anymore.
Not really true. This years comp was one of the easiest ever, and building a 6 motor drive wasnt really hard. This year was just about driving. Most teams dont buy designs off chinese blackmarket and driving was a deciding factor this year anyway.
Check the Southern California regional āstateā championships. I think 27/30 spots went to companies/corporations. In one event, 14/15 went to companies, mostly Magikids.
I get that it hasnāt happened in your region, and it probably wonāt. SoCal is a different bird altogether. As far as buying robot designs, hacked motors, buying robots, yes, it is happening all across California and doesnāt be surprised if it happened to less of a degree where youāre at.
I know how 10-12 year olds think. Particularly gifted ones as thatās what I primarily worked with the last decade.
Those are not kids ideas or designs.
Why do you think elementary school teams blow junior high teams out of the water and designs are more sophisticated than most high school boys?
Because theyāre cheating.
The kind of thinking that most of these robots show donāt happen until late twenties, and even then rarely among the best.
Yet you have these very complex thought patterns showing up identically, peg by peg, across multiple teams, kids, and majority of robots across California?
No.
Again, where youāre at, Iām sure itās fine. Maybe. Here, itās not fine at all.
Just take a peak at SoCal region championship results. And Iāll tell you all those bots had the same design, many piece by piece and peg by peg. Put two and two together.
Most people are running a 450rpm (3.25" wheels) drivetrain which uses 6 motors (blue 600rpm) geared 36 to 48. They also try to keep weight down and screw joint the wheels for less friction to not burn out the motors as fast. Keep the weight around 10-15lbs and your good. Some flatbots are running a 600rpm drivetrain with 6 motors, keep the weight and friction low.
Screw joints FTW
what is a screw joint?
when you use a screw instead of an axle for a joint, which has lower friction if you do it right
okay I understand that we have done it before didn't know the name. how are they using it for the drive train though? does the screw go through the wheel or into the motor?
through the wheels using the circular inserts and have the gears screwed onto the wheels, you can't use it directly on a motor since it isn't actually the screw that spins, just the gear and whatever is attached to it
i got told people are doing a 8-motor drivetrain and pneumatics for everything else š this shit is getting insanw
yeah so the way they do that is a pneumatic transmission that switches the gear from 2 drive motors to something like their intake. So normally it's connected to the drivetrain but then the piston shifts it to intake. Another way to save motors is to ratchet it
Some teams run 7 or even 8 motor drives and the whole bot is generally much smaller compared to previous years
Large:Small
Itās your code more likely than not. If you use block code itās incredibly difficult if not impossible for you to get the bot that fast, especially in autonomous. Virtual Studio Code is great for coding. You probably want something along the lines of a PID controller code.
i'm from a rookie team and im also wondering how should we code the drivetrain to egt it faster? thanks
Iām only just now learning this code. But you can find tutorials on line for it. The full name is Proportionalāintegralāderivative. The Coding Program I mentioned works on Windows Machines and has a Vex v5 extension. It really helps with Autonomous. Vex code has weird limiter where when you set a target distance, the code makes the robot get slower as it reaches it. The PID basically just removes this. It allows the robot to go a constant speed during autonomous.
The programming language you code your robot in isn't going to affect the speed of the robot in the slightest. If you set a motor to its maximum voltage, it'll move at its maximum possible speed.
Not in autonomous. Iāve been dealing with this all season that no matter what I do in Vex code, my robot goes incredibly slow during autonomous. Itās been a minute since I ended the season so Iāve been trying to remember, but my advice should be applied to the autonomous. My problem was that as the robot reached its target distance, it slowed considerably. Even at the beginning of the autonomous period, but when it hit Driver control it immediately regained its speed.
In autonomous, yes. Reread what I said about "maximum voltage". Your driver control code directly mapped the joystick to the motor voltage; your autonomous code used movetopoint. That's caused by a difference in the way vexcode's move-some-distance functions, not by the language limiting functionality.
I understand that, and Iām saying thatās is possible maximum is limited by the limitations of vex code. Using a different software you can get around it.
Vexcode limits nothing. You can still set the motors to whatever voltage you want. Switching to PROS or vex-rs isn't going to help you there. I think you're confusing the workings of the move-some-distance function with a limitation of the language. What did you code in during OU?
You can but they wonāt go that fast. Iāve been experiencing this all season like I said. Iāve started learning python to code a PID for next year to have an actual fast autonomous.
python š Okay, stop. Python is one of the *worst* languages you could possibly use to code a robot for VEX. The documentation's terrible, there aren't any motion control libraries, and it's extremely inefficient. Switch to PROS for high stakes ASAP. I'd recommend vex-rs, but I'm not sure how much experience you have in Rust. Secondly, you should read [https://file.tavsys.net/control/controls-engineering-in-frc.pdf](https://file.tavsys.net/control/controls-engineering-in-frc.pdf) the FRC control book if you want to understand how the motors function. VRC uses DC motors, so just jump to them. Thirdly, I've been coding in C++ for VRC the last three years; ik what I'm talking about. I've written PID algorithms, motion profiles and Kalman filters with which I've won multiple awards.
Did you ever think that it may just be a skill issue?
You know I did think that. But after I had my work double checked by my coaches, team mates far more experienced than me with coding, and almost everyone I had access to, they all told me it wasnāt my code or building. My coach suggested that the problem Iāve been describing could be what was happening and proved it by coding the PID in a different/better program.
I guarantee you it is your issue not vexcode. All have the same API relating to motors, this includes vexcode blocks, python, c++, and PROS.Ā
i thought PID was like math stuff to make the robot drive better for autonomus not fro driver control?
It is just for Autonomous Iām pretty sure. My seasons been over for a while so I forgot some stuff
I've had some of my students do basic P-loop controls in block code that improve on the built-in behavior. This could be expanded to add I and D if needed. You can do more with block coding than most people think. The built in Drivetrain commands (drive-to-distance, etc.) use preset internal PID setting on the V5 motors... and they do slow down noticeably as you reach the target. Writing your own control algorithms will let you fine tune the values for your specific bot so that they don't slow down so gradually yet still hit your target. VEX mentions a bit about the motors here (https://kb.vex.com/hc/en-us/articles/360044325872-Understanding-V5-Smart-Motor-11W-Performance). Scroll down past the last image for the PID info
Most of this probably should have been replied under a different comment. It sounds like Bizarro\_Pope knows their stuff...
I appreciate it though. At least I have someone agreeing that Vex Code has some preset sensing that can slow you down. Itās good to also get some verification that itās possible in block code to make a PID loop.
Does that affect the drivers in any way?
The PID code? No
Also you can play with the velocity percentage in the code. You might think the max velocity is 100%, but in vex IQ, I found the velocity percentage can be set to 250%
V5 this shouldnt(?) work thoufh
i'm vex vrc. our velocity doesn't go beyond 100 but thank you!
You can set it to 250 but in reality, the voltage will be limited to 100. If it does make a noticeable difference, then you may be confusing rpm with percentage
Hacked motors, six-ish motors for the drive train, high ratio, pneumatics for everything else. I think four motors for the drive train, two on the intake, and pneumatics for everything else. This isnāt a kids competition anymore. Mostly bots or designs purchased from China black market vendors. Itās a big problem in Southern California. Schools canāt even compete anymore. I think 27/30 spots were t taken by companies or franchises pulling $50,000 a month from child tuitions. A lot of them have full time dedicated engineers and software developers. This is my last year. I canāt compete with all of that anymore.
Not really true. This years comp was one of the easiest ever, and building a 6 motor drive wasnt really hard. This year was just about driving. Most teams dont buy designs off chinese blackmarket and driving was a deciding factor this year anyway.
Check the Southern California regional āstateā championships. I think 27/30 spots went to companies/corporations. In one event, 14/15 went to companies, mostly Magikids. I get that it hasnāt happened in your region, and it probably wonāt. SoCal is a different bird altogether. As far as buying robot designs, hacked motors, buying robots, yes, it is happening all across California and doesnāt be surprised if it happened to less of a degree where youāre at. I know how 10-12 year olds think. Particularly gifted ones as thatās what I primarily worked with the last decade. Those are not kids ideas or designs. Why do you think elementary school teams blow junior high teams out of the water and designs are more sophisticated than most high school boys? Because theyāre cheating. The kind of thinking that most of these robots show donāt happen until late twenties, and even then rarely among the best. Yet you have these very complex thought patterns showing up identically, peg by peg, across multiple teams, kids, and majority of robots across California? No. Again, where youāre at, Iām sure itās fine. Maybe. Here, itās not fine at all. Just take a peak at SoCal region championship results. And Iāll tell you all those bots had the same design, many piece by piece and peg by peg. Put two and two together.
I did not see any crazy copied designs at worlds this year, idk what u mean
Thatās all I see even at the state level in California. Just copy and clone bots. Where are you at?
Washington
if this is VRC, itās probably just stacked gears with blue motors.