Common Issues and Solutions

[Daltz333]

Meant to compile a list of common issues and solutions related to building and deploying to the robot.

Please share

[Starlight220]

Meant to compile a list of common issues and solutions related to building and deploying to the robot.

Is this only about build/deploy or also about code problems?
Do CAN problems (i.e CAN Recieve Timeout) count?

[Daltz333]

I think code problems would also be acceptable. CAN is an icky situation as there is no CAN controller in the KOP

[Starlight220]

More with PCM/PDP issues, 99% of the times I encountered a CAN Recieve Timeout was because of PCM problems...

[Starlight220]

A troubleshooting section for simulation should also be made...

[Daltz333]

There is an issue with extending simulation docs already. I usually get CAN Receive Timeout with TalonSRXs when there is an issue with the wiring.

[Starlight220]

CAN is an icky situation as there is no CAN controller in the KOP

What motor controllers are in the KOP? And I think these docs should have troubleshooting for everything except maybe extreme vendor stuff. And if the blink codes for the TalonSRX, etc. were added, why shouldn't basic troubleshooting be added too?

[AustinShalit]

This past year the KOP motor controller was the Victor SPX. The reason why we do not include troubleshooting for vendor devices is because that was part of the arrangement we came to when we decided to split out vendor hardware from the library. We make exceptions for specific pieces of documentation. For example, the status light page is great because it is a single document that contains all of the status light codes.

[Starlight220]

This past year the KOP motor controller was the Victor SPX

And the VictorSPX isn't CAN?
I understand the decision that troubleshooting vendor products should not be in the main docs, basic CAN troubleshooting should be in the main docs as that is the direction FRC is going in, and it applies to products of most vendors and KOP equipment (PCM,PDP), if the latter isn't a reason itself.

[Daltz333]

To be clear. We can include CAN devices. However, if we do anything with vendors, we have to mention them all.

[Starlight220]

Would we want a separate troubleshooting file for each "topic", or a single file with sections?

[Daltz333]

I was thinking a section for each topic would be cleaner. It already exists in some topics. In specific, this issue relates to creating a FAQ of common deployment issues (network connection, null pointer exception, etc)

[Starlight220]

Where would this troubleshooting file be?

[Daltz333]

And that is the hard question. It'd likely be somewhere in basic Programming

[jasondaming]

I am starting a list of things that should go on here will update as more things come in:

• No WPILib Install
• CAN Recieve Timeout-Hardware Disconnected
• CAN Recieve Timeout-PCM? Is this a location thing where it get noise from other systems?
• CTRE Firmware not up to date
• Motor Controller set up in a loop

[Starlight220]

Maybe search for keywords like "bug", "problem" etc in Chief Delphi? There seem to be people there that are very skilled in finding weird problems and bugs.
Also, look over support issues in allwpilib, frc-docs, and GradleRIO - multiple common problems have been reported there too.
I can help with some fixes, mostly concerning GradleRIO.

[AustinShalit]

To prevent this from becoming a huge PR, maybe we can create a page with one or two things and then folks can PR additions as we see fit?

[Daltz333]

Should we turn Known-Issues into this type of thing? I feel like permanent known issues should fall under this.

[jasondaming]

I don't mind combining them. Would this be in a FAQ format?

[AustinShalit]

I'd be worried that this document would get really long if we combine them. There is a difference between known issues that we intend to fix at some point and issues that users run into but there is nothing actionable we (WPILib) can do.

[jasondaming]

I don't have a strong preference about combining I agree that separate does make some sense. Maybe they link to each other?

For this issue however do we want to structure it as a FAQ or just like a bulleted list of common problems people have?

I assume this goes under basic programming? That section is really becoming a catch all but I think there is another issue to address that.

[AustinShalit]

@jasondaming What do you think (FAQ vs list)? And I think basic programming is fine for now until we figure out a long term solution.

[jasondaming]

I think that a FAQ format is nice in that it many times is better at capturing the common things people would search for that just having an answer might not.

[Starlight220]

Agree with that, many times it isn't clear what the problem is. FAQ format might help with that.

I think that issues should have a link to the gh issue tracking that problem, so teams can easily check the status of the problem.