Has anyone found a reasonable way to stop a shaft from spinning unless the motor is being powered? To explain, I’m looking for help in making a system where a motor turns a shaft but unless the motor is being powered, the shaft cannot be turned. A Passive lock would be preferable, but using one motor is also an option. Any ideas?
I don’t know what you want to use this for, but worm gears are pretty good at holding their position. They used to make some other ones that are more better for powering arms and such, but I couldn’t find them.
worm gear is the best option if you want the axle spinning in both directions and a ratchet is best for spinning in a single direction. the main downside of worm gears is that they produce a ton of torque and very little speed, so if you need the axle to spin fast, you will have to gear it up for speed, and when you do that you may create a bit of slop, which makes it hard to use.
Thanks for the example. I realize that my original question was ambiguous, so to explain further, I’m trying to compress the cubes with a plate that rotates around a shaft mounted to my lift. My problem is that when I try to compress it, the lift raises up rather than compressing the cube. I’m running low on motors and I’m trying to figure out how to stop the lift motors from backdriving.
Ah, I’ll stop you there. Compressing the cube intentionally is illegal.
This is only the case if it is a drive team member that is compressing the cube. The robot can compress the cube as much as it wants. Look at SG4 and SG5 in the game manual.
My apologies; I must have misread that. In that case, why do so?
They may be looking to push cubes under the fence.
Yes, while the cubes are ~12in initially, they easily compress down to about half of that, and the lowest point on the outside sections of the fence is 8" off the ground. So long as you can get past the pileup of stars around the fence, it should be relatively simple compared to lifting it over the fence.
Not so. Cube compression is long work. I can see it easily taking as much as ten seconds to compress, where as just picking is up and dumping of the fence can take much less time.
I didn’t say it would be fast, I just said it would be “simple” and “easy.” At this point I’m trying to give the robot the ability to score in every way possible. It can high hang, move stars, and soon cubes. Once it can do everything for our next competition, I’ll focus on making it more efficient by playing with other ideas and combining mechanisms to conserve motors and sensor ports.
Oh, so you only have a pushbot? Unless this competition is really soon, I would start out with something simple like a dumper. Even if you don’t get it at 100%, it will be better than almost all pushbots. Also, if you are planing to switch from the pushbot design later on, you should know it’s a lot easier to build an only O.K. robot then make it better than it is to build a really simple easy robot then completely change it later on.
No, while I appreciate the sage advice, you’ve obviously missed a few key details of the conversation. Not to stray too far off topic, but a push bot is a block with wheels and maybe some sort of linear puncher. Did I not mention that my robot had a lifting mechanism? Therefore my robot isn’t a push-bot. Also, any robot that can score reliably with all three methods is better than O.K. I’m hardly the most experienced guy on the forums, but I do know that “simple” and “easy” are hardly bad things, nor do they necessarily denote some failure to create a viable robot. Not all solutions must be complex. If I ever wish to switch from my “pushbot design,” I’ll be sure to ask your opinion.
Active brake. You can see in this video that when I move the motor, the motor is locked in position.
Quick rundown of what the code is doing:
When you drive the robot, it drives normally. But when you let go of the joysticks, it records the position of the wheel when you let go, and uses PID to stay there.
This isn’t exactly passive, but it does what you need it to. I use active brake on my arm to stop it from falling when holding multiple objects.
If you need any help with the code, feel free to PM me.
Thank you. I think I understand the concept behind the code, but if I do have problems I’ll ask.
I for one discourage pushbots; they are, by nature, very… rudimentary. However, what @jwwood13 is making doesn’t seem like a pushbot in the typical sense. Yes, it can hang. Yes, it can score. That gives room for misinterpretation. But a properly planned out robot such as this can go very far.
Also, if you are up for it, what do you think about using a pneumatic transmission for your lift? If you have a 10 motor drivetrain, a properly constructed robot could go VERY far. Maybe not to worlds, but we will see I suppose.
Okay great. You don’t have a pushbot. (BTW pushbots can be actually be good sometimes. In Skyrise there was a pushbot in my state that was mostly defensive and could stop there opponents from accessing almost all of their scoring objects by pushing them into a corner.) Sorry, I did not mean to sound patronizing in my last post. I did see that you can hang. I did not mean to equate your robot to a block with wheals. If that is your definition of pushbot, then no, you do not have one. I was simply trying to say that simplicity and ease, while great, should not be sought after at the cost of effectiveness. I just don’t think a robot that can only hang and push will be very effective this season. But, as I have said about other designs I disagree with, by all means, prove me wrong.
In one of your posts you said
because you said it could move stars and cubes, I thought that meant you could only move them under the fence, instead of lift them over it. Is this not the case? When you said “lifting mechanism” do you mean your hanging mechanism or that you have a mechanism that can lift scoring object over the fence? If the later is true, then please discount everything I have said in these last two posts. If it is the former, I believe you should rethink your design. But that’s just my opinion. I am not the the supreme authority when it comes to robotics. (Trust me, I sent in an application for the job and it was denied :))
Glad I could help
OK, so first I should apologize for my initial reaction to your comment about my robot being a push-bot. I reacted mostly because the term “push-bot” is, at least in my team/school, somewhat derogatory as it usually denotes a team without a functional design beyond a drive. While I do admit that my current design probably does fit into that category, I am reasonably confident that we will be able to do well as a supporting team if not a high-scoring robot. I appreciate your critiques and once again apologize for my earlier snark.