Problem with driving
 

Hey guys, we recently had a problem with driving on the field and only on the field. We tethered it and ran everything, it was fine driving. However on the field, the robot would just not move well. It jerks and does not respond to the controller. We also know it is not a bandwidth issue. Does anyone know a possible fix?

should I set setSafteyEnabled to false?

Re: Problem with driving
 

You should make sure that your radio is mounted away from metal parts of the robot and motors. Those can lead to bad reception and/or interference and cause you problems like you are currently experiencing.

Re: Problem with driving
 

Does this happen shortly after the transition from autonomous to teleop? Look at the driver station logs; what does the CPU usage jump to? It sounds like the same problem that jumps up on teams time to time - an infinite loop that your robot get stuck in that spikes CPU usage up to 100%. You won't be able to replicate it in the pits because you're running tethered, and it's pretty hard to lose packets that way.

Re: Problem with driving
 

The radio is mounted away from motors. I am running at around 43% cpu.

Re: Problem with driving
 

When I was helping you in your pit with your compressor code, I noticed the debug output from the cRIO said Robot drive not updated often enough. Since it did that right when the cRIO was enabled, and then stopped, I assumed that you had some initialization stuff happening that took time to complete. I didn't notice any output after that.

Is this happening while you are driving?

In your testing, are you driving on carpet? I noticed you were running 1 CIM through a CIMple box with 6in wheels. How far is your voltage dropping when you drive? If you use the Driver station log viewer app, you can see the cRIO log (including voltage) from your matches.

If you still believe it is a code problem, make absolutely sure your RobotDrive or motor controller objects are having their drive/set methods called every loop.

- Andrew

Re: Problem with driving
 

The voltage drops to about 9volts.
The robotdrive is in the execute method.
We didnt drive on the carpet, only on the practice field.

This happens to driving. I re-coded the drive a bit, to compensate a dual joystick controller for one of our drivers. I am hoping that is going to fix it as well as setting the setSafetyEnabled to false.

Re: Problem with driving
 

9 volts is dangerously low...we change our our batteries when we see it drop down to 11.2...

Re: Problem with driving
 

9 volts when "driving", 12.5 when not.

Re: Problem with driving
 

9 volts is still very low when driving.

Re: Problem with driving
 

Did you notice the jerking when driving straight or only when turning? I'm not a mechanical person, but it really looks like your gearboxes contribute to your issues.

Feel free to correct me if I'm wrong on this:
- 6 inch wheels
- 4.67:1 reduction in CIMple gearboxes
- 1 CIM per gearbox
- 1:1 chain linkage to wheels

For this configuration, JVN design calculator says you have a max speed of 24.11 ft/sec and a maximum pushing force of 60.26lbs.


Also remember that the WPILib Scheduler calls your execute() methods on one thread - if one starts blocking it will affect other commands.

Re: Problem with driving
 

from last year's logs, that seemed to be like a normal.

Re: Problem with driving
 

For reference, our bot this year has 6 CIMs on the drive through 6:1 VexPro gearboxes. We rarely dipped below 11 ( 10 minimum ) volts on a fresh battery driving on carpet.

Re: Problem with driving
 

We only use fresh 12.8ish Volt batteries once a match, we start to experience drive problems when the battery gets to 10.5ish volts standby. There could be many things making you experience the driving problems. By the way, what programming language do you guys use? Also, I know you said it wasn't bandwidth but, your problem sounds just like bandwidth. :rolleyes:

Re: Problem with driving
 

hmm, i wonder why it dips down so much. We use java, command base. I know its not a bandwidth problem because the trip time was not high at all.

Re: Problem with driving
 

It's dipping so low because you're simply stalling the motors when you even try to move.

Re: Problem with driving
 

In your driver station logs do you see a high trip time or a lot of missed packets?

In Q32 at SCH, we experienced bandwidth issues because too many people were pulling full or close-to-full quality camera feeds. The packet time skyrocketed, and the robot was hitting disable timeouts about every 3 seconds ( DS would blink No Robot Comms for 1/2 second then reconnect ).

If you don't see any of these symptoms, it really really seems like your just don't have enough torque.

EDIT: Ignore this, I just saw your post saying you had low trip time

Re: Problem with driving
 

Are you using Victors, Jaguars, or Talons on your drive motors? Jaguars will "brown out" at about 9 volts.

Re: Problem with driving
 

I agree with CalTran.

In 2011, we did the same thing with 8 inch wheels (traction in back, omni in front) but with a reduction between the gearbox and the wheels (chain). The robot barely had enough torque to turn. We ended up switching the CIMple boxes with Toughboxes since we were using a third CIM somewhere else that year.

If you have 2 CIMs or MiniCIMs to spare, you should really put them in those CIMple gearboxes. Unless you have a need for the CIMple box speed, you might be better off switching to the kit toughboxes. Even then, I would still put two CIMs in, otherwise you'll just get pushed around by everyone else.

Re: Problem with driving
 

I think we are going to change the drive train if our weight permits it. I will get back to you guys within a day or three. Thanks for all your help though. By Lenepe, we are going to be awesome.

Re: Problem with driving
 

During the regional, we had a similar issue where our robot would work in the pit area but would "lag" when we drove it on the field. At first we thought it was a cpu issue and then we made the wait loops a little longer (tenth of a second i believe). That did not get rid of the issue.
We started jerking the robot back and forth in the pit to see if we could reproduce the issue. The light on the jaguars were turning from solid yellow to flashing yellow. We traced the problem back to the cRIO. Specifically, our ethernet cable was zip tied really tight and it would lose communication everytime we jerked the robot. Simply creating some breathing room for the ethernet cable solved our issue. Hopefully your problem is easy to solve as ours.