Clarification on Actuator (setpoint) commands about public_regulated_data_types HOT 9 CLOSED

The group setpoints are weakly typed. There are no dedicated types per control mode, just raw float16, so what you see is all there is. Your actuator is supposed to interpret the values according to its pre-configured settings.

from public_regulated_data_types.

Ok, I'm still a little confused at how it's implemented in practice. Let's say I have 5 servos and 8 ESC's. Can you point me to the relevant documentation on how I would send those commands from the flight controller, and how the actuators would be able to interpret them?

Part of my misunderstanding may be related to how the abstract "port IDs" get created and used, so if your answer is "read the docs", I will oblige; a little clarification would be nice though.

from public_regulated_data_types.

so if your answer is "read the docs", I will oblige

Ooh, that is always the answer. If the docs are unclear though, that's our fault and is something to be fixed.

In this specific case we have this passage from The UAVCAN Guide:

You just manually assign these when you integrate the device into a vehicle. In a later revision of DS-015, we will define a way to do that semi-automatically, like USB.

from public_regulated_data_types.

Ah, that 2nd bullet point I may have read previously, but it didn't sink in. I see now - this makes sense... I think. So when a new node is plugged into the network and provides a service, you must tell it what the port IDs that comprise that service are, instead of relying on static port IDs that all nodes must agree on ahead of time (UAVCAN v0).

Still, I'm not certain I understand how the different types can be mixed and matched. When you want to configure a node to send, say, reg.drone.service.actuator.esc.sp.Vector8.0.1.uavcan, what tool contains or provides the knowledge that this points to an independent instance of reg.drone.service.actuator.common.sp.Vector8.0.1.uavcan? I suppose I see how you can set, on the server side, a port ID for the common.sp object and not worry about the esc version. But where on the client side can I tell the DSDL compiler that I want the esc.sp.Vector8 object (which has no data type definition right now) to be interpreted as a common.sp.Vector8 object?

from public_regulated_data_types.

I suppose I see how you can set, on the server side, a port ID for the common.sp object and not worry about the esc version. But where on the client side can I tell the DSDL compiler that I want the esc.sp.Vector8 object (which has no data type definition right now) to be interpreted as a common.sp.Vector8 object?

A UAVCAN node needs you to define the mapping between port-IDs and the network services it provides by setting the appropriate configuration parameters (usually it is done using the Register API but it is not important right now). If you have an ESC that needs to subscribe to a setpoint subject, it would expect the data published over that subject to be of a particular type that you, as an integrator/user, can't change (it is set by the manufacturer). What you need to configure is the subject-ID of that data (of the correct or compatible type). Shall it turn out to be incompatible, the behavior of the node may turn unpredictable, so it is your responsibility to wire the logic correctly. Unlike v0, the type information is not available at runtime unless you invoke the dedicated introspection APIs.

Also, note that there are no dedicated setpoint types for ESC and servos.

from public_regulated_data_types.

Also, note that there are no dedicated setpoint types for ESC and servos.

I think this clears up my confusion - they simply don't exist right now.

from public_regulated_data_types.

They are not going to exist ever, at least that's the current plan. You don't need dedicated types if the only difference is the name.

from public_regulated_data_types.

That's totally fine; with the esc and servo sub-folders, I just expected there to be more there than simply documentation of possible use-cases. Pedantically, then, should the documentation provided inside {esc,servo}._.0.1.uavcan instead be placed inside of common._.0.1.uavcan?

from public_regulated_data_types.

Pedantically, then, should the documentation provided inside {esc,servo}._.0.1.uavcan instead be placed inside of common._.0.1.uavcan?

I'm not sure if having dedicated namespaces just for documentation is necessary, but I don't want to merge everything into one document because we need the ability to evolve service definitions independently. We could make it ...actuator._ESC.0.1, ...actuator._Servo.0.1 instead, I suppose, but then adding new actuator-specific types (e.g., specifically for ESC) would get slightly more invasive.

We may revisit this arrangement later.

from public_regulated_data_types.