Motor detection via back EMF about sapog HOT 4 CLOSED

The network may contain other UAVCAN nodes, not only ESC. We need to restrict the enumeration process so that only ESCs are affected. One possible solution is to define a vendor-specific message/service for that (only ESC will be able to recognize it), but generally it is preferred to reduce the number of vendor specific data types when possible to improve cross-vendor compatibility.

So I propose a generic approach based on a single new standard message. It is suitable for any node that can receive some confirmation from the user (e.g. motor turn, button press).

Here's the new message uavcan.protocol.EnumerationRequest:

uint8 timeout_sec
uint7 node_id

Let the default node config contain an invalid Node ID, so the node starts in passive mode (i.e. it can listen the bus but can't transmit anything). If the node is in passive mode, it subscribes to uavcan.protocol.EnumerationRequest and is ready to get a new Node ID. The node shall not subscribe to that message if it is already configured to avoid spurious reconfiguration.

The algorithm then (essentially it's just a variation of your proposed approach):

1. The main node (e.g. a Pixhawk) performs network discovery to find all ESCs that are already configured (unconfigured ESC will not be discovered).
2. Each discovered ESC is reset to default config (using uavcan.protocol.param.*) and restarted, so it enters passive mode and awaits uavcan.protocol.EnumerationRequest. Now all ESC are unconfigured and are ready for enumeration.
3. For i=0..N (where N is provided by the user):
   1. Pixhawk broadcasts uavcan.protocol.EnumerationRequest with node_id set to an appropriate value.
   2. The user turns the motor; ESC assigns itself the requested Node ID, saves the config, and restarts (not in passive mode this time).
   3. Pixhawk makes sure that ESC is now online with proper Node ID.
4. Enumeration is done now; however, the ESC are not ready to work yet because we need to assign motor indices. This is done automatically with no attention from the user. For each ESC:
   1. Set the config param uavcan_esc_index.
   2. Set the config param uavcan_light_index (optional, for RGB LED control).
   3. Save the config params into the non-volatile memory.
   4. Restart this ESC.
5. Make sure that all N ESCs are online and have status code OK.

Note that this algorithm can be safely restarted from any stage.

from sapog.

@pavel-kirienko The user will need to identify the ESCs not only in their order, but also regarding their position - therefore assigning an ID and a position is linked (since the flight code has a fixed mapping of ID to position). So step 3+4 will happen at the same time.

from sapog.

@LorenzMeier Yes, essentially it doesn't matter whether 3&4 happen at the same time or subsequently. It's just important to realize that Node ID and motor index are not the same thing.

A new idea: since we're asking user to turn the prop, we could also ask them to turn the prop in the right direction (CW/CWW) so we can configure the direction of rotation automatically too. It shouldn't be hard to implement.

from sapog.

Done.

from sapog.