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

[willishf]

I did find in testing that once you enter in autonomous mode you need to keep track of the time spent and return from the method after 15 seconds. I have a keepGoing() method that I put in all the loops and before the next step that forces a return if 15 seconds has expired.

If not, the joysticks are not sampled and the appropriate drive method called. We are doing Java but assume the program constructs are the same in labview or C++.

Just because the field switches from autonomous mode to telop mode does not impact the code you have running on your robot.

[Maxzillian]

Originally Posted by willishf

I did find in testing that once you enter in autonomous mode you need to keep track of the time spent and return from the method after 15 seconds. I have a keepGoing() method that I put in all the loops and before the next step that forces a return if 15 seconds has expired.

If not, the joysticks are not sampled and the appropriate drive method called. We are doing Java but assume the program constructs are the same in labview or C++.

Just because the field switches from autonomous mode to telop mode does not impact the code you have running on your robot.

We had talked about the possibility of the robot not going out of autonomous mode, but wouldn't that cause the User1 indicator to turn off? I'll admit that this assumption is not based off direct knowledge, but what I had been told by the mentor who is experienced with LabView and the cRIO.

[theprgramerdude]

Stuck with PWM output this year (absolutely no reason to switch to CAN -- everything that can be done with it can also be done by coding the Crio) and lost our camera. Everything runs so much smoother now.

[willishf]

Unless lab view does something special to understand the notion of autonomous vs telop I think it will simply do in a program loop or block of code what it is asked to do. If you spend 30 minutes in a loop adding up numbers no reason why the code would return/yield/interrupt that block of code because the mode changed on the field.

[Vikesrock]

Originally Posted by willishf

Unless lab view does something special to understand the notion of autonomous vs telop I think it will simply do in a program loop or block of code what it is asked to do. If you spend 30 minutes in a loop adding up numbers no reason why the code would return/yield/interrupt that block of code because the mode changed on the field.

The way the Labview framework is written you cannot get stuck in Autonomous mode. When the field changes over, your autonomous code is terminated whether you are in a loop or not. If you change any of the framework or put your auto code somewhere other than the Autonomous Independent VI, all bets are off. Also I'm not sure if this functionality will work or not if you are in a loop that never yields the processor (IE no loop delay).

This is not the same as the C++ and Java frameworks which have no such functionality (from what I've been told)

[Chexposito]

The only reason you should not be 100% all of the time is code or electronics, it's as simple as that. The only time we had problems with controls is when we had bad electronics, loose wires, or a discrepancy in the code

[artdutra04]

We are using serial CAN with all Black Jaguars (programmed in Java) and had no control problems (such as lag or lack of control) at the WPI Regional. There only instance our robot was "not responding" was when our drivers forgot to shift into low gear in a pushing match and tripped the Jaguars current protection for three seconds, but they only made that mistake once.

This may or may not be related to our stability with CAN, but early in the build season our programmers noticed a conflict between the camera and CAN code in Java, and they fixed the bug.

[davidalln]

Originally Posted by Chexposito

The only reason you should not be 100% all of the time is code or electronics, it's as simple as that. The only time we had problems with controls is when we had bad electronics, loose wires, or a discrepancy in the code

I agree the inconsistent CAN errors (such as ours) that people have gotten are a function of code. The problem is that they're near-impossible to reproduce in a controlled setting and its absolutely impossible to diagnose where the problem is occurring.

I highly suggest switching to PWMs if you're having this issue. The wiring sucks, but its worth it for consistent control if the robot.

[codedr]

The theoretical maximum transfer speed over wireless is 5 MB/s. The actual maximum is less, due to
packet and header overhead. The camera can easily saturate the link at that speed. When congestion
starts to drop packets, it makes the problem worse over tcp, as the lost packets have to be retransmitted.

1000 mbit / s = 100 MB / s
_100 mbit / s = _10 MB / s
__50 mbit / s = __5 MB / s

We did some experiments with the camera and the crio.

Ex.0 (wpi lib) receive images via http on crio and retransmit to DS via TCP.

This failed last year (2010) when we tried to run video. FIRST restricted all video to run over TCP.

Positives:
- ???
Negatives:
- data sent over TCP, lost packets are re-transmitted
- camera data saturates network link disabling robot communications
- crio tcp network stack backs up setting off hardware watchdog
- did not reach 20 fps, camera task never yields

Ex.1 receive images via http on crio and retransmit to DS via UDP.

This was our first idea this year (2011) to improve the situation. We got approximately 4 img/s.
One drawback to this experiment is that the crio task for receiving the images from the camera
and sending them to the DS is never idle, so it takes away available CPU cycles from controlling
the robot. We are not currently able to measure what performance other tasks impact the processor.

Positives: data sent over UDP, lost packets are not re-transmitted
Negatives: did not reach 20 fps, camera task never yields

Ex.1 receive images via http on the DS and display them at 20 fps.

Positives:
- 18 to 20 fps display on DS
- packets backup into camera not crio
- no hardware watchdog timeouts on crio
Negatives:
- data sent over TCP, lost packets are re-transmitted

[davidthefat]

Our flaw was overused, overheated motors without the proper gear ratio and not enough motors (we only used 2 CIMs).

[pfreivald]

We lost control a few times at FLR -- the robot would sit still with no coms for about one minute, and then kick back on. We're 99.99% positive it is the bridge rebooting, but we have yet to figure out why that is the case...

...It's got good location on the robot (up high, not surrounded by too much metal), and we double-triple-quadruple-quintuple-and-more checked the electrical connections.

It was intermittetent, frustrating, and cost us a match three times. :/

[pafwl]

We were in New Youk over the weekend and had 2 instances of comm problems. We are using C++, no CAN, 4 victors and 1 jaguar all PWM controlled, no camera.

The first time it happened in prelims. We were about 1:30 into the game and we were lining up to deploy but we just stopped. FTA said is was us. No power issues, no wire issues.

We tie wrapped the ethernet cable in to the bridge.

In Quarterfinals. we started autonomous. In our design the tower is pushed vertical by pistons. They started up then started down, then up, then down. The only way to get the towers down is an input from driver or operator (button 5 ). They were not near controls. Autonomous for the fisrt part goes forward for 4 seconds. We did not go as far as we always do. Looked to me like the CRIO was restarting the code.

Once in round we were good but again with about 30 sconds left we died. This time I was less than pleased. I made sure I got the FTA's attention. He came back to the pit and looked all over and found nothing.

My only issues may be the placement. We are moving the radio more to the open.

Another team that was in the semifinals had a similar experience.

Very frustrating...

[Alan Anderson]

At a pre-ship scrimmage, our robot would occasionally start spinning in circles or take off at high speed in reverse. This would happen with nobody touching the driver joysticks. The program was definitely using only those joysticks to control the drive motors. Some of the team believed it was a communication issue, but I couldn't see any evidence of that kind of problem.

It took us most of the day to track down a bug in our rate limiting code. It was intended to keep the robot from accelerating backwards quickly so a chain tensioner wouldn't be overstressed. The bug was being triggering whenever a joystick went just barely outside the deadband in reverse. We spent a few minutes puzzling over the code, first trying to figure out how it was broken, then trying to figure out how we had intended for it to work in the first place. Finally we just threw it out and rewrote what it should have been originally.

[willishf]

We also have pneumatics for lifting our fork lift and have seen that behavior multiple times where it simply retracts the forklift. Something is causing the code to go into the startup state. This has happened to us in practice in the shop so the problem could still be communication related where a drop in communication does the same thing as not feeding the watchdog.

Not sure if it is possible to monitor the communication from the cRIO to have it log anytime it goes into "safe" mode.

[ChrisH]

Originally Posted by willishf

We also have pneumatics for lifting our fork lift and have seen that behavior multiple times where it simply retracts the forklift. Something is causing the code to go into the startup state. This has happened to us in practice in the shop so the problem could still be communication related where a drop in communication does the same thing as not feeding the watchdog.

Not sure if it is possible to monitor the communication from the cRIO to have it log anytime it goes into "safe" mode.

If you are at an event get with the FTAA before your match and ask him to pay attention to your robot. He has a display and logs of the communication status between the field, the robot, and the driver station. He can also spot a big drop in battery voltage, which indicates other problems. The logs can be checked but it is easier to just catch stuff as it happens most of the time.