Diagnosing Belt Skip Under Load

[Monochron]

Our belt driven intake arms are currently experiencing a lot of skipping (ratcheting) when accelerating and decelerating. Our arm pivots on a shaft that stretches the front of our robot and is driven by two Bag motors + gearboxes. A 18 tooth pulley from the gearboxes drive a 36 tooth pulley on the shaft/arm. The full arm can be seen in the video below.

What seems to be happening is that when the arm drives to drive the gearbox, even when unpowered, it often skips the belt on the smaller pulley. So when we are powering the arm, it skips when trying to stop because the momentum of the arm is trying to drive the small pulley.

The tension of the belts seems reasonable (one belt is slightly tighter than our KOP drivetrain belts, and the other is slightly less tight [resulting from fab inconsistencies]), though adding tensioners is possible. As best as I can tell our alignment from pulley to pulley is fine.

Can anyone comment on possible causes or suggest ways to fix this? We expected the belts to stop and stall the motors before skipping. Right now this is making PID control of the arm pretty much impossible, making it very very difficult to accurately control it and intake balls. About a week ago we made a video of the problem to ask a couple of friends, you can watch that video here.

Any advice is greatly appreciated.

[MaGiC_PiKaChU]

we also use a belt to actuate our arm, but we use a different technique.
you can see the belt in action here My guess would be, like you mentioned, that your arm gets momentum and your motor stops too fast. We have a similar reaction when we cross the rock wall, the arm wants to go forward on the landing, but the PID keeps it in place, making the belt skip sometimes when the shock is too hard. Putting more tension in the belt seems to make it better

[Owen Busler]

You could try slowing down the rotation of the intake. It seams to be moving pretty fast. It also appears as if the belt skips when you suddenly stop so if you were so ramp down the speed before you stop that may help.

[Mike Marandola]

Maybe the shafts holding the small pulleys are deflecting. What kind of belts/pulleys are you using?

[Joey Milia]

The problem is definitely at the small pulley. It's not simply supported so I wouldn't be surprised if the position of the pulley flexes a bit under high acceleration, not much you can do about that though. I'm assuming you're using the VexPro htd belt.

Things that would help:
1. Switch to 24t pulley. Would slow you down a bit but probably not super noticeable, you're pretty fast already.
2. Switch to GT2 or GT3 belt from sdpsi.
(Edit: scratch that one. GT series are better with power but HTD might be better with shock loads due to deeper profile. Don't have personal experience on that. Jury is out)
3. Limit your acceleration in software. Even a small ramp will help enormously. This is probably the best option as you don't need to buy anything else and will probably make the biggest difference.

Higher tension would probably help with the skipping, but may not be the best solution (depending on how tight things are already)

[BernieSolo]

Originally Posted by Joey Milia

3. Limit your acceleration in software. Even a small ramp will help enormously. This is probably the best option as you don't need to buy anything else and will probably make the biggest difference.

THIS IS A GREAT IDEA! Do you have a link to where we can find information on how to limit acceleration using LabVIEW?

Thank you.

[gpetilli]

Originally Posted by BernieSolo

THIS IS A GREAT IDEA! Do you have a link to where we can find information on how to limit acceleration using LabVIEW?

Thank you.

The simplest (assuming you are using CAN) is to use the new motion profiling built into the SRX. Either way, you should read the CTR documentation to understand what motion profiling is and what it is trying to do.

Last year we did motion profiling to keep from dumping stacks of crates. We used a spreadsheet called MotionProfile_Capiloli.xlsx (from VEX) as a model. Basically, we apply a voltage ramp limit and then an averaging filter to the set point we send to the speed controller. PM me if you cant find the xlsx online or if you want more info. We code in Java.

[Kevin Sevcik]

If the belt is ratcheting under load, then software solutions will only help you until your first rock wall, moat, or rampart crossing. Then you'll get the shock loading from physics instead of your PID, and you can't reprogram physics.

We've had this problem on drivetrain belts using the Vex plastic bearing blocks when the students put the cam tensioner on the non-belt side of the block. Also on other systems where structure between the pulleys is questionable. What happens is the belt loads up and the tension pulls the two pulleys closer together. This both puts an upper limit on your effective tension, and it adds misalignment into the mix which makes ratcheting more likely. I've usually diagnosed this by simply squeezing the two sides of the belt together and observing the shafts and bits of structure. If you see something moving when you squeeze the belt together, that's your weak point that you have to lock down. Your structure looks pretty solid, but it's had to tell from a video of the thing whipping around like that. If you try this and decide you need to beef up your structure, I think your best option would be something like a 1x1 aluminum tube with vex end-mount bearing gussets directly between the two shafts.

The other option is that you're simply overloading the belt. They can only transmit so much tension before ratcheting or breaking after all. I'm going to disagree with everyone else here and declare that the small pulley is NOT your problem. Or at least not your only problem. You almost can't get more wrap around that pulley, after all. The problem is that both of your pulleys are too small. Bigger pulleys mean bigger lever arms, mean less tension in the belt to transmit the required torque. I'd go with gptelli's suggestion of switching to 36T->60T or something similar. You definitely want the 60 tooth pulley on the arm, since that's what really drives the loading of the system.

[cjl2625]

Originally Posted by gpetilli

The simplest (assuming you are using CAN) is to use the new motion profiling built into the SRX. Either way, you should read the CTR documentation to understand what motion profiling is and what it is trying to do.

Last year we did motion profiling to keep from dumping stacks of crates. We used a spreadsheet called MotionProfile_Capiloli.xlsx (from VEX) as a model. Basically, we apply a voltage ramp limit and then an averaging filter to the set point we send to the speed controller. PM me if you cant find the xlsx online or if you want more info. We code in Java.

You can also apply voltage ramping while avoiding the complexity of motion profiling. The SRX lets you supply a voltage ramp value right into the PID block. Though when the ramp is too shallow, it's easy to cause a lot of oscillation.

[glennword]

Also, if you want a quick and dirty fix, make sure the motor controllers for those motors are set to coast and not brake. This may or may not fix your porblem, but it only takes a few minutes to test it

[chapman1]

Agreed with all above who posit that there are not enough teeth in contact on your pinion (smaller pulley).

It's just asking too much of those few teeth. If you could get some slack in the belt and add an idler close to the pinion for more wrap, I think your problem would be solved

[Monochron]

If we decided to switch to #35 chain, how does a pinion sprocket of 15 teeth sound? We don't have a lot of room with the VersaPlanetary right next to the output, and are currently restricted by needing a hex shaft for the pinion, but 15 tooth sprockets are available.

As my mark was off for how many belt teeth would be needed, I wanted to get some opinions on an appropriate number before committing.

[holygrail]

We have almost the exact same setup and we were slipping belts too. We were able to fix it by doing a few things. We haven't slipped a tooth since.

1) We added a 3rd pulley. We needed more teeth in contact with those small 18 tooth pulleys
2) Added shaft support in the center of the driven shaft. It helps minimize any potential bending of the shaft which can change the tension.
3) Improved belt tensioning. We used a Turnbull from the hardware store and it worked great.

[Chris is me]

Originally Posted by Monochron

If we decided to switch to #35 chain, how does a pinion sprocket of 15 teeth sound? We don't have a lot of room with the VersaPlanetary right next to the output, and are currently restricted by needing a hex shaft for the pinion, but 15 tooth sprockets are available.

As my mark was off for how many belt teeth would be needed, I wanted to get some opinions on an appropriate number before committing.

My unqualified, gut opinion not based on any calculations - you should be fine. 35 chain is extremely strong and forgiving. Properly tensioned, it is quite hard to break 35 chain anywhere on an FRC robot. Much, much harder to size incorrectly than belts.

[Monochron]

Originally Posted by Chris is me

My unqualified, gut opinion not based on any calculations - you should be fine. 35 chain is extremely strong and forgiving. Properly tensioned, it is quite hard to break 35 chain anywhere on an FRC robot. Much, much harder to size incorrectly than belts.

I am actually more concerned about skipping chain than breaking it. Last year we had skipping problems as a result of overloading and it took us days to properly diagnose and fix it.