Robot Communication Lost for odd reason

[engbrech]

Have done the sanity check a few times. Can go back and forth between deploying and run on boot repeatedly and the problems comes and goes with that. Seems like a coding issue but a baffling one. I don't have a clue where to start on how the code might be executing differently in the two cases. But obviously I ought to look at the catapault code as a starter.

As for the voltage drop. Seems like that might be A problem but not necessarily THE problem. The drive (four mecanum wheels with a CIM each on 8.65:1) does not operate at the same time as the catapult so it isn't that the two combine for a large voltage drop.

Tap test causes no problems.

[thatnameistaken]

If you'd like another person to check the code, I'm decently experienced in LabVIEW and am willing to give it a look.

[rich2202]

If your RoboRio wiring was wrong, then check your Radio wiring. It should be plugged in to the 12v2A socket, and nothing else on the other 12v2A connection.

If launching the catapult causes the robot to crash, then that is where I would start to look for code problems.

If it works when deployed, but not when rebooting, then look for:
1) access to devices that may not be there.
2) access to devices that may not have yet been initialized.
3) access to variables/network tables/etc that may not yet been initialized.

What sometimes causes the "works when deployed, but not when rebooting" (or some other similar type combination) is that you are referencing a variable with an undefined value. Sometimes you are lucky, and sometimes you are not. On reboot, the memory addresses are usually in a default state that doesn't seem to work for you. On Redeploy, the deploy process may leave memory in a state that just happens to work for you.

Something as simple as a while loop conditioned on a new variable that is not first used until inside the while loop.

[engbrech]

I decided a little sleep was important but no I am back and troubleshooting.

Just ran a test with the voltage on the catapult reduced by a factor of 10 in order to learn if this was a power or coding issue. The code still showed the "deploy works, boot on power does not" problem making me quite certain now this is a coding issue.

I have a good bit of Labview coding experience so I'm going to spend some time looking for the issues (which I didn't do before because I thought is was a power issue). I'll post again when I've either located the issue or post the code if I feel lost again.

Thanks for the suggestions.

[Alan Anderson]

Just a shot in the dark -- have you recently copied or moved your LabVIEW project to another folder? If so, you might not be sending the program you think you are to be run at startup. Make sure the FRC Robot Boot-up Deployment settings have the right Local destination directory. I can't think of a simple way for things to get messed up so you're building to one folder and "deploying" from another, but it might be possible.

[engbrech]

Well I seem to have alleviated the issue but I don't really understand the reason. The catapult was being launched in the periodic task loop in a Labview subVi. It's launched was controlled with a timed loop structure. Switching that loop to a regular while loop with a "wait until next 10ms" control seemed to fix the job.

No more crashing the code.

Think are most working now except a vision problem that may or may not be related. I'm going to post that separately as I think that is now a new question.


Thanks for the advice. It was a heck of a problem to troubleshoot and being pushed away from a power problem into a code problem was what I needed.

Cheers

[Mark McLeod]

Timed loop structures run at an elevated priority to regular code, so it was probably locking out normal operations.

[Alan Anderson]

Originally Posted by engbrech

Well I seem to have alleviated the issue but I don't really understand the reason. The catapult was being launched in the periodic task loop in a Labview subVi. It's launched was controlled with a timed loop structure. Switching that loop to a regular while loop with a "wait until next 10ms" control seemed to fix the job.

Maybe your catapult loop takes longer than 10 milliseconds to execute? A timed loop runs at a higher priority than normal, and would starve the rest of your program of CPU cycles.