Really jittery driving


I’m putting $1 on the shifter on one side is defaulting to high gear and low on the other.

1 Like


I’ll take your dollar! When our tank drive gearboxes were in the wrong gears the robot drove in really nice circles. Our driver was talented enough that he could compensate and finish the match!



Sorry to say I’ll be taking that dollar we made sure that the transmissions are shifted the same way. We actually had to switch from low gear to high gear because how slow our robot was moving after limiting the current it draws. Currently we suspect it’s just the scrub factor of the wheels we have. Since our season has ended most of the students are taking a break and will work on the robot for an off season in June. Ill let you guys know what changes we made



Switching to high gear would likely exacerbate your observed issues.



Is your RSL going crazy when this happens? if so, your robot is browning out.

Otherwise, we fixed this by implementing a slew limiter, and setting the current limiters on our talons.



2 Interesting tidbits about a slew limiter - as an 8th year mentor and a 4th year CSA I hadn’t heard of that one yet. More to the point, I was surprised re-scanning this thread that there is no mention at all of setting a ramp-rate to your Talon(s) - it should accomplish the same effect without new components.

The previous point about high hear is also spot on, the best use of power would be to auto-shift into low whenever wheel speed is low then auto shift up after the wheels are turning. If this is done pragmatically then the drive team can focus on game-strategy…

I for one am still curious to hear back on earlier posts suggesting that there is a mechanical issue on one side of this robot - when spinning one side shouldn’t draw significantly more power than the other.

Also - some comments unrelated to the OP - the Neo/MAX combination can also present this same type of symptom with less obvious causes - I’ve seen a 6-motor drive do this while up on blocks because current-limiting actually seemed to cause motor-stalls while starting ( week-3, adding ramp-rates helped some and taking out current-limiting was still needed ) - and more recently I’ve seen no brownouts on forward backward but that from stationary to 100% spin would cause a stall, while going to 50%-70% spin was ok ( like the OP, with pneumatic tires ).



I am not sure how we should add a slew limiter to help with the jittery driving, we also have a ramp rate on 150 ms to reach max speed but we haven’t really played around with that value since we were going in and out of matches. We believe it could be because of the gear ratios we picked out for the 3 ball cim shifters, we got the same ones as last year which was used with 6 inch wheels so I don’t think its appropriate for 8 inch wheels.

As for current limiting, I am not sure if I did it right since I put the peak current and continuous current as same so it will always be the same.



Well re-reading back to your OP again, I don’t clearly see if its resolved that your 2 robots are performing the same or not. Does your practice-robot do this same thing when its tested on Carpet?

If yes, then I’d say your main challenge is how to reduce scrubbing load.

If not, then I’d go back to the question of why you seem to have a higher resistance/load on one side of your robot than the other.

On the ramp-rate topic - for the Neo/Max brushless purposes: this seem to help with some starting/stahling issues - However for a burshed-talon case like this: .setCloseLoopRampRate() and/or .setVoltageRampRate() won’t fix a situation where motors are fighting too large a load, it just slows down the acceleration to smooth out behavior ( a simplified motion-profile ).



Best example of this probably being 0-fps with both sides in high gear rather than low gear.



Auto-shifting is often far better in theory than in practice. The momentary dip when you shift between gears, combined with the accelerated wear of constantly shifting on the fly, offsets any real performance advantage from shifting during acceleration.

A shifting gearbox in FRC isn’t being used in the same way or for the same reason as driving a car. The dominant school of thought is to use high gear essentially all the time on offense, with low gear being reserved for pushing or precise situations. Some other teams use a faster low gear for near-goal maneuvers and save their high gear for full field sprints. In neither case is shifting from low to high used as an acceleration aid.



Hi there! Driver from team 5943 here.

Our robot had a very similar problem this year. At one of our competitions our robot started just randomly dying out on us (at both our competitions actually… we don’t have much luck with robot reliability…). One of the issues was an issue with our motor controllers. One main test you can do is to feel the motors. No need for fancy technology here, literally just feel all your motors. We did this and we realized that one side of our drive train was burning hot, while the other was cold. (Due to the way our drivetrain is, our motors naturally run in opposite directions, so one side actually should be warmer than the other. The problem was that one side felt like it was ready to catch fire it was so hot). This led us to check all our motor controllers and connections. We did find an issue here, one of our Anderson connectors had popped out. this was a fairly quick fix. We tested again, and had the same issue. It just turned out to be a completely dead motor controller for whatever reason. That was time number one.

The second time it happened was at our second competition. This time, we would try to turn and just either barely move or turn really unevenly. Our battery would spike majorly. Because of the way our breaker wire was routed, it rubbed against the edge of some tube aluminum, breaking open the rubber coating and causing a 140v short. I doubt this is the issue. (It sounds like it could be more of the first thing). Just check all your connections (especially ones in tight spaces) and just make sure you don’t have any shorts anywhere.

It also could simply be that the pneumatic tires cause too much friction. We have 8” pneumatic tires as well, but haven’t found it to be an issue.

I hope this helped! Feel free to PM me with any further questions.

-Kaitlyn, Team 5943




I was one of the volunteers at HVR that tried to help your team out with this issue. I’ll reiterate what I said to your team in the pits.

We reviewed your gear ratio and found that it was sufficient according to the low gear value you gave me (I checked it with JVN’s calculator).

I then proceeded to check for drop center and found that there was little to no drop center. My next suggestion was to replace the back wheels with omni wheels but unfortunately the teams at the event only had 6” omnis.

If I remember correctly, your team said that you practice on hard flooring not carpet. That would be the reason why the practice bot doesn’t have the same problem. Carpet has a higher CoF which increases your scrub.



Log files are tremendously useful here - if you could get the automatically collected driver station logs from your driver station computer a huge swath of issues could be ruled out.



I checked the logs too. Forgot to mention that. The logs didn’t show any brownouts which is why we started looking directly into the mechanical aspects instead.



There are other considerations - you can see breakers tripping in logs, see the relative amperage your drive train is pulling (indicator of issues with friction or gearing), you can see CPU issues that’d impact the processing of controller data, latency issues that could be indicative of a faulty or misplaced radio - the list goes on.



So in best times the logs help identify symptoms you didn’t know were there. Insufficient-drop is one that I think a CSA can find nearly once per year, esp between multiple events. In a real pinch at competitions, when wheel changes aren’t found, as stated earlier that address-label/duct-tape applications can get a robot through a few matches.

Also right now as some robots are heading heading into their 3rd or 4th events; start looking to rotate worn down middle-tires out to the corners.

@Kaitlynmm569, your 2 stories reminds me of a few less likely drive-failure causes I’ve also seen.

One was that rather than shorted wires, keep in mind that there are no laws of physics to actually prevent PWM signal wires from getting crossed between motors (notably when attempting things like Y-splitting).

On the mechanical side, nothing like long hours on week-0 to let something like excessively tight chain tension go unnoticed.

1 Like


We have implemented autoshifting as nominally described by @wlogeais for the past two seasons with no detected acceleration in drivetrain wear (Vex 3-MiniCIM Ball Shifters, 2.16x spread). We observed improvements in battery usage and cycle times with autoshifting vs nominally staying in one gear or the other. Mathematically the 2.16x spread shifts the drive motors from near free speed in low gear to near peak power output in high gear, resulting in wonderfully fast sprints with little or no ‘lugging’ to get going in high gear.



Also, the spring of the carpet reduces the effect of the drop center directly. The same drop/overinflated center amount will end up being more evenly distributed among the three axles on carpet.

1 Like


Have you guys tried running this on blocks? Listen for sound differences.

I’m kinda surprised the gut reaction here was to pull the whole gearbox apart, that’s not the right approach to this problem.

Can you feel a physical difference between the sides?

Are all motor controllers running properly?

Are all motors live?

Have you written a diagnostic to check each motor individually and see if they all spin?

If it’s in brake mode instead of coast, a motor could be resisting the others.

Are you still having this current issue when driving straight?

Can the robot drive straight from a pure “drive forward” command?

That’s the first step. Not ripping into it’s guts.



Would you please explain what exactly you mean by this.