Automatic extension change & Cyphalization (#127)

* Automatic extension change

shopt -s globstar
for f in **/*.uavcan; do mv "$f" "${f%uavcan}dsdl"; done

* Cyphalize

reg/udral/README.md

@@ -1,8 +1,8 @@
 # UDRAL
 
 This namespace contains data type definitions, network service specifications, usage guidelines and best practices,
-and other documentation relating to the UAVCAN DRone Application Layer Specification (UDRAL).
-The specification defines the application layer for applying UAVCAN v1 to (un)manned aerial vehicles,
+and other documentation relating to the Cyphal drone application layer (UDRAL) specification.
+The specification defines the application layer for applying Cyphal to (un)manned aerial vehicles,
 including multirotors and fixed wing aircraft.
 
 The definitions are contained in two namespaces:
@@ -25,7 +25,7 @@ UDRAL is designed per the following goals:
 
 The user of this standard is advised to get familiar with the basic principles of service-oriented design.
 As a quick primer, [read Wikipedia](https://en.wikipedia.org/wiki/Service-oriented_architecture).
-For a more in-depth review, please read the [UAVCAN Guide](https://uavcan.org/guide).
+For a more in-depth review, please read the [Cyphal Guide](https://opencyphal.org/guide).
 
 The value of this or any other interoperability standard is in enabling compatible, composable,
 and extensible complex systems.
@@ -67,21 +67,21 @@ Being forward-looking, this design is optimized for transports that offer
 the data rates of at least ~4 Mbps and the MTU of at least ~64 bytes.
 It is expected that in the foreseeable future all new applications will be leveraging transports whose
 data transfer capability is at this level or higher
-(this includes, for example, UAVCAN/UDP over Ethernet, UAVCAN/CAN over CAN FD, UAVCAN/serial over RS-422 or USB, etc).
+(this includes, for example, Cyphal/UDP over Ethernet, Cyphal/CAN over CAN FD, Cyphal/serial over RS-422 or USB, etc).
 
-Note that UAVCAN v1 allows integrators to selectively disable irrelevant publications by reconfiguring the
+Note that Cyphal allows integrators to selectively disable irrelevant publications by reconfiguring the
 appropriate port-ID registers (`uavcan.pub.*.id`), which is a powerful bandwidth management tool.
 
 Applications relying on Classic CAN (maximum data rate 1 Mbps, MTU 8 bytes) can still deploy these network services,
 but the designer needs to be aware that most transfers will be multi-frame transfers and the resulting bus utilization
 may be comparatively high.
 Multi-frame transfers are not expected to cause performance issues because the official
-UAVCAN implementation libraries are optimized for handling multi-frame transfers efficiently.
+Cyphal implementation libraries are optimized for handling multi-frame transfers efficiently.
 
 The following resources are provided to help the integrator analyze bandwidth usage:
 
-- [UAVCAN/CAN bandwidth validation: Classic CAN](https://docs.google.com/spreadsheets/d/1zjpdPfmBf9oje2qjLYddlhFfkaQuTJ-VvQjHxzITils/edit)
-- [UAVCAN/CAN bandwidth validation: CAN FD](https://docs.google.com/spreadsheets/d/1iK0MegMuEC55c-zTW6ssWhrA_sGUuSlT0S26xv5gytE/edit)
+- [Cyphal/CAN bandwidth validation: Classic CAN](https://docs.google.com/spreadsheets/d/1zjpdPfmBf9oje2qjLYddlhFfkaQuTJ-VvQjHxzITils/edit)
+- [Cyphal/CAN bandwidth validation: CAN FD](https://docs.google.com/spreadsheets/d/1iK0MegMuEC55c-zTW6ssWhrA_sGUuSlT0S26xv5gytE/edit)
 
 ## Typical applications
 
@@ -118,16 +118,16 @@ which may as well be published by a mocap rig.
 
 ### Port name prefixes
 
-In UAVCAN, the name of a port (i.e., subject or RPC-service) defines the names of related registers
+In Cyphal, the name of a port (i.e., subject or RPC-service) defines the names of related registers
 as described in the documentation for the standard RPC-service `uavcan.register.Access`.
 For instance, a node that publishes to the subject named `measurement` would have registers named
 `uavcan.pub.measurement.id` and `uavcan.pub.measurement.type` (among others).
 
-> N.B.: Contrary to other protocols, in UAVCAN, the name of a port is a node-local property that does not affect
+> N.B.: Contrary to other protocols, in Cyphal, the name of a port is a node-local property that does not affect
   network exchanges over that port.
   This means that nodes can publish/subscribe to a port even if they name it differently
   as long as they are configured to use the same numerical port-ID.
-  The details are given in the UAVCAN Specification.
+  The details are given in the Cyphal Specification.
 
 Network service specifications given here under the `service` namespace provide the recommended names for
 every defined port.
@@ -249,7 +249,7 @@ The design allows this by adding an optional register per port that contains a s
     uavcan.srv.PORT_NAME.type_sig
 
 Where `PORT_NAME` is a placeholder defined in the
-[documentation for `uavcan.register.Access`](https://github.com/UAVCAN/public_regulated_data_types/blob/b02e6899a319ddefbab41b820d167c95dd00174d/uavcan/register/384.Access.1.0.uavcan#L136-L139).
+[documentation for `uavcan.register.Access`](https://github.com/OpenCyphal/public_regulated_data_types/blob/b02e6899a319ddefbab41b820d167c95dd00174d/uavcan/register/384.Access.1.0.uavcan#L136-L139).
 For example: `uavcan.sub.main_drive.setpoint.type_sig`
 
 Example signature would look like `(u12{u8}a5[f16]=i8)`, and be interpreted as
@@ -267,7 +267,7 @@ Sample proof-of-concept code that generates type string from DSDL and compares t
 
 ## Conventions
 
-- Conventions defined in the UAVCAN Specification shall be followed.
+- Conventions defined in the Cyphal Specification shall be followed.
 
 - All physical quantities except error variance should be represented as `float32` by default.
   Error variance and covariance matrices should use `float16` by default.

reg/udral/physics/kinematics/README.md

@@ -18,7 +18,7 @@ Cartesian approximation is infeasible.
 Other than using a different coordinate system to express position, the data types are equal to their Cartesian
 counterparts and are to some extent interchangeable thanks to the structural subtyping/aliasing features of DSDL.
 
-See UAVCAN Specification chapter "Application layer" for the applicable conventions.
+See Cyphal Specification chapter "Application layer" for the applicable conventions.
 Key excerpts:
 
 - For world fixed frames, the North-East-Down (NED) right-handed notation is preferred:

reg/udral/service/actuator/common/sp/_.0.1.uavcan → reg/udral/service/actuator/common/sp/_.0.1.dsdl

@@ -3,15 +3,15 @@
 # Actuators are expected to subscribe using the largest array type. Publishers would choose the array type
 # depending on the number of actuators in the group. The actuators would be expecting the largest array type,
 # where the missing elements will be zero-filled automatically by the protocol stack thanks to the
-# Implicit Zero Extension Rule (refer to the UAVCAN Specification for details).
+# Implicit Zero Extension Rule (refer to the Cyphal Specification for details).
 #
 # The physical meaning of the values contained in the array is defined by the respective actuator service specification.
 # If ratiometric control is used, then the range should be [-1, +1].
 #
 # It follows that a standalone actuator (that is not a member of any group) is just a special case of a group of 1,
 # where the setpoint type is a single scalar.
 #
-# The UAVCAN Specification might benefit from supporting flexible array fields to avoid having to deal with redundant
+# The Cyphal Specification might benefit from supporting flexible array fields to avoid having to deal with redundant
 # similar types: https://en.wikipedia.org/wiki/Flexible_array_member, so that instead of having multiple types that
 # differ only in size of the array fields, one could just say `float16[0] value` such that the size of zero indicates
 # that the array is a flex array.

reg/udral/service/actuator/servo/_.0.1.uavcan → reg/udral/service/actuator/servo/_.0.1.dsdl

@@ -126,6 +126,6 @@
 #                               positive| negative
 #                               power   | power
 #
-# An example implementation is available at https://github.com/UAVCAN/demos
+# An example implementation is available at https://github.com/OpenCyphal/demos
 
 @extent 0

reg/udral/service/battery/Status.0.2.uavcan → reg/udral/service/battery/Status.0.2.dsdl

@@ -5,7 +5,7 @@ reg.udral.service.common.Heartbeat.0.1 heartbeat
 # that the availability of energy in the battery is critical for the safe operation of the vehicle, which is usually
 # not the case. For example, if the vehicle is equipped with several batteries that are discharged in series, one
 # after another, the depletion of energy in the first battery is not a fault condition and it should not be reported
-# as such. This follows from the good service design principles reviewed in https://uavcan.org/guide.
+# as such. This follows from the good service design principles reviewed in https://opencyphal.org/guide.
 #
 # The readiness state depicts the ability of the battery (or its power electronics) to deliver full rated power
 # and whether the overdischarge protections are active.

uavcan/internet/udp/500.HandleIncomingPacket.0.1.uavcan → uavcan/internet/udp/500.HandleIncomingPacket.0.1.dsdl

@@ -1,4 +1,4 @@
-# This message carries UDP packets sent from a remote host on the Internet or a LAN to a node on the local UAVCAN bus.
+# This message carries UDP packets sent from a remote host on the Internet or a LAN to a node on the local Cyphal bus.
 # Please refer to the definition of the message type OutgoingPacket for a general overview of the packet forwarding
 # logic.
 #
@@ -12,7 +12,7 @@
 # It should be noted that this data type definition intentionally leaves out the source address. This is done in
 # order to simplify the implementation, reduce the bus traffic overhead, and because the nature of the
 # communication patterns proposed by this set of messages does not provide a valid way to implement server hosts
-# on the local UAVCAN bus. It is assumed that local nodes can be only clients, and therefore, they will be able to
+# on the local Cyphal bus. It is assumed that local nodes can be only clients, and therefore, they will be able to
 # determine the address of the sender simply by mapping the field session_id to their internally maintained states.
 # Furthermore, it is uncertain what is the optimal way of representing the source address for
 # client nodes: it is assumed that the local nodes will mostly use DNS names rather than IP addresses, so if there
@@ -38,7 +38,7 @@ uint8[<=309] payload
 # Effective payload. This data will be forwarded from the remote host verbatim.
 # UDP packets that contain more than 508 bytes of payload may be dropped by some types of
 # communication equipment. Refer to RFC 791 and 2460 for an in-depth review.
-# UAVCAN further limits the maximum packet size to reduce the memory and traffic burden on the nodes.
+# Cyphal further limits the maximum packet size to reduce the memory and traffic burden on the nodes.
 # Datagrams that exceed the capacity of this field should be discarded by the modem node.
 
 @extent 600 * 8

uavcan/internet/udp/500.HandleIncomingPacket.0.2.uavcan → uavcan/internet/udp/500.HandleIncomingPacket.0.2.dsdl

@@ -1,4 +1,4 @@
-# This message carries UDP packets sent from a remote host on the Internet or a LAN to a node on the local UAVCAN bus.
+# This message carries UDP packets sent from a remote host on the Internet or a LAN to a node on the local Cyphal bus.
 # Please refer to the definition of the message type OutgoingPacket for a general overview of the packet forwarding
 # logic.
 #
@@ -12,7 +12,7 @@
 # It should be noted that this data type definition intentionally leaves out the source address. This is done in
 # order to simplify the implementation, reduce the bus traffic overhead, and because the nature of the
 # communication patterns proposed by this set of messages does not provide a valid way to implement server hosts
-# on the local UAVCAN bus. It is assumed that local nodes can be only clients, and therefore, they will be able to
+# on the local Cyphal bus. It is assumed that local nodes can be only clients, and therefore, they will be able to
 # determine the address of the sender simply by mapping the field session_id to their internally maintained states.
 # Furthermore, it is uncertain what is the optimal way of representing the source address for
 # client nodes: it is assumed that the local nodes will mostly use DNS names rather than IP addresses, so if there

uavcan/internet/udp/8174.OutgoingPacket.0.1.uavcan → uavcan/internet/udp/8174.OutgoingPacket.0.1.dsdl

@@ -48,7 +48,7 @@
 # be exhausted, it is allowed to remove old NAT entries earlier, following the policy of least recent use.
 #
 # Having received a UDP packet from a remote host, the modem node would check the NAT table in order
-# to determine where on the UAVCAN bus the received data should be forwarded to. If the NAT table
+# to determine where on the Cyphal bus the received data should be forwarded to. If the NAT table
 # contains no matches, the received data should be silently dropped. If a match is found, the
 # modem node will forward the data to the recipient node using the service HandleIncomingPacket.
 # If the service invocation times out, the modem node is permitted to remove the corresponding entry from
@@ -63,7 +63,7 @@
 #
 # To summarize, a typical data exchange occurrence should amount to the following actions:
 #
-#   - A local UAVCAN node broadcasts a message of type OutgoingPacket with the payload it needs
+#   - A local Cyphal node broadcasts a message of type OutgoingPacket with the payload it needs
 #     to forward. If the node expects the remote host to send any data back, it sets the masquerading flag.
 #
 #   - Every modem node on the bus receives the message and performs the following actions:
@@ -112,10 +112,10 @@ uint8[<=45] destination_address
 # node should take care to channel all traffic arriving at the opened port from any source to the node that
 # requested masquerading.
 # The full domain name length may not exceed 253 octets, according to the DNS specification.
-# UAVCAN imposes a stricter length limit in order to reduce the memory and traffic burden on the bus: 45 characters.
+# Cyphal imposes a stricter length limit in order to reduce the memory and traffic burden on the bus: 45 characters.
 # 45 characters is the amount of space that is required to represent the longest possible form of an IPv6 address
 # (an IPv4-mapped IPv6 address). Examples:
-#   "forum.uavcan.org"                              - domain name
+#   "forum.opencyphal.org"                          - domain name
 #   "192.168.1.1"                                   - IPv4 address
 #   "2001:0db8:85a3:0000:0000:8a2e:0370:7334"       - IPv6 address, full form
 #   "2001:db8:85a3::8a2e:370:7334"                  - IPv6 address, same as above, short form (preferred)
@@ -132,7 +132,7 @@ uint8[<=260] payload
 # Effective payload. This data will be forwarded to the remote host verbatim.
 # UDP packets that contain more than 508 bytes of payload may be dropped by some types of
 # communication equipment. Refer to RFC 791 and 2460 for an in-depth review.
-# UAVCAN further limits the maximum packet size to reduce the memory and traffic burden on the nodes.
+# Cyphal further limits the maximum packet size to reduce the memory and traffic burden on the nodes.
 
 @extent 600 * 8
 @assert _offset_ % 8 == {0}

uavcan/internet/udp/8174.OutgoingPacket.0.2.uavcan → uavcan/internet/udp/8174.OutgoingPacket.0.2.dsdl

@@ -48,7 +48,7 @@
 # be exhausted, it is allowed to remove old NAT entries earlier, following the policy of least recent use.
 #
 # Having received a UDP packet from a remote host, the modem node would check the NAT table in order
-# to determine where on the UAVCAN bus the received data should be forwarded to. If the NAT table
+# to determine where on the Cyphal bus the received data should be forwarded to. If the NAT table
 # contains no matches, the received data should be silently dropped. If a match is found, the
 # modem node will forward the data to the recipient node using the service HandleIncomingPacket.
 # If the service invocation times out, the modem node is permitted to remove the corresponding entry from
@@ -63,7 +63,7 @@
 #
 # To summarize, a typical data exchange occurrence should amount to the following actions:
 #
-#   - A local UAVCAN node broadcasts a message of type OutgoingPacket with the payload it needs
+#   - A local Cyphal node broadcasts a message of type OutgoingPacket with the payload it needs
 #     to forward. If the node expects the remote host to send any data back, it sets the masquerading flag.
 #
 #   - Every modem node on the bus receives the message and performs the following actions:
@@ -110,10 +110,10 @@ uint8[<=45] destination_address
 # node should take care to channel all traffic arriving at the opened port from any source to the node that
 # requested masquerading.
 # The full domain name length may not exceed 253 octets, according to the DNS specification.
-# UAVCAN imposes a stricter length limit in order to reduce the memory and traffic burden on the bus: 45 characters.
+# Cyphal imposes a stricter length limit in order to reduce the memory and traffic burden on the bus: 45 characters.
 # 45 characters is the amount of space that is required to represent the longest possible form of an IPv6 address
 # (an IPv4-mapped IPv6 address). Examples:
-#   "forum.uavcan.org"                              - domain name
+#   "forum.opencyphal.org"                          - domain name
 #   "192.168.1.1"                                   - IPv4 address
 #   "2001:0db8:85a3:0000:0000:8a2e:0370:7334"       - IPv6 address, full form
 #   "2001:db8:85a3::8a2e:370:7334"                  - IPv6 address, same as above, short form (preferred)

uavcan/metatransport/ethernet/EtherType.0.1.uavcan → uavcan/metatransport/ethernet/EtherType.0.1.dsdl

@@ -1,5 +1,5 @@
 # Standard EtherType constants as defined by IEEE Registration Authority and IANA.
-# This list is only a small subset of constants that are considered to be relevant for UAVCAN.
+# This list is only a small subset of constants that are considered to be relevant for Cyphal.
 
 uint16 value
 

uavcan/metatransport/serial/Fragment.0.2.uavcan → uavcan/metatransport/serial/Fragment.0.2.dsdl

@@ -1,8 +1,8 @@
 # A chunk of raw bytes exchanged over a serial transport. Serial links do not support framing natively.
 # The chunk may be of arbitrary size.
 #
-# If this data type is used to encapsulate UAVCAN/serial, then it is recommended to ensure that each message
-# contains at most one UAVCAN/serial transport frame (frames are separated by zero-valued delimiter bytes).
+# If this data type is used to encapsulate Cyphal/serial, then it is recommended to ensure that each message
+# contains at most one Cyphal/serial transport frame (frames are separated by zero-valued delimiter bytes).
 
 uint12 CAPACITY_BYTES = 2048
 uint8[<=CAPACITY_BYTES] data

uavcan/node/430.GetInfo.1.0.uavcan → uavcan/node/430.GetInfo.1.0.dsdl

@@ -7,15 +7,15 @@
 ---
 
 Version.1.0 protocol_version
-# The UAVCAN protocol version implemented on this node, both major and minor.
+# The Cyphal protocol version implemented on this node, both major and minor.
 # Not to be changed while the node is running.
 
 Version.1.0 hardware_version
 Version.1.0 software_version
 # The version information shall not be changed while the node is running.
 # The correct hardware version shall be reported at all times, excepting software-only nodes, in which
 # case it should be set to zeros.
-# If the node is equipped with a UAVCAN-capable bootloader, the bootloader should report the software
+# If the node is equipped with a Cyphal-capable bootloader, the bootloader should report the software
 # version of the installed application, if there is any; if no application is found, zeros should be reported.
 
 uint64 software_vcs_revision_id
@@ -29,7 +29,7 @@ uint8[16] unique_id
 # The vendor shall ensure that the probability of a collision with any other node UID globally is negligibly low.
 # UID is defined once per hardware unit and should never be changed.
 # All zeros is not a valid UID.
-# If the node is equipped with a UAVCAN-capable bootloader, the bootloader shall use the same UID.
+# If the node is equipped with a Cyphal-capable bootloader, the bootloader shall use the same UID.
 
 @assert _offset_ == {30 * 8}
 # Manual serialization note: only fixed-size fields up to this point. The following fields are dynamically sized.

uavcan/node/434.GetTransportStatistics.0.1.uavcan → uavcan/node/434.GetTransportStatistics.0.1.dsdl

@@ -6,11 +6,11 @@
 ---
 
 uint8 MAX_NETWORK_INTERFACES = 3
-# UAVCAN supports up to triply modular redundant interfaces.
+# Cyphal supports up to triply modular redundant interfaces.
 
 IOStatistics.0.1 transfer_statistics
-# UAVCAN transfer performance statistics:
-# the number of UAVCAN transfers successfully sent, successfully received, and failed.
+# Cyphal transfer performance statistics:
+# the number of Cyphal transfers successfully sent, successfully received, and failed.
 # The methods of error counting are implementation-defined.
 
 IOStatistics.0.1[<=MAX_NETWORK_INTERFACES] network_interface_statistics