Weekly dev call - Meeting notes

Development & Maintenance
5

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.

6

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)
7

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
8

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.
9

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.
10

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
11

Agenda/Notes 12.12.2018

Present (?)

12

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.
13

Agenda 16.01.2019

14

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.
15

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).
16

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.
17

Notes 13.06.2019

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

18

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.

19

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?

(Abraham)

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

https://en.cppreference.com/w/cpp/memory/allocator

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.

Pavel

1 Like
20

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?

21

You are certainly not alone in that boat :ship:

The framing logic of high-overhead transports like UDP is a little different from CAN; they use simpler and more robust transfer reassembly policies which are hard to generalize in a manner compatible with CAN, so I doubt that the idea of building a robust multi-transport implementation for embedded systems is feasible. My PyUAVCAN rewrite is multi-transport capable, but then again it’s ~20k LoC large and it’s not yet quite finished.

I think I should put together a brief post sometime soon to shed some light onto PyUAVCAN and implementations of alternative transports.

22

Notes 10/30/19

Survey

The UAVCAN team is currently working on a Survey with the goal to understand what type of adopting vendors are already in the ecosystem, we are hopefully going to capture feedback on v0, v1, and the migration path.

Question areas that the call attendees think we should implement:

  • CAN bootloader, and Security around that bootloader
  • Migration guide
  • Do you already have a v0 enabled product
  • Are you familiar with UAVCAN v1.0?

NXP presented their BMS design

NXP presented their UAVCAN conversion board

NXP is working on a Development Board reference design, that will be sold very low costs, this is a perfect entry point for devs into our project.

Ramón; I think we should Identify and list UAVCAN hardware that is already out there.

Project funding

The UAVCAN team has identified a developer that can assist in the integration of v1 with PX4 and project Yukon, the team will create a value proposition document and present to vendors.

The goal is to get funding to bring those projects to the finish line.

What’s the ask, how much money, what’s the benefit, what they are going to do

Action: ramón work on value proposition

1 Like
23

Notes 11/06/19

Pavel: Had a prominent discussion with the APM team on v1 adoption. They are ready for us to let them know when we are ready for them to implement.

Scott: Just writing unit-tests for C++ structure generation in Nunavut. Will have PR this week and then move on to generating (de)serialization logic in Nunavut. These types and (de)serializers are provided to libuavcan where I will consume in that project’s media layer.

Ramon: UAVCAN v1 Sponsorship Value Prop doc ETA Friday. Survey will be scheduled on the next Dronecode newsletter.

Survey (updated)

Core team covered the main topics, needs one last pass from @mrpollo. This is scheduled to appear on the latest Dronecode newsletter first week of December.

V1 Project Funding

Core team met over the weekend and defined the value-prop for supporting vendors, we are waiting for @mrpollo to give form to document.

1 Like
24

Notes 11/27/19

@pavel.kirienko

  • ArduPilot will incorporate v1.0 with v0 compatibility, the dev team is on board with v1.0
  • Survey, so far they confirm our understanding of the industry
  • Working on the transport layer chapter to the spec (last change to doc) nothing drastic
  • Collaborating with Auterion to enable distributed avionics with UAVCAN

@scottdixon

  • On vacations (holiday)
  • Nunavut refactor to support .ini style configuration
  • Finishing serialization logic for CPP
  • C++ requirements for libuavcan are not set in stone but the following can be assumed at this point:
    • requires C++11
    • has minimal requirements from the standard library including:
      • standard integer types
      • type_traits, static_assert, and various compile-time utilities to support templates and TMP
      • std::unique_ptr (which does not require an allocator) but mostly this will be used internally for RAII patterns.
      • std::vector but don’t panic: we will provide allocators for this and any other STL construct we use that needs an allocator. These allocators will have O(1) complexity and will use statically (i.e. compile-time) allocated memory pools, however, the allocators will also be optional so you will be able to fall back to a heap-based allocator if you want. That said, so far we only plan on using std::vector with allocators.
    • RTTI will not be used. Since dynamic_casts will not be allowed within libuavcan compiling with this enabled should have no effect on its internal correctness.
    • exceptions will be optional (i.e. we will provide exception-safe logic but will also allow compiling with -fno-exceptions with no loss of functionality or correctness).
    • v1 will be header-only so you will not have to worry about the ABI.

@iain.galloway

  • Blog post on NXP blog, might need to post on Dronecode instead
1 Like