Hardware Component Testing#

Note

This section is designed and tested for DB21-series Duckiebots and onwards.

This section shows how to use the Dashboard to test different individual hardware on a Duckiebot.

Assuming you have your Duckiebot assembled, the SD card prepared and the Software updated after booting. Before diving into the beautiful yet could-be-complicated world of robotics and coding, let’s do a few simple individual hardware component tests to verify the sensors, actuators, computation and power units work.

The purpose of these tests is to help us be confident in the hardware, and avoid wasting time debugging software without knowing whether the hardware works.

In case you encounter any erroneous behaviors of any of your hardware components, or have any questions about the process, please check out a later sub-section on this page for FAQs, reporting and getting help.

Where to find the Hardware Tests#

The tests could be accessed on the Components tab on the ROBOT page of the Dashboard.

In each component with the button Test Hardware, the test description and expectations would be shown in a modal (an on-page pop-up) when the button is clicked. Before running any test, it is recommended to watch the videos in the next section at least once to see how the robot would behave in each test.

Tip

  • You can always perform these tests.

  • Later on, if you have problems receiving sensor readings, commanding the motion, or connecting to the robot, maybe you could run these tests again before debugging the code.

Demos of the Hardware Tests#

These videos would be what you typically need to do or would see, when performing the tests.

(You might want to manually set the video resolution to 1080P, instead of Auto.)

Component

Demo Video

Battery

Camera

Left motor

Right motor

Left encoder

Right encoder

Screen

IMU

Power button

Wifi adapter

Front LEDs

Back LEDs

Time-of-Flight distance sensor

FAQs, Reporting Problems & Getting Help#

Problems could arise due to faulty hardware, misleading setup instructions, erroneous handling etc. Let’s deal with them, patiently and efficiently. This part contains:

  • some FAQs

  • how to gather logs and enrich the context of an issue reported

  • places and formats to post questions and feedback

FAQs#

Here are some common possible issues and resolutions you could already try. If the suggestions do not lead to a successful outcome, do not spend too much time trying it. Maybe we did not make it clear enough. Feel free to report to the team as mentioned in this part.

Troubleshooting

SYMPTOM

When I click on the “Test Hardware” button:

  • the button does not seem to react / is grayed-out; or

  • the modal shows up, but there is no content in it.

RESOLUTION

This is likely because the duckiebot-interface container did not start or has not finished initialization successfully. You could go to the “Portainer” page of the Dashboard, and select Containers on the left nav-menu. Then, you could try these:

  • First, look for the duckiebot-interface container, and make sure it exists. If not, try from your host computer: dts duckiebot update ![ROBOT_NAME]. After the command finishes, repeat this check in a few minutes.

  • If it does exist, check the logs of the container (Ref: how to check logs in portainer). Ask

Troubleshooting

SYMPTOM

Can I close the modal while the test is running?

RESOLUTION

Yes. It will be alive in the background. But you should avoid doing so. Please run only one test at a time, wait until you could check for the expected outcomes, and then close the modal once all done.

When running tests for sensors like camera or ToF, the data would be streamed. It is fine to close the modal after you could determine whether the test passed or failed. On the other hand, for tests with a progress bar, wait for the described time period. Only the LEDs might need a little longer time than written in the description (please check the next FAQ).

Troubleshooting

SYMPTOM

My front and back LEDs seem stuck at a color when performing test. Is this normal?

RESOLUTION

The LEDs ideally should be changing brightness or color (or both) all the time during the test. However, it could occur that the frequent commands issued to the LEDs creates a temporary congestion and make the system busy. And the LEDs would appear to be neither changing color nor brightness. The situation should only last for less than 30 seconds.

  • Please wait for the duration patiently to see if the test proceeds.

  • If it is ever longer than that, please don’t hesitate to contact our team and report the problem.

Troubleshooting

SYMPTOM

Would it be harmful if the Duckiebot is turned off during some test runs?

RESOLUTION

No. These are very simple hardware tests. It is perfectly safe to kill any programs or power down the robot.

Troubleshooting

SYMPTOM

Why, in the camera test, the image appears smaller than the sensor data size (see start_gui_tools in coming sections of this book)?

RESOLUTION

The camera stream in the Dashboard hardware test is resized, such that it fits better in the pop-up modal. The actual data size is always the same as what ROS indicates.

How to provide a rich context when reporting problems#

You are of course welcome to ask us your questions directly anytime. In order to get back to you faster and debug efficiently, having richer context would help a lot! That is also why, in the modals you see for each hardware test, there are the buttons for:

  • Download logs of this ROS node: by clicking this button, a text file will be downloaded from your Duckiebot to your personal computer, containing the logs of the relevant ROS node.

  • Download docker container logs: by clicking this button, a new modal should pop up, allowing selection of the docker container(s), that is related to this test. The relevant container(s) is/are typically mentioned in the “Logs Gathering” section of the test modal.

Tip

Here’s a potential example of organizing information in one issue:

  1. I am performing hardware test via the Dashboard for component: …

  2. I followed the instructions until this step / am waiting for this outcome: …

  3. It’s not clear what to expect. / The expectation is …, but I see …

  4. The logs for the ROS node: file/pasted text

  5. The logs for the relevant containers: file/pasted text

Not only does the rich context help the team recognize the problem and provide solution faster, the community could also benefit, by knowing clearly if someone had an identical/close problem before. And you might be able to find useful answers just by searching our StackOverflow.

In the next sub-section, we recommend some tags and endpoints for communicating the issues to.

Where to post questions & feedback#

  • (Preferred) StackOverflow for Duckietown

    • It is recommended to use these tags when posting on StackOverflow

      • robot-setup

      • hwtest, hw tests, hardware-test, hardware-tests (and other similar)

      • hwtest-Name of the component

  • You could also ask on the Duckietown Slack, on the help-robot-setup channel. But it is more preferable to post technical issues on our StackOverflow, and any other feedback on Slack.

    • Here are some kinds of “any other feedback”:

      • The tests ran but the description clarity could improve here and here.

      • The test design would be better if the content is this.