Add doc for roboRIO safety controls

[Gold856]

Fixes #2227. Slight adjustments from the original post for grammar, removal of non-ASCII characters, and use of markup.

[Daltz333]

Could you clarify the original post the article is from?

So, there's a couple of issues I have with the content as-is that prevents me from merging this in it's current form.

1. It does not read cleanly. There are no transitory sentences and large amounts of the content in the list don't even relate to each other. I'm not sure what the list is even supposed to be besides an information dump.
2. The last paragraph on robot's disabling is also just kinda thrown in there.
3. It's not clear to me the "flow" of a robot control process. Really it's

• PWM vs CAN
• Netcomm monitoring for heartbeat
• Where does heartbeat come from
• How can I identify when a heartbeat is being sent
• What about when a heartbeat gets ignored (I believe this can happen in extremely high CPU% situations

This article should get rewritten to be more than an information dump, with a clear direction on what value we are trying to provide to the reader (how Netcomm and motor controller heartbeat work, and how to identify user failures).

[Gold856]

https://www.chiefdelphi.com/t/severe-100-packet-loss/428031/139?u=peter_johnson

[Daltz333]

Thanks. Peter's information is correct, but is not written in a way that makes sense to a reader just visiting that webpage. The article needs context and a value-purpose (what are we trying to solve) that guides language and direction.

[Gold856]

Like you said, this is a very large amount of information. I'm not even sure where to start with this. IMHO, this is just meant to be an informative article, something similar to A Technical Discussion on C++ Commands. I don't know if there's really any other purpose for it, except the last part about delayed disabling. Perhaps that could be extracted into a troubleshooting article, like avoiding running anything else other the DS, although that could just go into DS Best Practices.

[Daltz333]

A Technical Discussion on C++ Commands works because it has a purpose. To inform the reader of the design decision for Commandsv2 and the context behind those decisions. The context is what makes the article work and provides a lot of value.

That article provides context by identifying problems in the original command based, and possible solutions. It then iterates on how to make this a viable API for the consumer. It constantly reflects its context onto the reader, which is important to a well-written article. This article should ideally be written (this is just me throwing out a suggestion, but I'm totally open to other ideas) in a form like following.

• Introductory to Netcomm and how it disables your motors (high level, no specifics)
• Why does it disable your motors, why does safety matter?
• How does it work (maybe even a draw.io diagram of the process)
  • The existing bullet points should be expanded upon, let's avoid dumping info on the user and break it into parseable chunks.