The workflow described here reflects how threads, build logs, and troubleshooting notes actually move through the forum. It is not a rigid process, but a set of expectations that keep conversations useful and easy to follow. If something feels unclear, these notes should settle it before you post.
A build log documents one project from start to finish, with updates added as you go. A thread is for a specific question or discussion, like troubleshooting a motor driver or comparing chassis materials. Posting a build log inside a troubleshooting thread makes it harder for others to find the answer later. Keep them apart unless you are explicitly asked to share more context.
Explanations should be clear enough for someone who just assembled their first kit, but that does not mean skipping details. Include the board name, voltage, current draw, and the code snippet you are using. A photo of the wiring helps more than a paragraph describing it. The goal is that someone else can reproduce your setup, not just admire it.
When you recommend a supplier or a specific module, mention whether it is a local South African shop or an overseas order. Import duties and shipping times change the value of a recommendation. If you bought something from a local electronics retailer, say which one and what it cost you in practice. If you ordered from abroad, note the lead time and any customs fees you paid.
The forum values what you have actually tried on your workbench. If a component overheated, a chassis flexed under load, or a sensor misbehaved in bright light, that is worth sharing. Academic explanations have their place, but they should support the practical observation, not replace it. If you are unsure why something failed, describe the symptoms and what you tested.
South African hobbyists deal with heat, humidity, and sometimes direct sunlight in a workshop. PLA parts can warp in a hot car or a sun-facing window. When you share a chassis design or an enclosure, note the material and the conditions it was tested in. This helps someone in a different region avoid a failure you already solved.
When you share microcontroller code, format it so it is easy to read and test. Include the library versions you used and note any pins that are specific to your board. If a snippet is only a fragment, say what it is supposed to do and where it fits in the full sketch. Do not assume everyone uses the same board or wiring layout.
Every project on Botrose follows a loose timeline, not a rigid process. Some stages overlap, some get skipped when a kit arrives pre-assembled. What stays consistent is the habit of documenting decisions as you go, so the next builder can learn from your notes.
Week 1 - Concept and parts list
Most members start with a rough drawing and a list of components they already own. The first forum posts usually ask about voltage compatibility between a battery pack and a chosen driver board, before any soldering happens.
Week 2 - Sourcing and delivery
South African builders compare notes on which suppliers keep DRV8833 modules in stock and how long customs clearance actually takes. If a part is backordered, the thread shifts to substitute components that fit the same footprint.
Week 3 - Bench assembly and first code
The real workshop experience starts here. Members post photos of their breadboard layouts and ask for a second pair of eyes on wiring before powering up. A simple blink test on the microcontroller usually comes first, then a motor spin test without the chassis attached.
Week 4 - Chassis fit and sensor calibration
Once the motors spin reliably, the build moves to the chassis. IR sensors get positioned at the right height above the floor, and the PID constants start as rough guesses. Build logs at this stage often include notes on how ambient light affects readings in a garage workshop.
Week 5 - Testing and troubleshooting
The first full run rarely goes clean. Uneven wheel speeds, sensor noise, and battery sag under load are the usual suspects. Members share their oscilloscope readings and multimeter checks, then propose small code tweaks or mechanical fixes like adding weight to the front caster.
Week 6 - Showcase and build log
Finished builds get their own thread with a short video of the robot following the line and a summary of the parts that actually worked. The most useful logs include a note on what the builder would do differently next time, which becomes the starting point for the next project.
Every project on Botrose follows a similar path, whether it is a first line follower or a more complex sensor rig. Knowing what happens at each step helps you post useful content and get better answers from the community.
Describe the robot you want to build, the parts you already have, and what you are unsure about. Include your microcontroller model and motor driver if you have picked one. A clear starting point gets more focused replies.
Upload photos of your chassis, wiring, and any test runs. Note what worked and what did not. Real workshop details, like which sensor calibration routine you used, help others spot issues faster.
Members will comment on your code, suggest alternative parts, and point out wiring mistakes. Expect questions about your power supply and motor current draw. Reply with measurements when you can.
Take the suggestions back to your workbench. Adjust your PID values, reflow a solder joint, or swap a noisy sensor. Most builds need two or three rounds of tweaks before the robot behaves reliably.
Update your thread with the finished build, a short video of it running, and a list of parts you actually used. Note any local suppliers that delivered quickly. This becomes a reference for the next builder.
Answer questions on threads about similar builds. Share what you learned about import duties or 3D printing in humid conditions. The forum works best when experienced builders stick around.