How to Ask a Robotics Question That Actually Gets Answered

Choose the Right Community First

Posting in the wrong place wastes your time and theirs. Different forums serve very different audiences. Robotics Stack Exchange (robotics.stackexchange.com) is now the main Q&A site for ROS and general robotics questions; it absorbed the old ROS Answers site (answers.ros.org), which was retired in 2023 and is read-only, so post new questions on Stack Exchange rather than the legacy site. ROS Discourse (discourse.ros.org) is better for announcements, design discussion, and open-ended conversation than for debugging. The Arduino forums are best for microcontroller questions at the hardware and firmware layer. Reddit communities like r/robotics skew toward general discussion and project sharing rather than deep technical debugging. Discord servers for specific frameworks (PX4, Betaflight, MoveIt) often have active maintainers who respond quickly.

Before you post anywhere, spend five minutes checking whether the community handles your type of question. Scan recent posts. If you're asking about a ROS 2 navigation stack issue in a forum full of Arduino beginners, you're unlikely to get a useful answer no matter how well you frame the question.

Search Before You Post

The single most effective thing you can do before posting is search. Most robotics questions, especially error messages, have already been asked and answered somewhere. Search the exact error message in quotes. Check the GitHub issues page for the library or firmware you're using. Look at the official documentation or changelog if you recently upgraded a dependency.

If you do find a related thread but it doesn't fully solve your problem, link to it in your post and explain specifically what's different about your situation. This shows you've done your homework and helps others understand exactly where the existing solutions fall short.

State Your Goal, Not Just Your Symptom

Describe what you are trying to accomplish, not only what went wrong. "My PID loop isn't working" tells a helper almost nothing. "I'm trying to hold a 3 kg differential-drive robot at a heading of 90 degrees using a BNO055 IMU, but the heading drifts about 15 degrees per minute even with the motors stopped" gives them something actionable.

Include the broader context. Is this a competition robot? A fixed installation? Does it need to operate outdoors? Understanding the end goal sometimes reveals that the approach itself is the problem, not the specific implementation.

List Your Hardware and Software Versions Precisely

Version information is not optional; it's often the entire diagnosis. Include the specific microcontroller or single-board computer (for example, Raspberry Pi 4 Model B, 4 GB, not just "a Raspberry Pi"), the operating system and version, the firmware version if applicable, and the exact library versions. For ROS 2 users, state your distribution (for example, Humble or Jazzy); you can confirm it with printenv ROS_DISTRO or echo $ROS_DISTRO. On ROS 1 (Noetic and earlier), rosversion -d prints the active distribution. For Arduino, include the IDE version and any installed library versions.

For hardware, list the relevant components: motor driver model and revision, sensor model, battery voltage and configuration, and any relevant wiring topology. You don't need to list every component, but anything in the signal path related to your problem should be mentioned.

Show What You Tried and What Happened

Walk through your debugging steps in order. Helpers need to know what you've already ruled out so they don't waste time repeating it. "I checked the wiring with a multimeter and confirmed 5 V at pin 7" is useful. "I checked everything" is not.

Paste the actual error message or log output in full, not a paraphrase. Copy the exact text, including line numbers and stack traces. If your issue is visual (a robot moving in an unexpected direction, an arm not reaching the target pose), a short video or annotated photo is worth more than a paragraph of description.

Post a minimal reproducible example for code problems. Strip your code down to the smallest version that still shows the bug. This process often reveals the bug on its own, and when it doesn't, it makes your code far easier for someone else to test in isolation.

Follow Up and Close the Loop

If someone responds, acknowledge it promptly. Even a quick "I tried that and it didn't work, here's what happened" keeps the thread moving. If you solve the problem, post exactly what fixed it; future searchers will find your thread and benefit from the answer. On sites like Robotics Stack Exchange, mark the correct answer as accepted. On traditional forums, edit your title or first post to include "[SOLVED]" so others know the thread has a resolution.

If you go silent after getting help, people notice. Communities where questioners disappear without acknowledgment eventually stop engaging with new questions from those users. A one-line follow-up after a problem is resolved is a small courtesy that keeps the community functional for everyone.