Comments (8)
@Guelakais the infrastruture for generating code for messages is rather complex, hence why it's not as streamlined with ros2-rust
as with other projects that just use existing message packages in other languages. We know about this issue and the ROS team as well, we've been talking with them on how to improve the user experience since we both believe that Rust will play an important role in robotics in the short future.
However, you'd still need to declare dependencies in Cargo.toml so that both colcon
and cargo
can find them. C++ doesn't have that problem because there's no packaging system for C++, but given that Rust comes with its own toolchain, the dependencies need to be duplicated. Eventually, we might be able to infer the ROS dependencies from Cargo.toml, but not sure if that's entirely feasible.
from ros2_rust.
Ok, I have a workaround for now. So you can fill the timestamp of a ros2 header correctly:
Time {
sec: (self.node.get_clock().now().nsec /10_i64.pow(9)) as i32,
nanosec: (self.node.get_clock().now().nsec %10_i64.pow(9)) as u32,
}
As you can see right here, your rclrs::Time
type collides with the builtin_interfaces::Time
type. In my opinion, a good approach would be to translate certain ros2 message types directly into rust crates to make them available for rclrs. I have already asked you how to do this and have not yet received an answer. If you do this, a possible method in the implementation for rclrs::Time could look like this
fn to_ros_msg(&self) -> builtin_interfaces::Time {
builtin_interfaces::Time {
sec: (self.nsec /10_i64.pow(9)) as i32,
nanosec: (self.nsec %10_i64.pow(9)) as u32,
}
From my point of view, this issue should definitely remain open, as timestamps are an essential resource for nodes, especially when processing sensor data. I am currently having heated discussions with someone who is using an algorithm for determining angular ranges from sensor_msgs::msg::LaserScan
messages in his node and simply refuses to look at the timestamps. The results of his node are complete rubbish. I have now set about doing this in my implementation for precisely this reason. Timestamps are essential and must adapt to the corresponding ros2 message types to ensure proper processing.
from ros2_rust.
@Guelakais do you happen to have the builtin_interfaces
repository in your workspace? If so, you'd need to remove it (or maybe even remove the entire workspace and start from scratch). The builtin_interfaces
code is now vendorized into rclrs
, which from what I gather, conflicts with the repository you have in your workspace.
In my opinion, a good approach would be to translate certain ros2 message types directly into rust crates to make them available for rclrs. I have already asked you how to do this and have not yet received an answer.
Can you paste a link to the ticket where you asked for this feature? Would be a nice addtion, though perhaps using the Into
and From
traits would be more idiomatic, and if you have time, we'd be very happy to review a PR with these changes if you submit it.
from ros2_rust.
#381
I'm beginning to think that I can't avoid a pull request. But then I would have to learn how github works...
from ros2_rust.
@esteve it occurs to me that the vendored message packages could create a lot of confusion when building the ros2_rust
repo in the same workspace as a ROS distro, which was meant to be supported as of #370.
What would you think if we put some logic into the vendoring script to check whether the Rust bindings for the messages are available in the workspace before we vendor them?
We would then install the vendored bindings in a way that they can be used as if they're the upstream bindings.
from ros2_rust.
building the corresponding Ros distribution in the same workspace as ros2 rust is, in my experience, quite extraordinary. Normally, the classic ros2 developer relies on the corresponding .deb
dependencies, which he installs via apt install ros-${ROSDISTRO}-<PACKAGENAME>
. A logic that checks how ros2 rust gets .msg
dependencies is of course always cool.
Something basic: If in doubt, you should include your dependencies in package.xml
via <depend>package</depend>
instead of any other keyword, as this exact keyword is used when using ros2 pkg create pacakge_name --dependencies package_one package_two
. Build and exec dependencies are, in my opinion, more confusing than normal <depend>
dependencies.
from ros2_rust.
@mxgrey yeah, I agree, the vendored interfaces can complicate things (this ticket is an example of that). The core issue is that we wouldn't need to this if we could get the generator included in the buildfarm. Or at least, we could do things differently.
What would you think if we put some logic into the vendoring script to check whether the Rust bindings for the messages are available in the workspace before we vendor them?
That's a good idea, it'd make things less confusing and we'd still be able to push rclrs to crates.io
from ros2_rust.
Ok, I've been dealing with this bug all evening. For some reason rclrs keeps replacing builtin_interfaces::msg::Time
with rclrs::vendor::builtin_interfaces::msg::Time
when compiling. I have already tried to include the dependency directly in Cargo.toml. Doesn't work either. I have found a script, which probably just renames all possible parts in the code when compiling. It is called vendor_interfaces.py
. This file alone probably ensures that neither the Into
trait nor the to_ros_msg
method can generate the correct type in the return. So the error is simply too deep.
from ros2_rust.
Related Issues (20)
- Check if our CI configuration is potentially causing our intermittent failures HOT 1
- Move rclrs_test into rclrs
- Investigate the rcl struct drop order HOT 4
- Failed to build depends on `builtin_interfaces` HOT 10
- Cargo can't find `Std_msgs` HOT 6
- Your own installation process crashes HOT 2
- Strange Warning by initial rclrs compilation HOT 2
- Audit drop ordering for rcl handles HOT 2
- Your tutorial is actually too complicated for beginners. HOT 5
- How to build subscribers? HOT 1
- QoS for Clients and Services HOT 6
- Prevent message packages from crates.io to be included during the build HOT 15
- Crate imports_granularity requires nightly HOT 4
- Action_msgs not findable, because of relocation from `/ros_ws/install/action_msgs/share/action_msgs/rust` to `/ros_ws/install/share/action_msgs/rust/` HOT 3
- Upgrade to Rust 1.78
- Begin Jazzy Testing HOT 2
- Improve Message Generation Documentation
- Investigate proposed alternatives to the existing message generation pipeline.
- Panic occurs when publish sequence types for Rust 1.78 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ros2_rust.