Hi, I am kind of new to Vex as this is my second year. My team is wanting a sort of parking brake that makes our bot unable to be pushed/moved by opponents. I have a few ideas such as a ratchet and pawl mechanism, a different ratchet design, and a 1-way gear/clutch. Which idea would work the best? Also, I was thinking some sort of pneumatic brake might work too, but have no idea where to start with that. Any suggestions? I am open to any ideas and constructive criticism. Thanks, guys
I used a pneumatic brake last season, it worked by having some static gears mounted to little levers that could be pushed downwards into the drive gears, seizing up the whole drive. This worked very well and made the drive completely immovable forwards and backwards, and using traction middle wheels locked movement side to side. I had experimented with friction pad brakes earlier, but found they were much more difficult, took up more space, and were only partially effective.
I’m not sure that it’s worth it this season though, there aren’t many instances when being pushed forwards or backwards is a concern. Maybe when you are shooting into the goal, but you do this so many times in a match that it would require almost constant actuation of the brakes for pretty minimal benefits. Last year was different because being able to lock movement on the platform and during tug of war matches was really powerful.
Several parts to your question:
1 - can motors be actively engaged in resisting motion in park - yes - use brake type hold. However, there will be a lot of lost energy as motors always active.
2 - preventing motion - that will require both mass of robot and solid area resisting motion - not practical if you are trying to accomplish other tasks and not damaging field.
lots of others … but that’s up to your imagination…
what about when trying to spin the roller and when you get into pushing matches there? I can see something like this being useful for that to hold onto the roller without getting pushed by the opposing alliance to keep you position where you can roll it all you want
Thank you so much for your input. I will talk to my teammates about a brake not being as necessary this season. I’m glad your pneumatic brake worked out well last year, as it seems like a great design, especially for last season. Thanks again!
brakes in tipping point were really good because it let you never lose a tug of war while also not stressing out your drive motors. In this game, there is no real way for an opponent to pull you away from a roller, only push you sideways, which is solvable by traction wheels.
Yes, that is what we were going to use it for. My teammate said he watched a match where a team got every disc into the goal but still ended up losing due to expansion and rollers. So, we definitely want to have a good expansion, and protect our rollers. I will research more on traction wheels, and ways to prevent getting pushed.
Yes, I will take this into consideration. Thank you so much!
Every disc into the goal - 66*5=330 points
Every Tile 36*3=108
Every Roller = 40.
This is silly math, lets try something else. Here are some reasonable numbers
Your Team: No rollers, 4 tiles, 25 discs = 43+255= 137
Other Team: 4 Rollers, 30 tiles, 2 high discs, 6 low discs = 410+303+2*5+6 = 146
Low goal tiles don’t count for points so that max is 28*3=84.
for my robot, I have a button that just locks our drive motors
the code looks something like this:
but what if your code has an error and will not let you drive again after then you are kinda screwed for the rest of the match
I have not had that problem in a match yet, but it is always a good idea to test your code if you make changes.
With my current program, the motors only lock if I hold the button. I can still drive when the motors are set to lock, but turning is more difficult.
Note that this code sets the drive stopping to hold, so it would only affect the robot after you are not driving. I’ve seen teams use a brake function the whole match, and this would only be a little different then that. Also, errors don’t just appear, they are the result of a mistake, and one should test their code before implementing it in a match.