Comments (9)
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 ofcommon._.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.
Related Issues (20)
- reg.drone.service.battery.Parameters.0.2 is missing the nominal cell voltage HOT 17
- Pregenerated headers of public_regulated_data_types to ease development HOT 3
- Incorrect nested type in reg.drone.physics.kinematics.translation.Velocity3Var
- Suggestions and questions HOT 3
- Some questions about the dsdl file under /uavcan/equipment/power HOT 2
- Migrate to GitHub Actions
- uavcan.can.iface is not exposing available interfaces HOT 5
- Extend primitive types with small fixed-size arrays HOT 2
- pycyphal demo HOT 2
- Remove the translational/rotational segregation in `reg.udral.physics.kinematics` and `reg.udral.physics.dynamics` HOT 1
- Modify the servo interface for compatibility with common trajectory generators HOT 1
- Incorrect name of uavcan.si.magnetic_field_strength
- Define standard registers for publication priority setting
- Stabilize v0.x data types in the `uavcan` namespace
- Add luminance to si types HOT 1
- Allow full stop inside the PORT_NAME
- Transfer UDRAL definitions to the DS-015 project
- Define new minor versions of data types that contain strings
- Cyphal/UDP: provide a standard register for overriding the priority to DSCP mapping
- Add a `CMD_IDENTIFY` to ExecuteCommand HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from public_regulated_data_types.