200 rpm. You want speed to rush goals, but you want torque so you can’t be easily pushed around. Also, then you don’t have to deal with the extra work and friction of a gear train.
200rpm is definitely not bad, but I think a faster drive will become very advantageous for goal rushing. I’d go anywhere between the equivalent of 250 and 300 rpm on 4" wheels
yep I agree with this, I think 257 on 4in wheels will be a really popular speed (its 4.49 ft/s compared to 200 on 4in wheels, which is 3.49 ft/s)
What about a pneumatic transmission for the rush at the start? Is that worth doing?
why do that when updating velocity with code exists
when you do that you’re limiting the physical power output of the motor. it’s better to do it mechanically
it’s usually not worth the mechanical complexity to add a shifting transmission, but with the new freedom of no longer worrying about a pneumatic penalty it’s perfectly reasonable to give it a try, at least for the sake of making something cool. highly doubt it’ll be super common on the competitive level though
There is also an option to have a one time shifting transmission that starts in the high gear to accelerate the light robot, but then shifts into the torque mode to carry the goals, play defense, and climb the platform.
You don’t have to use expensive pneumatics for switching, as it could use some elastics to do that one time shift, triggered by another mechanism.
Similarly, you could start with 8 motors connected to the drivetrain and, after the initial auton rush, shift some of them in similar way to the secondary functions, such as mogo or ring lifts.
Finally, there is an option of a non standard X-drive that, compared to a regular X-drive could give your more speed in one direction and more torque in another.
Just be mindful that the more it is tilted, the more power will be lost in the speed direction due to the friction in the omni rollers. Less power means less torque and lower initial acceleration. If the robot is light enough you may still gain some fractional seconds advantage with the higher speed, but that is not guaranteed.
Agree. I think that a much more competitive thing to do would be to use pneumatics for things like mogo lifts, to save yourself the motors so you could do a 6 motor drive and gear it up to something like 360 rpm.
Yeah I don’t know when the iPhone version will update and allow the scoring to work? Did vex say when that will be?
The fact of the matter is that now people are usually rushing at this point to make something and the Vex Moby bot specializes in taking the platforms that hold the rings so I mean that is probably gonna be the most common besides clawbot.
We probably won’t see the day of competitive moby robots because they lack a lot of key aspects needed for this game. They can only hold 1 mobile goal, and can not do rings. They can’t lift mogos to the platform, which is a major problem against any other team that can. They are slow and only have 2 motor drives, so they will be pushed around a lot. While moby is way better than the clawbot, I don’t see them ever becoming a robot that could compete against most custom ones.
No but I am saying on a Qualifier level there will be plenty of beginners because around here they enter the high school level automatically, I did not want to build one but there is a rush for a qualifier so we will build that then we will build what I am sketching and looking into. It will be inspired by the Duel in Dublin 2077x 3303S Vs 2657A 58593A
hey guys im looking into programming a v5 robot with pro in c++ and was wondering what the line would be to get the color team you are on in competition so I can make the vision sensor focus on that color rather than writing multiple drive codes per color have it be hybrid
Just save your red program to slot 1 and your blue program to slot 2.
Is there no other way? I mean I guess it can be found using vision sensor.
There is no way to directly tell what side you are on. However, if you want to know, I would use a color sensor to Spence the color of the alliance mobile goal, use a jumper clip in one of the 3 wire ports, or had an absolute sensors with different positions for different colors.
You could also use a color sensor to detect the color of the platform (though why would you want to know what side of the field you are on? There the exact same on both sides)
I had thought while I was learning the cpp coding i had seen a statement that had read the competition controller but I must be wrong. I know it is the same on each side but was thinking if I only have legacy color sensors I could not always predict neutral towers to be kept in place by opponents so I could do more with my color but I need it to know what color to be looking for.