Corrections
How to report an error on the Robotics Field Guide, how we check and fix it, and how corrections are recorded on the page and in a public log.
Robotics changes quickly. Drivers are renamed, distributions reach end of life, and makers revise datasheets. Some of what we publish will be wrong, either from the start or after a while. This page explains how to tell us, what we do with the report, and how the fix is recorded.
How to report an error
Email the editor at editor@roboticsfieldguide.com (details on the contact page). Include the page address, what is wrong, and if you can, what is right and where it can be checked. A link to the maker’s datasheet, the official documentation, a paper or a standard is the fastest route to a fix. For code, include the error message and your versions.
You do not need to be sure. “This looks wrong to me” is a useful report, and we will check it.
What happens next
| Step | What we do |
|---|---|
| Check | We read the report and check the claim against the primary source: the datasheet, documentation, paper or standard |
| Decide | We classify it as a correction, an update or a disagreement (see below) |
| Fix | We change the page and move its “updated” date. For code, we rerun the block in the same environment as before |
| Note | A correction gets a dated note at the foot of the page saying what was wrong and what changed |
| Log | A correction also gets an entry in the log on this page |
| Reply | We tell the person who reported it what we did, or why we did not change the page, with a source |
If we cannot settle the question, we say on the page that the point is disputed, until we can.
Correction, update or disagreement
A correction fixes something that was wrong when it was published. Examples include a wrong payload or reach figure, a licence misread, a ROS 2 command with the wrong flag, code that does not do what the text says, a maker’s claim reported as a measured fact, or a claim the cited source does not support. Corrections get a note on the page and an entry in the log.
An update changes something that was right when published and has since changed. Examples include a new software release, a distribution reaching end of life, a revised datasheet, a price change or a moved link. Updates move the “updated” date, and on reference pages the “last verified” date. They get no log entry, because the earlier text was not an error.
A disagreement is a matter of judgement, such as which simulator suits a task or whether a tuning rule is a good starting point. We may add the other view to the page if the argument is sound and sourced.
The “last verified” date
Reference pages, the software matrix and the robot database show a “last verified” date. It is the date on which every version, specification, price and link on the page was last checked against its source. A page can be updated without being re-verified (a typo fix), and re-verified without being updated (everything still held). Use the date to judge how far to trust a version number.
Corrections log
Each entry gives the date, the page and one line on what was wrong and what changed. Entries stay here permanently.
No corrections have been recorded yet. The first entry will appear here when the first error is fixed.