![]() |
Re: Robots not under driver control- does it happen- do you determine why?
Quote:
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. |
Re: Robots not under driver control- does it happen- do you determine why?
Quote:
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):
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. |
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