Skip to content
This repository has been archived by the owner on Jun 3, 2019. It is now read-only.

i2c support #31

Open
beriberikix opened this issue Mar 10, 2016 · 1 comment
Open

i2c support #31

beriberikix opened this issue Mar 10, 2016 · 1 comment

Comments

@beriberikix
Copy link

Just watched the presentation from ROSCon 2015 Hamburg, which mention TTL UART is a future goal. What about i2c? That seems like a good target as most MCUs have onboard i2c and it is a great solution for multi-node systems (RS485, also mentioned, is great but less abundant in non-automation situations.)

@codebot
Copy link
Member

codebot commented Mar 12, 2016

Hi @beriberikix , yeah i2c and uarts and other lower-level, non-natively-internetworkable physical layers (including, perhaps most commonly, USB) are definitely in the wish-list and the informal longer-term roadmap. It will be a bit tricky because these protocols tend to have smaller physical frame sizes and/or smaller logical datagrams than Ethernet/UDP4, which was what RTPS was originally designed for. So there will have to be some adaptation of the protocol and generic forwarding / routing work on whatever nearby host can actually reach other networks. But I think the principles of RTPS have a lot of running room and it will be fabulous to adapt them to lower-cost, simpler physical layers. But for now I'm working on finishing up a near-total rewrite of fastRTPS which follows the UML of the specification much more closely, and is generally much cleaner code. This is currently shown as the "history_cache" branch in this repo. Once that gets put back together (it's getting close...) and our near-term RTPS-over-UDP4 needs are handled, it will be fun to do some blue-sky dreaming about how to adapt this stuff to other physical layers.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants