Weekly dev call - Meeting notes

This topic is only for collaborating on notes from the weekly dev call.

There will only be one post per meeting.

  • It will be created before the meeting, and edited several times.
  • Feel free to edit in items on the agenda.
  • After the meeting, feel free to edit in your notes under the agenda item, but try to make them coherent with already existing notes.
  • Please refrain from adding other posts or using this thread for anything else as it will quickly clutter the meeting notes.

For any questions about topics discussed at the dev call (or other feedback on the process of creating these notes), please create a new topic.

1 Like

Agenda/Notes 08.10.2018

Present (3)

No agenda yet:

The Stockholm summit post is important:

The code compatibility issue is the main unresolved issue and needs to be resolved:

Agenda/Notes 15.10.2018

Present (3)

General notes:

  • Pavel is a little bit behind on spec work. Will finish it soon.

Pyuavcan needs update

  • Pavel will do it.
  • We need someone for doing front end work on the gui tool

Protocol namespace PR should be smaller.

  • Pavel will remove a lot of the namespace.
  • Kjetil will review
  • Scott will catch up

Agenda/Notes 22.10.2018

Present (3)

Review the massive DSDL PR one last time.

  • Scott need to add final comments
  • And then everyone need to take one last review

There is a new DSDL Parser in Python (https://github.com/UAVCAN/pydsdl)

  • (Pavel) Can we remove the Rust parser?
    (Kjetil) No, currently adding functionality for using dynamic DSDL in Uavcan.rs

Unresolved questions for protocol v1.0:

Sort priority (uavcan protocol -> DSDL protocol -> dsdl definitions)

  • It might help us start implementing stuff sooner.

Agenda/Notes 29.10.2018

Kjetil (the great note taker) missed the meeting due to daylight saving time, please edit in notes if you have some.

Agenda/Notes 05.11.2018

Present (2)

Code compatibility (The case for code compatibility)

  • Pavel has commented.
  • Kjetil agree to not having code compatibility on minor version
  • We will discuss having code compatibility on patch version next week

DSDL const evaluation and assertions (New DSDL directive for simple compile-time checks)

  • Kjetil will write the DSDL chapter
  • We will discuss kjetils draft next week
  • Kjetil will read the restrictions to DSDL and comment on them.

Concerning the meeting.

  • After daylight saving the meeting time is inconvinient for Kjetil. Let’s reschedule (Weekly dev call)

Agenda/Notes 12.11.2018

Present (3)

News on Code Compatibility (The case for code compatibility) ?

  • Postpone discussion

Rescheduling of the meeting (Weekly dev call)

  • Meetings are now on Wednesdays 18:00 UTC

Are these kind of agenda/notes good enough or do we want each meeting to have a topic of its own?

  • Not touched on

Challenges of timekeeping and timestamping

  • Read up on discussion and comment before next meeting

Review of chapters 1 & 2

  • Read up on discussion and comment before next meeting

SI namespace design

  • Read up on discussion and comment before next meeting

Transfer priority level mnemonics

  • Read up on discussion and comment before next meeting

Agenda/Notes 21.11.2018

Note: American Holiday, Scott will not be able to attend

Present (2)

Discuss statically allocated IDs in the application specific range (On standards and regulation)

  • No progression beyond the current discussion
  • Think about how a conclusion can be reached and discuss next meeting.

Touch on SI design (SI namespace design)

  • Kjetil is worried about the current design, but has no constructive suggestions to improve it.

Timestamping issues (On timestamping, https://github.com/UAVCAN/dsdl/pull/53)

  • If 56 bit timestamps are used every message (continging a float32) will be at least 12 bytes.
  • The maximum length of CAN 2.0B messages are 8 byte, 24 bit timestamp should be used to avoid all messages being muli frame.

DSDL versioning

  • Kjetil is worried about micro protocols using different datatypes.
  • Been thinking about a different versioning scheme, will be concertized and announced before next meeting.

Agenda/Notes 28.11.2018

Present (5)

Discuss statically allocated IDs in the application specific range (On standards and regulation)

  • Reached a conclusion of allowing static IDs in the application specific range.

DSDL versioning alternative (Simpler and better DSDL versioning)

  • Remove any mention of github and git repos (should be interchangable +devops - spec)
  • Pavel might think it’s a bit more complex
  • Discuss more next week

Chapter 1 and 2 of the Specification (https://github.com/UAVCAN/specification/pull/32)

  • Pavel agrees with every point from the last review, will fix and hopefully merge soon.

Implementations Schedule

  • Scott wants to discuss v1 schedules (again)
  • We should do a community announcement where we are in the process.
  • Our highest priority is to resolve DSDL versioning discussion.

Agenda/Notes 05.12.2018

Present (3)

DSDL versioning alternative (Simpler and better DSDL versioning)

  • We should make the proposal open enough to switch from per datatype to per namespace.

Sum up of schedule

  • Pavel will implement SI Monday and we will look on it
  • Review transport layer chapter

Agenda/Notes 12.12.2018

Present (?)

Notes 19.12.2018

  • @iain.galloway is looking into recruiting help from NXP.
  • DSDL v1.0-alpha is virtually ready, one last PR remains: https://github.com/UAVCAN/dsdl/pull/60
  • Work on the spec is ongoing, chapters 3 and 5 are not yet ready; ETA end of December.
  • @scottdixon is going to start on the GUI architecture and is currently working on a full rewrite of libuavcan (while borrowing stuff from the existing implementation).
  • We should find a free or a low-cost tool for MISRA enforcement for libuavcan and libcanard.

Agenda 16.01.2019

Notes 06.02.2019

  • BDFL Pavel out sick. @scottdixon joined the room but at 10:15 left with no others having joined.
  • @scottdixon made some progress on getting the libuavcan bluesky branch to generate and build objects from dsdl definitions but ran into internal errors coming out of the RegularGrammarMatcher object in pydsdl. Could use some help from @pavel.kirienko to understand this issue.

Notes 13.02.2019

  • @scottdixon updated the old libuavcan_dsdlc to use PyDSDL, which is available for an early review (where though). The next step is to rewrite it to better accommodate the new PyDSDL API (which differs drastically from pyuavcan’s).
  • @scottdixon is going to talk about his UAVCAN-related work on a top-secret internal event which we may or may not be able to attend remotely. :male_detective:
  • @kjetilkjeka found a guy who is brave enough to help update libcanard and its DSDL transpiler to support UAVCAN v1.0.
  • we cordially extend our invitation to @Linjieqiang to join our next dev call, which will take place at UTC 18:00 Feb 20. The new GUI tool will be discussed at length (among other things).
  • @pavel.kirienko keeps annoying his colleagues by calling from weird noisy places with no decent Internet connection. He will be back in his lab tomorrow though, enjoying a total lack of strangers and a robust high-speed optical link.
  • @pavel.kirienko and his web guy who is to stay incognito have put together a website: PR preparations for the upcoming UAVCAN v1.0 release: new website, new logo. Time was well spent drafting up the new logo (to which everyone is welcome to submit their constructive criticism).

Notes 06.03.2019

Present: @scottdixon, @Zarkopafilis, @pavel.kirienko. @Linjieqiang was experiencing connection issues and could not join.

  • @pavel.kirienko continues his glacially slow work on the last remaining chapter of the new specification – the DSDL chapter.
  • Still no consensus on the logo issue: PR preparations for the upcoming UAVCAN v1.0 release: new website, new logo
  • On Yukon:
    • @scottdixon and @Zarkopafilis agreed that the decision on whether we should use Electron should be postponed until some minimal functionality is implemented.
    • Vue has been chosen for the client side (JS).
    • Flask has been chosen for the server side (Python 3).
    • @pavel.kirienko has to accelerate his work on pyuavcan, otherwise, Yukon development might stall soon because of the lack of the underlying UAVCAN v1.0 implementation.
    • @Zarkopafilis may be available to draft up a REST API specification soon; everyone should look out for his thread on the forum.
  • @scottdixon continues his work on libuavcan and pydsdlgen.

Notes 13.06.2019

Today we talked about Yukon – the new GUI tool. @Zarkopafilis has posted the summary over at Yukon UI & Rest API.

Sorry I couldn’t make it today. Updates on my end: working to get an initial version of pydsdlgen into the UAVCAN github org as a repo. Most of the big kinks have been worked out. Just writing tests now.

Notes 10/02/2019

Pavel - PR for UDP transport completed. To demonstrate

Ensure no design decisions which prevent the implementation

Abraham -

Studying ROS - more aware of what UAVCAN framework brings to the table

Seeing the similarities. Big picture is stack over UDB. Robot with Linux

Conceptual similarities between UAVCAN and ROS.

E.g software engineering concepts - publish subscribe in both.

CAN in physical layer - ROS by software services.

Details are in UAVCAN tutorials.

Higher level abstraction by UAVCAN.

Progress/Questions problems with S32K driver?


Only part left is ‘write’ function Lib UAVCAN -

MIT license (original) - or BSD 3 clause

  • These are not compatible at the moment.
  • Looks like Licanse text in header sets the standard - NXP seems to be using BSD three clause.

Abraham -

Next validate code in each function.

Make it portable to all S32K family

S32K 146 and 148 chips have two interfaces. Most have one.

Will make driver work on all .

Note issue:


static std::deque<CAN::Frame> frame_ISRbuffer;

Should use memory allocator as provided by the library. Now using shared heap - fragmentation and non-deterministic.

Must provide an allocator for the container. This is presently Incompatible


Scott has a start on the memory allocator:

Pavel - use this allocator please. No examples but look at this.libuavcan/memory.hpp at 1e0d947132b565601612f7cae528ce31f492f9f9 · OpenCyphal/libuavcan · GitHub

Provide this type as a second template to ???

Best to keep discussion public on forum. Talk with Scott on Forum if/when you have problem.

That part of STL usage was not clear to Abraham - thanks

Think this is the only part that is making use of Dynamic allocations.


1 Like

Sorry I missed the dev call. Thanks for the notes. I’ll consume them today. I’ll spend some time looking at the s32k repo today.

MIT license is what we’ve used everywhere to date. We should stick with this if we can.

I’ve already ported the pool allocator from v0 to v1. It’s available as libuavcan::platform::memory::PoolAllocator (https://github.com/UAVCAN/libuavcan/blob/uavcan-v1.0/libuavcan/include/libuavcan/platform/memory.hpp#L203). The trick will be allowing the application to provide the static memory pool since we want the driver to accept the memory configured by the application instead of directly consuming memory itself.

As for my status: My focus now is to, again, try to get back to libuavcan_v1 serialization code generated from dsdl.

The UDP stuff is interesting to us, BTW. I had another engineer asking about it. Will we be providing support either in libcanard or in a libcanard-like (i.e. minimal) project?