How to Brief a Robotics and Automation Project So the Right Engineer Finds It: From Prototype to Operation

Robotics projects combine programming, electronics and mechanics, and they differ from software projects because the real world gets involved: friction, dust, loads and parts delayed in shipping. An unclear post gets proposals you can’t compare, or a project that stalls at the first test. This guide helps you write a post in the Robotics & Embedded category on Farasa. For the general rules, read our guide to posting software projects.

Describe what the robot must do in one clear sentence: “an arm that picks parts from a bin and places them on a belt,” “a robot that moves around a warehouse delivering items between two points,” or “automating filling and sealing on a small line.” Then describe how the task is done today and what you want improved: speed, accuracy, or less manual work.

Stating the environment saves you costly mistakes: indoor or outdoor, level floor or not, dust, humidity or high heat, and the working area in metres. For the payload: the weight, size, shape and fragility of the objects. For accuracy: what is the largest acceptable position error, in millimetres or centimetres? A robot that places a part within a millimetre differs in price and complexity from one that delivers items to within half a metre.

Say what the robot needs to “sense”: a camera, a distance sensor, a weight sensor or positioning. Say whether you prefer particular tools (Arduino, ESP32, Raspberry Pi, or the ROS framework for larger robots); otherwise ask for a recommendation with reasons. If the task needs modelling or simulation before building, say so, because it saves many hardware trials.

A prototype proves the idea works and tolerates failures; running for many hours every day needs durability, safety, endurance tests, documentation and maintenance. Write which you want, and if you want both, split the project into two phases, since the first phase’s results show whether the second is worthwhile.

If the robot will work near people or move loads, say so and ask applicants to explain their safety measures: an emergency stop, motion limits and collision protection. Don’t be casual about this part however small the budget.

Agree who buys the parts: you or the engineer? And how are they billed? Which parts are available in your city and which need shipping? Waiting weeks for one part changes the schedule. Ask for a parts list with estimated cost as part of the proposal.

Programming and simulation can be done remotely, but assembly and testing on real hardware may need the engineer on your site, or you running tests following their instructions. State your city and whether the site is available for testing.

“A robot arm that picks small medicine boxes (under 200 g each) from a bin and places them in set positions on a belt, inside a factory in Najaf. The work area is about one square metre and acceptable accuracy is ±3 mm. A camera finds each box’s position. Phase 1: a lab prototype proving it can pick and place 20 boxes a minute, then we decide on real operation. I want a simulation before buying anything, and a parts list with costs. I will buy the parts. Budget: fixed price for phase 1 within a range (put your range here). Start your proposal by naming a robotics project you’ve built and the hardware you used.”

Write the task, describe the environment, payload and accuracy, name the sensors and tools, agree a prototype before operation, don’t skimp on safety, and settle who buys parts early. That gets you clear proposals. Post your robotics project on Farasa.