Introduction
As I’ve discussed with @pavel.kirienko, it might be a good thing to have some interesting tasks/challenges/first issues for developers that might be interested in contributing towards OpenCyphal. This post will try to address that question.
Before starting developing for OpenCyphal, it is useful to first get acquainted with the overarching architecture, as well as the different terms used within it: Node, Message, Service, Subscriber,…
A good place to start: https://opencyphal.org/
The home page answers the following questions:
- What is Cyphal?
- How do I use Cyphal?
- Why do I need Cyphal?
Then (this is taken straight from the previously mentioned home page):
First, read the Guide. To learn the technical details, read the Specification. Familiarize yourself with the regulated DSDL repository.
From personal experience: the Guide is quite dense as far as introductions go. It helps to read through it once in the beginning, and then come back to it a couple of times once you’ve gotten acquainted a bit more with the technical jargon used. (I’m trying to say: If you don’t understand 70% upon first reading - don’t panic)
From personal experience: the Specification is the final reference as far as technical specifics goes, most often you won’t need to go that far, the code is well-documented using comments, allowing one to focus on trying to understand one piece of the puzzle/protocol at a time.
From personal experience: understanding that DSDL files contain “types”, which define the I/O of a particular Node is often enough to work on most parts of Cyphal.
From personal experience: Once you’ve done some of the reading, I suggest to try to complete the Demo of Pycyphal: try to understand what each step is for, and how this could be useful when (for example) developing a UAV. (Or if you’re feeling adventurous, play with some real hardware using @aentinger’s Arduino library of Cyphal)
At this stage you might feel like you don’t have anything to contribute, however you’d be mistaken: being new to this project you could provide tangible value (sometimes referred to as PRs) by a fresh set of eyes:
- If you’re working through the Demo (or setting up an Arduino) and you come across some step that is unclear, try to:
- Understand what is missing, if you can solve the issue yourself it means you’ve learning.
- If you have figured out what the problem is: congratulations, you can submit a PR to the relevant Github repository and try to improve the documentation for the next person that comes across this issue.
- If you don’t manage to resolve the issue, don’t sweat it, it happens to the best of us: ask a question on the forum.
- Explain what you’ve tried and what your understanding of the issue is.
- (This helps the people responding to perhaps correct some mistakes notions about Cyphal you might have at this initial stage.)
- Once you’ve managed to resolve the issue, try to ask yourself: “Is there a way in which the documentation could be improved to clarify this for the next person”. If the answer is yes, feel free to submit a PR.
Now that we have this general introduction to OpenCyphal out of the way, going forward I will assume you have done some of the suggested reading, understand the high-level terms used and tried playing arround with the suggested demos. Now I will describe some tasks/challenges that might be interesting to tackle as a new contributor to OpenCyphal.
Task 1: cyraft
- Programming language:
Python - Complexity: Beginner
General description
Cyphal does not currently support named topics, however this would be an interesting feature to implement as this would allow Cyphal to serve as a communication layer between PX4 and ROS.
TODO
An initial draft version of this can already be seen here:
If you’re interested, to reach out to me (@maksim.drachov) and I will prepare some instructions on how to start and what could use further development.
Task 2: platform_specific_components
- Programming language:
C - Complexity: Intermediate (embedded)
General description
Many popular MCUs lack built-in CAN FD-capable controllers, which limits the uptake of CAN FD in new products. There is an interesting IC that could help new hardware revisions or new designs adopt CAN FD without having to port an existing codebase to a new platform: TI TCAN4550 – a single-chip CAN FD controller with a built-in 5 Mbps transceiver interfaced with the MCU via SPI:
It is also appealing price-wise, being available from DigiKey for $1.5 @ 1k pcs, which is comparable to a regular standalone CAN transceiver.
This is a very promising chip and it would be nice to have portable and reusable drivers for it.
TODO
The issue can be found here:
If you’re interested, reach out to @pavel.kirienko and he will prepare the necessary instructions.
Task 3: libcyphal
- Programming language:
C++ - Complexity: ?
- Contact person: @scottdixon
General description
TODO
Dev call
If you’re interested in helping to develop OpenCyphal, feel free to join the weekly dev call:
It takes place weekly on Friday, 17:00-18:00 GMT, here’s a calendar event:
OpenCyphal_devcall.ics (739 Bytes)