Adds a Zenoh Implementation Designed to work with zenoh-ros1-bridge #209
Conversation
|
Description on this looks pretty sus, I don't know... |
|
lol, sorry you looked so fast, I started putting this up for review and then decided to add services as well. Close your eyes for a bit |
|
Okay I hit a bug when dealing with services (#210) so I'm going to punt on that and go ahead and merge this. |
|
#210 has unblocked the services impl for this, so I'm plowing forward with adding that and cleaning this up. |
|
@ssnover Okay this is really ready for a review now. I haven't added CI tests yet, but have tested everything manually for first pass. Note: this ONLY works with zenoh-bridge-ros1 and not "generic zenoh". |
| @@ -730,7 +730,7 @@ pub fn generate_rust_ros_message_definitions( | |||
| } | |||
| Ok(()) | |||
| }) | |||
| .collect::<Result<_, Error>>()?; | |||
| .collect::<Result<(), Error>>()?; | |||
There was a problem hiding this comment.
Note these changes were the result of new Rust lint about deprecation of implicit conversion of the never type to null type ! -> ()
…id a lot of byte shuffling
Is it possible to make that configurable later, be able to turn off the zenoh-bridge-ros1 features? (I saw the topic mangling but I'm curious what else is involved) |
There are only two things that really tie this to zenoh-bridge-ros1: the topic mangling, and the serde_rosmsg usage for serializing and de-serializing. So it is definitely possible to make a more generic version, but at that point I'm not sure why someone isn't directly using the Zenoh API? As far as I know no-one in the Zenoh ecosystem is using the TCPROS serialization format for message passing (and frankly I wouldn't recommend it). I built this mostly to work around this issue: eclipse-zenoh/zenoh-plugin-ros1#131. |
Description
Adds a roslibrust_zenoh crate (not yet published) that provides an implementation of the TopicProvider trait for working with zenoh_ros1_bridge.
Fixes
Checklist