Added snapshot of current hardware design
This commit is contained in:
63
firmware/docs/implementation-notes.adoc
Normal file
63
firmware/docs/implementation-notes.adoc
Normal file
@@ -0,0 +1,63 @@
|
||||
Motion control in an interrupt.
|
||||
|
||||
= Parts
|
||||
This consists of two parts, the planner and the executor.
|
||||
|
||||
The planner receives target positions. Each time it receives a target
|
||||
position, it replans so as to reach that position as soon as possible;
|
||||
the output of a plan consists of a set of motion segments, each
|
||||
following a 3rd order polynomial.
|
||||
|
||||
The executor processes the current state and decides whether to toggle
|
||||
the step lines of the MCU.
|
||||
|
||||
These two processes communicate by means of a command queue.
|
||||
|
||||
== Executor
|
||||
1. Update a cycle counter
|
||||
2. Evaluates the next output of the position polynomial (3 adds)
|
||||
3. determine whether to toggle a stepper, and do so.
|
||||
4. Determine whether to start the next segment; if so, advance in the command queue.
|
||||
|
||||
|
||||
|
||||
== Command queue
|
||||
|
||||
The command queue takes the form of a ring buffer, with each item
|
||||
containing a motion segment. The ring buffer must be large enough to
|
||||
contain a complete motion profile plus a terminating "stop" segment.
|
||||
|
||||
A motion profile segment consists of the following values:
|
||||
|
||||
* For step computation
|
||||
* Δx1..Δx3 (initial values)
|
||||
* start time (in ticks)
|
||||
* For use by the planner
|
||||
* v₀, vₑ: Initial and terminal velocities
|
||||
* a₀, aₑ: Initial and terminal acceleration
|
||||
* The actual position at the start time (written by executor)
|
||||
|
||||
The following invariants hold for the command queue:
|
||||
|
||||
|
||||
== Planner
|
||||
|
||||
=== Aborting
|
||||
|
||||
In case of an abort, the fastest stop profile will consist of at most
|
||||
3 segments: const -jerk to max -a, const -a to to lead-out, const +j
|
||||
to a=v=0.
|
||||
|
||||
If we're already in the last three segments, we're already in
|
||||
a race to a stop, so there's no need to handle an abort specially.
|
||||
|
||||
In the cv segment, we can simply advance the start times of each leadout segment.
|
||||
In the lead-in, we need to replan; this is, however, easy enough:
|
||||
|
||||
1. Predict state in $t_plan$ cycles
|
||||
2. Identify how to reach a=0; prepare a segment accordingly
|
||||
3. Feed the end values from said segment to the leadout calculator
|
||||
4. replace the next N commands with this leadout.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user