Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)
-   -   Robots not under driver control- does it happen- do you determine why? (http://www.chiefdelphi.com/forums/showthread.php?t=93488)

Alan Anderson 14-04-2011 14:01

Re: Robots not under driver control- does it happen- do you determine why?
 
Quote:

Originally Posted by boomergeek (Post 1052789)
I'm always debating with myself if these types of connectors are better with a light solder to hold the twisted wire or the greater mechanical flex of a tightly twisted wire. I'm fairly certain a poorly twisted wire is a bad choice.

We get great results with no specific twist on a freshly stripped wire of the proper length. I firmly believe that solder is an inferior choice for both the WAGO connectors and the screw-clamp style on the cRIO.

I saw three cRIOs with power problems so far this year. One had almost no exposed conductor on the common wire and the connector was biting down on insulation. A tug test didn't reveal the problem, but it was obvious from a close visual inspection. The other two both had wires that easily came free from the connector when pulled. It looked like they were of thicker gauge than the connector could handle well, and only a few strands made it into the slot while the rest of the wire just sort of bunched up at the opening.

Dave75 21-04-2011 22:11

Re: Robots not under driver control- does it happen- do you determine why?
 
Quote:

Originally Posted by Maxzillian (Post 1043848)
... we found that on some occasions the robot would stop rotating once the period ended, then after a brief pause would finish the command as teleop was starting.

This sounds a lot like an issue in the code where it does not handle all the various States the robot goes thru in the transition from Autonomous mode to Teleop mode.

In Robot Main, the call to the "Get Robot Competition Mode" VI yields 2 key outputs: Robot Mode (Autonomous Enabled, Teleop Enabled, etc), and Call Context (Init, Execute, Stop). The state transitions from Autonomous to Teleop look like this (they are listed as Robot Mode / Call Context):
  • Autonomous Enabled / Execute
  • Autonomous Enabled / Stop
  • Autonomous Disabled / Init
  • Autonomous Disabled / Execute
  • Autonomous Disabled / Stop
  • Teleop Disabled / Init
  • Teleop Disabled / Execute
  • Teleop Disabled / Stop
  • Teleop Enabled / Init
  • Teleop Enabled / Execute
Note: I don't know how many cycles of Autonomous Disabled & Teleop Disabled the code will see. Under FMS control, it depends upon how long a gap if any there is between Autonomous & Teleop. Perhaps one or the other may not even happen.

Here's what may be causing the problem you're seeing. In Autonomous Enabled / Execute, your code sends a command to a Jaguar to move. When the Autonomous period of the game ends, your robot becomes disabled. That starts the chain of state transitions above. So the next state your code sees is Autonomous Enabled / Stop. In that state, your robot is already disabled, so the Jaguars are receiving no signal - hence their motors stop.

For some period of time, the robot sits in Teleop Disabled / Execute. When the Teleop period starts and your robot is enabled, the code 1st sees a Teleop Disabled / Stop, and then Teleop Enabled / Init. During both those states, the robot is enabled. The Jaguars will attempt do whatever command they last heard. Hence the start of Teleop has your robot moving the way it was last told to move in Autonomous.

One way to fix this would be to send a Stop command to all the motors when the robot is Disabled. This is already being handled in the default code by the Disabled VI - but only for the 2 default Drive motors. You need to go in and add a Stop for all your motors there.

Ster 22-04-2011 00:22

Re: Robots not under driver control- does it happen- do you determine why?
 
We saw several instances of this at Smoky Mountain. Every case was eventually concluded to be a robot not exiting autonomous mode correctly, stopping their code at the end of autonomous, CAN errors, ethernet cable coming loose on the driver station, or intermittent power loss causing the cRIO or another key component to reboot.

Check your code by simulating a match on the driver station. If your autonomous functions properly in practice, it will execute on the field. Check all of your power connections on board and be sure that the main breaker is pushed in until it clicks. It is possible to close the breaker enough to allow power without it locking closed. Always check that the battery terminals and the primary lugs on the PD are tight. Sometimes the insulation covering them makes teams believe they are good when there is only intermittent contact. Lastly, I know that many of the driver stations develop issues with loose ethernet adaptors. If needed, use a small piece of duct tape or similar to temporarily hold the plug in just to be safe.


All times are GMT -5. The time now is 13:16.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi