What the work actually involves
You write control engineering content that a model can learn from: derive a plant model from first principles, justify the state-space or transfer-function form you chose, tune a PID or synthesize an LQR/MPC/Kalman solution, implement it in Python with open-source stacks (python-control, SciPy, CasADi, do-mpc), and then explain the reasoning in prose that holds up to scrutiny. A typical task is a self-contained problem with a defensible answer plus the trace of how you got there — sign conventions, linearization point, sample rate, actuator saturation, what you'd check on the bench. Some tasks flip the direction: you read a model-produced controller design or derivation and mark where it goes wrong, which is usually a plausible-looking gain calculation with a units error or an ignored unmodeled pole.
What the screen is looking for
micro1's screening is AI-led and follow-up heavy. It probes whether your control knowledge is bench-earned or textbook-recited — expect questions about encoder noise, integrator windup, deadtime, discretization choices, and what happened the first time your controller met a real actuator. It also checks that you can write: clear, precise English is not a soft preference here, because the written artifact is the deliverable. Python fluency is verified concretely, so be ready to describe how you'd set up and validate a closed loop in code rather than naming libraries.
Logistics
- Fully remote contractor engagement, no fixed hours; work is claimed from a task queue
- Most contributors run 10–20 hours a week alongside other work; some scale up when a project ramps
- Observed pay band $30–50/hr, positioned by domain depth and task type — not guaranteed
- Collaboration is asynchronous with interdisciplinary reviewers; occasional calibration calls
- No prior AI or ML experience expected or required