UAVCAN/CAN Physical Layer SIG guidelines

This thread is to coordinate the work on the UAVCAN/CAN Physical Layer standard (UCANPHY).

Background

The original UAVCAN v0 Specification contains chapter “Hardware design recommendations” that is not retained in v1. The reasons for its removal are summarized by @scottdixon as follows:

[T]he physical layer specification for CAN transports is significantly less mature than the rest of this specification and is also the most difficult layer to standardize in generic terms. Proper functioning of the CAN data-link layer requires properly designed electrical busses with properties specific to the physical dimensions of a vehicle, the topology of the network, the number of transceivers connected to the network, the location of the transceivers in relation to each other, and the electrical properties of each transceiver. As high data-rate variants like CAN-FD 1/5Mbs are deployed this electrical engineering will become even more important even for very small CAN busses. Because of this we are removing the physical layer specification from the core document but reserve the right to create sibling documents that standardize physical UAVCAN networks based on vehicle morphology and supported transports.

The most recent edition of this chapter is available in the alpha version of the UAVCAN Specification (near the end of the document):

Objectives

This SIG will develop, and then maintain for an indefinite period, an open and royalty-free standard based on the aforementioned chapter that defines physical layer connectivity conventions for UAVCAN/CAN networks in robotics and unmanned aerial vehicles (drones). Due to shared underlying principles and common concepts, the resulting standard may be applicable (perhaps to a limited extent) in other types of systems such as low-cost space vehicles (e.g., CubeSats) and manned aviation, which is to be encouraged as long as such widening of the scope is not in contradiction with the main objective of the SIG.

Both Classic CAN and CAN FD are within the scope of this SIG. Inclusion of CAN XL is optional.

The main work product of this SIG is a LaTeX document maintained in a private repository at https://github.com/UAVCAN. Every revision of the document will be available to the general public via the main UAVCAN website or a similar point of distribution.

Organization

The term “open”, as used in “open standard” above, denotes that the final standard is to be accessible to the general public under a permissive license on a royalty-free basis. Despite the final product being available to everyone free of charge, participation in its development process will be limited only to the members of the UAVCAN Consortium. This move is intended to reduce the workload on the contributors, eliminate random opinions from the conversation, and incentivize paid membership in the Consortium which helps us sustain the project. Observe that open-source projects and non-profits are entitled to free membership.

The discussion of the standard will be conducted chiefly in the closed category of this forum. The forum will also be used to facilitate voting. Any member of the UAVCAN Consortium is allowed to cast up to 1 (one) vote (this implies that representatives should internally select one delegate who is to cast the vote for the represented SIG participant). Besides the Consortium members, the two core developers of the protocol (@pavel.kirienko and @scottdixon) are assigned one vote each. The detailed rules are to be defined and agreed upon on an ad-hoc basis per voting session.

@consortium let me know if there are any suggestions regarding the proposed workflow. I am planning to set up the repo to kickstart the work once we agreed on the policy.

I fundamentally disagree with your proposed development approach. :man_shrugging:
Community engagement and collaborative development is not something to be feared: it should be embraced and encouraged.

1 Like