diff --git a/source/docs/software/basic-programming/index.rst b/source/docs/software/basic-programming/index.rst index 56a8d48105..2fb75f462c 100644 --- a/source/docs/software/basic-programming/index.rst +++ b/source/docs/software/basic-programming/index.rst @@ -7,6 +7,4 @@ Basic Programming git-getting-started.rst cpp-units joystick - robot-preferences - using-test-mode - reading-stacktraces + robot-preferences \ No newline at end of file diff --git a/source/docs/software/driverstation/driver-station-log-viewer.rst b/source/docs/software/driverstation/driver-station-log-viewer.rst index 728f1743e2..0249561b62 100644 --- a/source/docs/software/driverstation/driver-station-log-viewer.rst +++ b/source/docs/software/driverstation/driver-station-log-viewer.rst @@ -82,7 +82,7 @@ When diagnosing robot issues, there is no substitute for thorough knowledge of t .. note:: Note that all log files shown in this section have been scaled to match length using the Match Length button and then scrolling to the beginning of the autonomous mode. Also, many of the logs do not contain battery voltage information, the platform used for log capture was not properly wired for reporting the battery voltage. -.. tip:: Some error messages that are found in the Log Viewer are show below and more are detailed in the :doc:`driver-station-errors-warnings` article. +.. tip:: Some error messages that are found in the Log Viewer are show below and more are detailed in the :doc:`docs/software/troubleshooting/driver-station-errors-warnings` article. "Normal" Log ~~~~~~~~~~~~ diff --git a/source/docs/software/driverstation/driver-station.rst b/source/docs/software/driverstation/driver-station.rst index e2769d450f..182ef4ce07 100644 --- a/source/docs/software/driverstation/driver-station.rst +++ b/source/docs/software/driverstation/driver-station.rst @@ -65,7 +65,7 @@ The Operations Tab is used to control the mode of the robot and provide addition - Teleoperated Mode causes the robot to run the code in the Teleoperated portion of the match. - Autonomous Mode causes the robot to run the code in the Autonomous portion of the match. - Practice Mode causes the robot to cycle through the same transitions as an FRC match after the Enable button is pressed (timing for practice mode can be found on the setup tab). - - :doc:`Test Mode ` is an additional mode where test code that doesn't run in a regular match can be tested. + - :doc:`Test Mode ` is an additional mode where test code that doesn't run in a regular match can be tested. 2. Enable/Disable - These controls enable and disable the robot. See also `Driver Station Key Shortcuts`_. 3. Elapsed Time - Indicates the amount of time the robot has been enabled. diff --git a/source/docs/software/driverstation/index.rst b/source/docs/software/driverstation/index.rst index 4590b170c3..cb4003323a 100644 --- a/source/docs/software/driverstation/index.rst +++ b/source/docs/software/driverstation/index.rst @@ -7,7 +7,6 @@ Driver Station driver-station driver-station-best-practices driver-station-log-viewer - driver-station-errors-warnings programming-radios-for-fms-offseason imaging-your-classmate manually-setting-the-driver-station-to-start-custom-dashboard diff --git a/source/docs/software/troubleshooting/can-bus.rst b/source/docs/software/troubleshooting/can-bus.rst new file mode 100644 index 0000000000..9cc6cb8730 --- /dev/null +++ b/source/docs/software/troubleshooting/can-bus.rst @@ -0,0 +1,10 @@ +Debugging CAN-Related Problems +============================== + +Usual symptoms + +wiring + +termination + + diff --git a/source/docs/software/troubleshooting/code-build.rst b/source/docs/software/troubleshooting/code-build.rst new file mode 100644 index 0000000000..6d5b88023a --- /dev/null +++ b/source/docs/software/troubleshooting/code-build.rst @@ -0,0 +1,40 @@ +Debugging Issues while Building Code +==================================== + +Common Symptoms +--------------- + + +gradlew is not recognized... +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``gradlew is not recognized as an internal or external command`` is a common error that can occur when the project or directory that you are currently in does not contain a ``gradlew`` file. This usually occurs when you open the wrong directory. + +.. image:: images/reading-stacktraces/bad-gradlew-project.png + :alt: Image containing that the left-hand VS Code sidebar does not contain gradlew + +In the above screenshot, you can see that the left-hand sidebar does not contain many files. At a minimum, VS Code needs a couple of files to properly build and deploy your project. + +- ``gradlew`` +- ``build.gradle`` +- ``gradlew.bat`` + +If you do not see any one of the above files in your project directory, then you have two possible causes. + +- A corrupt or bad project. +- You are in the wrong directory. + +Fixing gradlew is not recognized... +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``gradlew is not recognized...`` is a fairly easy problem to fix. First identify the problem source: + +**Are you in the wrong directory?** +- Verify that the project directory is the correct directory and open this. + +**Is your project missing essential files?** +- This issue is more complex to solve. The recommended solution is to :ref:`recreate your project ` and manually copy necessary code in. + + +Driving toward Root Cause +------------------------- \ No newline at end of file diff --git a/source/docs/software/troubleshooting/common-field-problems.rst b/source/docs/software/troubleshooting/common-field-problems.rst new file mode 100644 index 0000000000..5585abc9f4 --- /dev/null +++ b/source/docs/software/troubleshooting/common-field-problems.rst @@ -0,0 +1,52 @@ +Common Field Problems +===================== + +This article details some of the common problems that can plague your robot when it's on the field. It can be extremely frustrating and stressful when your robot breaks down. This article hopes to inform and instruct on what you can do to find the problem, and it's resolution. + +.. important:: Remember to never eliminate any possibility! It never hurts to double or even triple check that everything is working properly. + +Robot is stuttering and the RSL lights are dimming +-------------------------------------------------- + +Whenever your robot seems to give jerking motions and the RSL lights are dimming, this is usually a sign of :doc:`brownouts `. One of the first steps you can take to resolving a brownout is identify when it occurred and any notable correlating events. Did you go into a match with your battery too low? Are you drawing too much current somehow? Can you reproduce this in the pit? + +One of the most useful tools for identifying brownout causes is the :doc:`driver station log viewer `. + +.. image:: /docs/software/roborio-info/images/identifying-brownouts.png + +In the above image, you can see the brownout indicated by the highlighted orange line. The orange line represents dips (or lack of a straight line) in robot voltage. + +Joystick inputs seem to be dropping +----------------------------------- + +One of the characteristics of lost joystick inputs is when you press buttons or an axis and nothing happens! This can happen from a variety of reasons, so it's important to analyze which one is likely to your situation. + +.. todo:: looking at the driverstation log and identifying if lost joysticks is a code related .. error:: text + +.. important:: There is a current :ref:`known issue ` where I2C reads can take a long time or lock up the roboRIO. + +Let's begin by asking a question. Can you reliably reproduce this issue at home or in the pits? This step is critical and assumptions *must not* be made. + +Yes, I can +^^^^^^^^^^ + +This eliminates bandwidth or connectivity issues to the FMS. Some areas to explore are: + +- Are joysticks working properly? + - Sometimes the issue can be as simple as a flakey USB cable or joystick. + +- Is the computer running slow or sluggish? Try restarting + - High CPU or Disk Utilization can be indicators the Driver Station itself is sending inputs late. + +- Is the code doing any long computation or loops? (Misuse of `for` and `while` loops can be common problems) + - In most cases, the use of any loops in FRC robot code can be avoided except in rare circumstances. + +No, I cannot +^^^^^^^^^^^^ + +This is likely a bandwidth or IP configuration issue. Try setting your IP configurations to :ref:`DHCP ` or :ref:`Static `. Another potential problem could be excessive bandwidth utilization. Try :ref:`measuring your bandwidth utilization `. + +Unable to connect to your robot? +-------------------------------- + +See :ref:`docs/software/troubleshooting/networking:Usual Symptoms` \ No newline at end of file diff --git a/source/docs/software/driverstation/driver-station-errors-warnings.rst b/source/docs/software/troubleshooting/driver-station-errors-warnings.rst similarity index 100% rename from source/docs/software/driverstation/driver-station-errors-warnings.rst rename to source/docs/software/troubleshooting/driver-station-errors-warnings.rst diff --git a/source/docs/software/troubleshooting/gathering-information.rst b/source/docs/software/troubleshooting/gathering-information.rst new file mode 100644 index 0000000000..d0c6447d79 --- /dev/null +++ b/source/docs/software/troubleshooting/gathering-information.rst @@ -0,0 +1,112 @@ +Gathering Debug Information +=========================== + +During the cycle of troubleshooting, a key step is to gather data. A large amount of the behavior of a robot's control system is *hidden* from view, and requires special tools to observe. While not exhaustive, the following is a list of common tools that robot software developers should be familiar with. + +Driver Station +-------------- + +The National Instruments DriverStation is the first place to check when robot does not behave as expected. + +In particular, the :ref:`Diagnostics Tab ` and :ref:`Messages Tab ` frequently contain the minimum info needed to start driving toward root cause on a problem. + +Additionally, the :ref:`Log File Viewer ` for more info. + +Command Line Utilities +---------------------- + +The Windows command prompt has a number of useful tools for troubleshooting. + +The Windows command prompt may be accessed from the start menu. It is named :code:`cmd.exe`. The commands we describe here should be typed into the command prompt. + +Using `ping` +^^^^^^^^^^^^ + +:code:`ping` is a utility built into Windows which allows for a basic network connection check between two points. It confirms basic functionality of both the physical layer (wiring or wireless), and a small portion of software. + +It can be invoked by typing :code:`ping`, followed by a space, followed by the IP address to be checked, followed by Enter. For example, checking the IP address :code:`10.12.34.1`: + +.. code-block:: console + + C:\Users\YOUR_USER>ping 10.12.34.1 + + Pinging 10.12.34.1 with 32 bytes of data: + Reply from 10.12.34.1: bytes=32 time=3ms TTL=128 + Reply from 10.12.34.1: bytes=32 time=3ms TTL=128 + Reply from 10.12.34.1: bytes=32 time=3ms TTL=128 + Reply from 10.12.34.1: bytes=32 time=3ms TTL=128 + + Ping statistics for 10.12.34.1: + Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), + Approximate round trip times in milli-seconds: + Minimum = 3ms, Maximum = 3ms, Average = 3ms + +This shows four test "pings" being sent, and the device with IP address :code:`10.12.34.1` responding with a "Yup, I hear ya!" message within three milliseconds. + +If None of the pings are responded to, it would likely indicate some total failure which prevents communication - perhaps a cable is unplugged, or the device is turned off, or doesn't have the expected IP address. + +If only some of the packets come back, it would indicate a partial failure preventing some communication. Perhaps a cable is loose, the wifi network is being rate limited or interfered with. + +Using :code:`ipconfig` +^^^^^^^^^^^^^^^^^^^^^^ + +:code:`ipconfig` is a utility built into Windows which summarizes the configuration of the network interfaces on the device. It can help confirm your computer is actually attached to a robot network, and should be capable of communicating with robot components. + +It is invoked simply by typing :code:`ipconfig` and hitting Enter. + +Here is an example of running it on a computer with one wireless (wifi) network interface and one wired (ethernet) interface, but with neither connected. + +.. code-block:: console + + C:\Users\YOUR_USER>ipconfig + + Windows IP Configuration + + + Wireless LAN adapter Local Area Connection* 1: + + Media State . . . . . . . . . . . : Media disconnected + Connection-specific DNS Suffix . : + + Wireless LAN adapter Wi-Fi: + + Media State . . . . . . . . . . . : Media disconnected + Connection-specific DNS Suffix . : + +Here is another example with the wifi network properly connected to team 1234's robot over wifi: + +.. code-block:: console + + C:\Users\YOUR_USER>ipconfig + + Windows IP Configuration + + + Wireless LAN adapter Wi-Fi: + + Connection-specific DNS Suffix . : localdomain + Link-local IPv6 Address . . . . . : fe80::890d:bbae:d81c:d416%7 + IPv4 Address. . . . . . . . . . . : 10.12.34.210 + Subnet Mask . . . . . . . . . . . : 255.255.255.0 + Default Gateway . . . . . . . . . : 10.12.34.1 + + +Manufacturer-Specific Interfaces +-------------------------------- + +3rd party manufacturers support custom interfaces to help address problems that are specific to their hardware. These include: + + * `REV Robotics Hardware Client `__ + * `Cross the Road Electronics Pheonix Framework `__ + * `Playing with Fusion's Web-Based Configuration `__ + +REV Robotics, Cross the Road Electronics, and Playing with Fusion all supply additional utilities for configuring and troubleshooting their hardware. + + diff --git a/source/docs/software/basic-programming/images/reading-stacktraces/bad-gradlew-project.png b/source/docs/software/troubleshooting/images/reading-stacktraces/bad-gradlew-project.png similarity index 100% rename from source/docs/software/basic-programming/images/reading-stacktraces/bad-gradlew-project.png rename to source/docs/software/troubleshooting/images/reading-stacktraces/bad-gradlew-project.png diff --git a/source/docs/software/basic-programming/images/reading-stacktraces/cpp_div_zero_stacktrace.png b/source/docs/software/troubleshooting/images/reading-stacktraces/cpp_div_zero_stacktrace.png similarity index 100% rename from source/docs/software/basic-programming/images/reading-stacktraces/cpp_div_zero_stacktrace.png rename to source/docs/software/troubleshooting/images/reading-stacktraces/cpp_div_zero_stacktrace.png diff --git a/source/docs/software/basic-programming/images/reading-stacktraces/cpp_null_stacktrace.png b/source/docs/software/troubleshooting/images/reading-stacktraces/cpp_null_stacktrace.png similarity index 100% rename from source/docs/software/basic-programming/images/reading-stacktraces/cpp_null_stacktrace.png rename to source/docs/software/troubleshooting/images/reading-stacktraces/cpp_null_stacktrace.png diff --git a/source/docs/software/basic-programming/images/reading-stacktraces/cpp_vscode_dbg_tab.png b/source/docs/software/troubleshooting/images/reading-stacktraces/cpp_vscode_dbg_tab.png similarity index 100% rename from source/docs/software/basic-programming/images/reading-stacktraces/cpp_vscode_dbg_tab.png rename to source/docs/software/troubleshooting/images/reading-stacktraces/cpp_vscode_dbg_tab.png diff --git a/source/docs/software/troubleshooting/index.rst b/source/docs/software/troubleshooting/index.rst new file mode 100644 index 0000000000..570086e504 --- /dev/null +++ b/source/docs/software/troubleshooting/index.rst @@ -0,0 +1,16 @@ +Troubleshooting +=============== + +.. toctree:: + :maxdepth: 1 + + introduction.rst + gathering-information.rst + code-build.rst + driver-station-errors-warnings.rst + common-field-problems.rst + reading-stacktraces.rst + using-test-mode.rst + loop-overruns.rst + can-bus.rst + networking.rst diff --git a/source/docs/software/troubleshooting/introduction.rst b/source/docs/software/troubleshooting/introduction.rst new file mode 100644 index 0000000000..68471c6cb4 --- /dev/null +++ b/source/docs/software/troubleshooting/introduction.rst @@ -0,0 +1,83 @@ +Introduction to Troubleshooting +=============================== + +*Troubleshooting* is the art of identifying the causes of problems, and using the cause to iterate a better solution. + +Issues Will Happen +------------------ + +Every robot will experience problems. These can be frustrating! Rest assured, fixing these issues is something every team goes through in a season. + +This section of the docs is designed to help teams identify and fix common robot issues which have control-system root causes. While not an exhaustive list of all possible issues, the hope is to provide general guidance and specific examples to reduce the most common pain points. + +Symptom vs. Root Cause +---------------------- + +When troubleshooting, be sure to separate *Symptom* and *Root Cause*. + +The *Symptom* is the behavior you actually observe, which is not correct. For example, a robot which can only turn in place (and cannot drive straight) is a *symptom* a team might observe. + +The *Root Cause* is the incorrect software, electrical hookup, or mechanical fault which actually caused the symptom to occur. + +When troubleshooting effectively, a team will work backward from the observed symptom, to the root cause. Ideally, the root cause gets fixed, and in turn the symptom stops manifesting. + +Sometimes, resource constraints might make a team "patch over" a symptom without identifying or fixing root cause. Teams should tread cautiously here, as patches are prone to break or cause more issues later on. + +On Working Methodically +----------------------- + +Effective troubleshooting requires teams to work methodically. + +The Scientific Process, in Real-Time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The core of all troubleshooting strategies is the same as the scientific process. Namely: + + . Observe the world around you + . Propose a hypothesis + . Design and execute a test of that hypothesis + . Observe and interpret the results + . Repeat + +In the case of most FRC robot troubleshooting, the hypothesis will be relatively small. A valid hypothesis could simply be "If I add a `* -1` to line 354 of my code, it should fix the motor that's running backward". The experiment would then be to make the change, upload the code, and attempt to reproduce the backward motor issue. If the motor is now running the correct direction, it is reasonable to assume the hypothesis was correct, and no further action is needed. However, if the issue persists, one could assume the hypothesis was not entirely correct, and the process must be repeated with a new hypothesis. + +Change One Variable at a Time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When interpreting the results of an experiment, it is critical that the experiment has controlled for all but one variable. Having only one changing variable is what allows experiment results to be interpreted to a single root cause. + +If many variables change, and the problem goes away, you will not know which variable actually fixed the root cause. + +While it may be tempting to change a lot of things hoping one of them fixes the issue, this will likely lead to a lot of things changed unnecessarily. + +Undirected Guess and Check is Ineffective +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A naïve approach to troubleshooting will start by assuming *anything* could be the root cause, and pursue each option one by one. However, in a large and complex system (like a robot), the number of possibilities can be too large to effectively test each one, one by one. + +From this perspective, it is best to start by making a few assumptions about what root causes are *most likely*, and test those first. As you get more experience doing troubleshooting, you'll gain a better intuition for where to start looking for problems. + +However, keep in mind that these are *assumptions*. They're educated guesses as to where the problem *likely is not*, not exhaustive proof that a problem doesn't exist. Always be ready to go back and undo your assumptions if needed. + +Be Egoless +^^^^^^^^^^ + +When troubleshooting, emotions can often start flying, as it sometimes appears blame is being placed. People can get defensive when their component or their design is called into question. + +It's important to keep in mind that everyone is on the same team, working toward the same goal. Be careful to choose words and descriptions which describe and judge ideas, not people. Furthermore, try not to let your own ego and biases get in the way of considering possible faults in the systems you are responsible for. + +Single vs. Multiple Points of Failure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The most effective way to troubleshoot is to start by assuming that a *single point of failure* has triggered the symptom. For well designed, simple systems, this is usually the case. + +However, as systems get larger and more complex, it's very possible multiple failures might exist. While this should always be a *secondary* assumption, be careful not to ignore the fact a symptom may be caused by multiple, interacting failures. + +Practice, Practice, Practice +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Troubleshooting is a learned skill. While there are few concrete facts and figures to memorize, seeing examples of failures and their root causes over and over again is the best way to get better at isolating root causes from symptoms. + +One will often see more experienced mentors or students look at an issue and quickly state a root cause. And, often, they'll be correct. Rest assured, this ability isn't magical or genetic - it's learned. Folks who are good at troubleshooting will *still* go through all the steps and processes these docs describe. However, they draw from a broader set of exposure to recognize patterns faster, and eliminate unlikely possibilities. + +Be intentional about spending time practicing troubleshooting, and try not to worry if it takes longer than others. diff --git a/source/docs/software/troubleshooting/loop-overruns.rst b/source/docs/software/troubleshooting/loop-overruns.rst new file mode 100644 index 0000000000..c186607ef1 --- /dev/null +++ b/source/docs/software/troubleshooting/loop-overruns.rst @@ -0,0 +1,94 @@ +Mitigating Loop Overruns +======================== + +A *loop overrun* is a common occurrence when teams scale up their codebases. It occurs when a piece of code takes too long to execute, "starving" other code of the time it needs to run. + +Real-Time System +---------------- + +Our robots are *real-time systems*. Code must execute in a way that the time between reading inputs, performing calculations, and assigning outputs is bounded and deterministic. In doing so, the code establishes the relationship of how outputs change in response to inputs. + +When code runs too slowly, that input-output relationship is no longer maintained, causing complex and unexpected behaviors. + +Common Symptoms +--------------- + +One key symptom is seeing a message like this frequently in RIOLog: + +.. code-block:: text + + Warning 1 Loop time of 0.02s overrun + edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:359) + Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage(IterativeRobotBase.java:359): Loop time of 0.02s overrun + Warning 1 SmartDashboard.updateValues(): 0.000361s + disabledInit(): 0.000475s + robotPeriodic(): 0.310620s + LiveWindow.updateValues(): 0.202739s + Shuffleboard.update(): 0.000896s + disabledPeriodic(): 0.001021s + edu.wpi.first.wpilibj.Tracer.lambda$printEpochs$0(Tracer.java:63) + + +The the bigger the numbers after each step are, the more sever the loop overrun is. For example, the main problem here is that the :code:`robotPeriodic()` method took :code:`0.31062s` to complete. This is much larger than the 0.02s (20 ms) update rate the robot is supposed to be running at. + +In extreme cases, the robot may move in a "jerky" or uncontrollable manner, not responding promptly to inputs or sensor value changes. + + +Driving toward Root Cause +------------------------- + +A common first step is to simply inspect the codebase. Misuse of :code:`for` or :code:`while` loops can increase processing time very rapidly. Using :code:`.sleep()` methods or lots of :code:`print()` statements can do similar things. Less likely but also possible, a function which calls itself can act like a loop. + +If a simple code inspection does not work, execution time can be measured with a few built-in WPILib methods. + +:code:`Timer.getFPGATimestamp()` will return the current number of seconds since the RIO booted, to a high decimal precision. By reading the time before and after code executes and subtracting them, you can calculate how long a certain piece of code takes to execute. By doing this in many spots, you can start to identify which pieces of code take longer than others to run. + +WPILib also provides a `Tracer class `. By creating a Tracer and adding Epochs, you can generate nice reports of how long it takes to execute through certain pieces of code. + +.. tabs:: + .. group-tab:: Java + + .. code-block:: java + + import edu.wpi.first.wpilibj.Tracer; + + public class YourCode { + private Tracer t; + + public YourCode() { + t = new Tracer(); + } + + public void periodicUpdate() { + t.clearEpochs(); + + // Some code + + t.addEpoch("First Epoch"); + + // Some more code + + t.addEpoch("Another Epoch"); + + // Even more code + + t.addEpoch("Yet Another Epoch"); + + t.printEpochs(); + } + + } + + .. group-tab:: C++ (Header) + + .. code-block:: cpp + + //coming soon! + + .. group-tab:: C++ (Source) + + .. code-block:: cpp + + //coming soon! + +when :code:`printEpochs()` is called, a print statement will be generated listing out the duration that each period defined by `addEpoch()` took. By carefully placing your epochs, you can identify which pieces of code take longer than others, to know where you need to optimize your code. \ No newline at end of file diff --git a/source/docs/software/troubleshooting/networking.rst b/source/docs/software/troubleshooting/networking.rst new file mode 100644 index 0000000000..88e1a6cab1 --- /dev/null +++ b/source/docs/software/troubleshooting/networking.rst @@ -0,0 +1,40 @@ +Debugging Network-Related Problems +================================== + +Usual Symptoms +-------------- + +Setting up the driver station in the short few seconds before the match should be utilized to do a quick connectivity and joystick check. Assuming your robot is turned on and has been turned on for ~30-60 seconds, you might realize a problem has happened. Below are a list of common reasons you are unable to connect to your robot. + +- Disconnected ethernet connection on the driver station + - Is the ethernet port on the driver station functional? +- Disconnected ethernet connection on the robot + - Perhaps the rio <-> radio connection came unplugged + - Perhaps the ethernet cord is bad (can be identified by looking at the light indicators on the Rio/Radio for network activity) +- Is the firewall disabled? + - It is recommended that the firewall is always disabled when at an events + +.. todo:: add more and maybe some images + +If on the field, you should immediately notify the FTA that there is a connectivity issue for the quickest resolution. + +.. important:: While rare, it has been shown that the robot radio can sometimes take a large amount of time to boot - 90 seconds or more. + +Driving toward Root Cause +------------------------- + +Checking physical connections +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Checking wifi connections & interference +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Check power supply to radio or switch (resets) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Check Firewall +^^^^^^^^^^^^^^ + +Try different ethernet port +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + diff --git a/source/docs/software/basic-programming/reading-stacktraces.rst b/source/docs/software/troubleshooting/reading-stacktraces.rst similarity index 94% rename from source/docs/software/basic-programming/reading-stacktraces.rst rename to source/docs/software/troubleshooting/reading-stacktraces.rst index 4980a9197f..0375522dd6 100644 --- a/source/docs/software/basic-programming/reading-stacktraces.rst +++ b/source/docs/software/troubleshooting/reading-stacktraces.rst @@ -598,33 +598,3 @@ In the example, the left motor controllers are plugged into PWM ports ``0`` and frc::PWMVictorSPX m_rearLeftMotor{1}; }; - -gradlew is not recognized... -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``gradlew is not recognized as an internal or external command`` is a common error that can occur when the project or directory that you are currently in does not contain a ``gradlew`` file. This usually occurs when you open the wrong directory. - -.. image:: images/reading-stacktraces/bad-gradlew-project.png - :alt: Image containing that the left-hand VS Code sidebar does not contain gradlew - -In the above screenshot, you can see that the left-hand sidebar does not contain many files. At a minimum, VS Code needs a couple of files to properly build and deploy your project. - -- ``gradlew`` -- ``build.gradle`` -- ``gradlew.bat`` - -If you do not see any one of the above files in your project directory, then you have two possible causes. - -- A corrupt or bad project. -- You are in the wrong directory. - -Fixing gradlew is not recognized... -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -``gradlew is not recognized...`` is a fairly easy problem to fix. First identify the problem source: - -**Are you in the wrong directory?** -- Verify that the project directory is the correct directory and open this. - -**Is your project missing essential files?** -- This issue is more complex to solve. The recommended solution is to :ref:`recreate your project ` and manually copy necessary code in. diff --git a/source/docs/software/basic-programming/using-test-mode.rst b/source/docs/software/troubleshooting/using-test-mode.rst similarity index 100% rename from source/docs/software/basic-programming/using-test-mode.rst rename to source/docs/software/troubleshooting/using-test-mode.rst diff --git a/source/index.rst b/source/index.rst index ef3bc696e1..c0dc513566 100644 --- a/source/index.rst +++ b/source/index.rst @@ -288,7 +288,9 @@ Community translations can be found in a variety of languages in the bottom-left docs/software/hardware-apis/index docs/software/can-devices/index docs/software/basic-programming/index + docs/software/troubleshooting/index docs/software/support/support-resources + docs/software/troubleshooting/index docs/software/frc-glossary .. toctree:: diff --git a/source/redirects.txt b/source/redirects.txt index 7e2253c4e8..b68b9e47ed 100644 --- a/source/redirects.txt +++ b/source/redirects.txt @@ -265,3 +265,5 @@ "docs/software/pathplanning/pathweaver/creating-path-groups.rst" "docs/software/pathplanning/pathweaver/creating-autonomous-routines.rst" "docs/software/dashboards/smartdashboard/setting-robot-preferences-from-smartdashboard.rst" "docs/software/basic-programming/robot-preferences.rst" "docs/software/advanced-controls/introduction/tuning-pid-controller.rst" "docs/software/advanced-controls/introduction/tuning-flywheel.rst" +"docs/software/driverstation/driver-station-errors-warnings.rst" "docs/software/troubleshooting/driver-station-errors-warnings.rst" +"docs/software/basic-programming/using-test-mode.rst" "docs/software/troubleshooting/using-test-mode.rst" \ No newline at end of file