ConfigurationSelector

ConfigurationSelector holds up to five matrices of the same size and publishes whichever one you select. All five can be edited while the controller runs, so a gain set, a transformation or a model’s coefficients can be changed and switched without rebuilding.

Set the matrix size to 1×1 and it becomes a five-way switch between single numbers.

flowchart LR
    p0(["configurationIndex"]) --> B["ConfigurationSelector"]
    p1(["configuration0"]) --> B
    p2(["configuration1"]) --> B
    p3(["configuration2"]) --> B
    p4(["configuration3"]) --> B
    p5(["configuration4"]) --> B
    B --> o1(["output"])

The switch is instantaneous. The output steps to the new matrix on the same cycle the index changes — there is no fade. That is usually what you want for a set of coefficients, because a blend of two validated configurations is a third one nobody validated. If the block downstream cannot take a step, smooth it there.

Matrices are stored one column at a time, not one row at a time. For a 3×3, tree elements 0, 1, 2 are the first column, not the first row. Fill them in that order or you will get the transpose of the matrix you meant. This catches nearly everyone once.

An index above 4 silently selects configuration0. Nothing reports that your request was rejected, so check output matches what you expected.

Signals

Outputs

This block has no inputs. The selection and all five matrices are parameters, so everything about it is configured rather than driven.

Parameters

All are persistent and survive a controller restart. All five configurations exist whether or not you use them, and each is the full matrix size, so an unused configuration still occupies its place in the tree. No parameters exist below this block.

The matrix size is fixed when the controller is built and cannot be changed from the tree.

Setup

1. Work out the storage order for your matrix size before you write anything. For a 3×3, the nine values run down the first column, then the second, then the third.

2. Write your first matrix into configuration0 in that order.

3. Read output back and confirm it matches. If it looks like the transpose of what you typed, you filled it row by row — refill it column by column.

4. Fill the other configurations you need. Leave the rest at zero.

5. Set configurationIndex and confirm output changes to the matching matrix.

6. Confirm the index survives a controller restart, and that the output comes back on the right configuration.

   Whatever consumes output will act on the new values immediately when you change the index — there is no fade. If that is a controller gain, the machine’s behaviour changes on that cycle.

Tuning

1. There is nothing to tune in this block itself. The tuning lives in the matrices you put in it and in whatever consumes them.
2. Use it to hold alternative tunings side by side: a cautious set in configuration0, a production set in configuration1, a diagnostic set in configuration2.
3. Keep configuration0 as your safe fallback. It is what you get when the index is out of range, so it is the one that must always be sane.
4. Edit a configuration while the controller runs and the change reaches output on the next cycle — including the one currently selected. Editing the active configuration changes the machine’s behaviour immediately, one element at a time as you type them. Edit an inactive one and switch to it instead.
5. Verify each configuration by selecting it and reading output back, rather than trusting what you wrote.
6. Nothing here depends on the task rate, so none of this needs re-checking after a rate change.

The step is the point. Smooth it downstream if you need it smoothed.

A starting point for a 3×3 used to hold two gain sets:

configuration0 = <the cautious set, column by column>
configuration1 = <the production set, column by column>
configurationIndex = 0

Limits and errors

This block logs nothing, ever. Every condition above shows as a value on a trace, or not at all.

Verified against motorcortex-control3 3.30.0 (bc348fd).