Conversation
| uint32 FLAG_AUTHORITATIVE = 1 | ||
| # the PUBLISHER_ONLY bit should be set if this node only publishes data, most sensor | ||
| # nodes should set this bit | ||
| uint32 FLAG_PUBLISHER_ONLY = 2 |
There was a problem hiding this comment.
What's the purpose of FLAG_PUBLISHER_ONLY? Does it mean literally only publishes and doesn't subscribe to anything or is there some nuance (parameters, etc)?
There was a problem hiding this comment.
the idea is to distinguish between a node publishing sensor data and nodes that consume sensor data. The reason this matters is for thinks like the old GNSS Fix message. We'd like to stop sending that message to save bandwidth, but we can't do that unless we know that all nodes that consume GNSS messages understand Fix2. We don't care if (for example) a baro/compass sensor node is at the level that understands Fix2, as it doesn't consume any GNSS messages, but we do care if all the consumer nodes (flight controllers, loggers, cameras etc) understand Fix2.
So this is a deliberately broad category to classify nodes as either "publish only" or "publish and consume". That reflects the reality of how DroneCAN networks are actually used, and will allow us to push out replacement messages much more easily.
Note that while I'm using GNSS Fix/Fix2 as an example, the same principle applies to other messages, and the same distinction between nodes can be used
| # the PUBLISHER_ONLY bit should be set if this node only publishes data, most sensor | ||
| # nodes should set this bit | ||
| uint32 FLAG_PUBLISHER_ONLY = 2 | ||
| uint32 FLAG_FDCAN_4M_SUPPORT = 4 |
There was a problem hiding this comment.
Are you seeing 4Mbit as a natural boundary somewhere? I'm seeing a lot of parts capable of 2M and 5M, but it's not like I've done a survey.
Another idea could be to separate the CAN version (2.0B, CAN FD 1.0, maybe CAN XL later) and the max bit rate?
There was a problem hiding this comment.
@bugobliterator what do you think? should we support 5M? I think keeping the number of options small is good
There was a problem hiding this comment.
discussed with @bugobliterator, we think we should do 2M, 5M and 8M, with arbitration at 1M for all 3
| # the PUBLISHER_ONLY bit should be set if this node only publishes data, most sensor | ||
| # nodes should set this bit | ||
| uint32 FLAG_PUBLISHER_ONLY = 2 | ||
| uint32 FLAG_FDCAN_4M_SUPPORT = 4 |
There was a problem hiding this comment.
what about 2M, 5M? 8M is not common and requires special SIC transceivers to utilize this datarate.
There was a problem hiding this comment.
Missing BRS support. CAN-FD can be used without setting the BRS or having a different data rate.
There was a problem hiding this comment.
that is a question for @bugobliterator
note that we don't really want to support all possible combinations
There was a problem hiding this comment.
Wouldn't lack of BRS support be implicit in the bitrate flags with the supported bitrate being limited to 1M (FLAG_FDCAN_1M_SUPPORT)?
There was a problem hiding this comment.
After some discussions on Discord (my kids are laughing at me for using Discord BTW. Thanks for that) I think the best design here is to define a set of abstract, Level-1 standards and given them names. For example:
- DRONECAN_COMPAT
- DRONECAN_RELIABLE
- DRONECAN_FAST
- DRONECAN_FAST_SI
where each is defined with a separate specification for your L1 bus. This would include all of the considerations like arbitration rate, data rate, sample point, etc. My example here would optimize these settings for:
- compatibility with existing systems
- using FD (with the improved checksum) at a slow data rate and without BRS to minimize SI issues.
- using FD at a single, fixed datarate that is faster than the arbitration rate.
- using FD with Signal Improvement transceivers (CiA601-4 2.0.0) to achieve 8Mb data rates.
That said, it may introduce some complexity into firmwares to require runtime reconfiguration to a minimum supported standard. You might allow this process to simply report to the user that "node x is not compatible with this system" and provide a link to the manufacturer's reported help URL. That URL can then instruct the user on how to reconfigure the LRU into one of the four modes. This suggests you need a "can dynamically reconfigure" flag in the message.
| @@ -0,0 +1,59 @@ | |||
| # NodeCapabilities messages | |||
There was a problem hiding this comment.
It's not clear when nodes, other than the central server, should emit this message. Also, as a protocol, there's no discussion of what to do if more than one nodeID sends different capabilities with the authoritative bit set.
There was a problem hiding this comment.
different capabilities with authoritative set would have to be either a transient condition or a bug in the implementation. All the authoritative servers have the same information to work with so should come to the same result
There was a problem hiding this comment.
I think logging an error in the authoritative server if it sees persistent (more than 5s?) conflicting information would be the way to go
|
One other thing I just realized, some hardware might be able to support different FD clock rates but cannot change them at runtime (i.e. needs new firmware or needs to be configured manually). If you are on a device that is, for example, using a 4M datarate and the minimum capability negotiated is 2M what does the node do to say "I can't do that"? |
it is assumed that devices can do 1M bxCAN, as all existing devices doing DroneCAN and v0 UAVCAN must be able to do |
|
nudge |
this will allow for dynamic detection of node capabilities, and upgrade to FDCAN
tridge
force-pushed
the
pr-NodeCapabilities
branch
from
5c94d48 to
0967b2d
Compare
4 participants
this will allow for dynamic detection of node capabilities, and
upgrade to FDCAN