Impact and Capability of Motor Brakes?

[Argon27]

Greetings!
We have been to two regionals and have seen several teams using brakes for balancing on the bridge. Most we've seen are done at a transmission level or use pneumatic cylinders to physically "poke" the wheels.

We have decided that we want to implement brakes on our robot for balancing purposes only.

We are weighing two options:

1. Pneumatic Brakes- A cylinder that mechanically stops the wheel (Still in R&D. Not my sub-team ).
2. Electrical Motor Brakes- Basically, we want to switch the polarity of the motor at a very low power up to x times per second to keep the wheels stationary.

We've considered the potential heat, power draws, and strain on the motors. We also know about coast/brake mode on the Jaguars. What we want to know is how many times per second the output of a Jag is capable of switching safely.

Does anybody have experience with this?

Thanks!

[Ether]

Originally Posted by Argon27

2. Electrical Motor Brakes- Basically, we want to switch the polarity of the motor at a very low power up to x times per second to keep the wheels stationary.

What led you to conclude that doing that would keep the wheels stationary?

[midway78224]

We had a auto balance button for our robot at lone star. It gave the drive motors 20 percent power and stuck to the bridge even at a angle. I didn't see anything go wrong with the motors or jaguars.

[Argon27]

Originally Posted by Ether

What led you to conclude that doing that would keep the wheels stationary?

It was an assumption. Any input is greatly appreciated .

Originally Posted by midway78224

We had a auto balance button for our robot at lone star. It gave the drive motors 20 percent power and stuck to the bridge even at a angle. I didn't see anything go wrong with the motors or jaguars.

Interesting. I'll toss that into the programming cave and see if they're hungry .

Thanks!

[EricH]

Originally Posted by Argon27

It was an assumption. Any input is greatly appreciated .

It might depend a lot on how fast you cycled the power, and whether the bridge was on an angle or not. If the bridge is at an angle, you need more power and less time on the down direction than the up direction.

Personally, I'd go with a pneumatic brake. If the bridge isn't balanced when the power cuts off, the power control brakes aren't going to work very well. OTOH, a properly plumbed pneumatic brake will stay exactly where it is supposed to be when the power to the solenoid is cut.

[RyanCahoon]

Originally Posted by Argon27

It was an assumption.

We were wondering what reasoning you have to back up / what reasoning led you to that assumption. The ability to metacognate can be quite helpful, both on the engineering design level and to communicate with others. While it's possible you picked something completely at random, I would hope otherwise.

Regarding brakes, you have the right idea that you want something that will impede movement. The best design will also likely continue to function after power the robot has been disabled, if nothing else because it's possible to get coop points even with a tilted bridge that way. More generally, if your mechanism doesn't require continual power draw, you will reduce "heat, power draws, and strain on the motors." This can be done with pneumatics, which are often the most straight forward in these situations, but a well-designed locking mechanism driven by a motor can have the same effect. Team 25 has done this in a couple of different games, I believe.


*this one solution out of a great many. think about other locking mechanisms you've seen. one that readily comes to mind for me is collapsible tables

[smistthegreat]

If you have the weight for it, mechanical brakes will work wonders. It seems like pneumatics are the most popular, but motor driven brakes are possible. On our bot, we literally have COTS bicycle brakes on our center wheels. The cable from the brakes get wound onto a drum driven by a window motor, so they breaks stay where they are when power is cut because window motors are difficult to backdrive. For your situation, I would recommend pneumatic brakes, if you can package them/afford the weight.

[Gigakaiser]

We use an encoder-based proportional loop (motor control) for our brake and it has worked perfectly for both bridge balancing and defense. If you have encoders on your drivetrain, I would reccomend trying this before implementing a mechanical brake.

[Argon27]

Okay. There was a miscommunication on my end. Oops.

We were planning on doing the pneumatic brakes anyways, and thanks to your opinions we are now strongly in favor of them.

We want the electric brakes in addition to the hard stop so our drivers have a little more flexibility while balancing.

Originally Posted by RyanCahoon

We were wondering what reasoning you have to back up / what reasoning led you to that assumption.

Ahh. I see. Our motors don't start moving until we apply at least 40% power, thus anything less than 40% effectively stalls them. We figured that alternating the polarity would remove a bias in either forward or backward direction if we applied power in one direction.

Originally Posted by Gigakaiser

If you have encoders on your drivetrain, I would reccomend trying this before implementing a mechanical brake.

We don't have encoders on the drivetrain. We did abandon our attempt at using the gyro to "auto-balance" because it was too slow. I'll consider adding some, I'll have to see how many GPIO's are open...

So does anybody have input on the switching capacity of the Jaguars, just for kicks ?

[Al Skierkiewicz]

Argon,
The electric brake that you mention is a very capable system that requires some feedback and fine tuning in software to work reliably. We have only used it once or twice as I remember. It also eats electricity when not done properly so it is possible to trip breakers. It took our software guys a lot of reading before they used it.

[Argon27]

Originally Posted by Al Skierkiewicz

Argon,
The electric brake that you mention is a very capable system that requires some feedback and fine tuning in software to work reliably. We have only used it once or twice as I remember. It also eats electricity when not done properly so it is possible to trip breakers. It took our software guys a lot of reading before they used it.

Awesome input! I'll keep that in mind. It seems it might not be possible for us to implement a safe,effective motor brake before CMPs.

Thank You

[RyanCahoon]

One easy thing to make sure of as well is that your Jaguars are in brake mode rather than coast. This won't keep your robot from rolling down the bridge if it's tilted, but it may help your robot from rolling around so much when the bridge is coming up to level. Basically it will resist uncommanded motor movement somewhat (especially short-duration disturbances), but not prevent it.

[Argon27]

Originally Posted by RyanCahoon

One easy thing to make sure of as well is that your Jaguars are in brake mode rather than coast. This won't keep your robot from rolling down the bridge if it's tilted, but it may help your robot from rolling around so much when the bridge is coming up to level. Basically it will resist uncommanded motor movement somewhat (especially short-duration disturbances), but not prevent it.

I talked to the drive team about this and they prefer it on coast.Now we are looking at switching to CAN in future years so we can change that on the fly. We also had some power problems if the drive motors short to brake while our flinger is on (powered by 3 BaneBots 550's) we blow some breakers and eventually lose communication. We fixed most of the problem when we had two of the flinger motors powered by Spikes by switching to Victors(which were out of our budget at the time), but we haven't tested the Jag brakes with our changes.

[slijin]

Originally Posted by Argon27

I talked to the drive team about this and they prefer it on coast. Now we are looking at switching to CAN in future years so we can change that on the fly.

If this is the only reason you're considering CAN, you may also want to look into configuring one of your GPIO pins to control this. This can be done by tying the signal line to the center pin; an OFF signal will bring you to break; an ON signal will set it to coast.

See Table 7, p6.

[Argon27]

Originally Posted by slijin

If this is the only reason you're considering CAN, you may also want to look into configuring one of your GPIO pins to control this. This can be done by tying the signal line to the center pin; an OFF signal will bring you to break; an ON signal will set it to coast.

See Table 7, p6.

Awesome idea! I can't believe we didn't think of that! Trying it out pronto.

(Also, we wanted CAN for other stuff too )