Closed OTL closed 7 years ago
What's the topic of?
There is currently an issue in the rustc_serialize
methods that I've resolved in my switch to serde
. But that's in the works currently, and should be finished hopefully soon
Hi, I want to know, is it time to try your new code now?
BTW, I'll talk about your project, rosrust, in the ROS JAPAN USERS MEETING, May 20th, Tokyo. I'm happy if I can introduce about your great software!
I've been quite busy, so the development was slow. But I merged the major changes into master, and I'll do my best to push a new release on Saturday. I'll also create another repo with a small demo project. It can't be just an example, since it requires build scripts.
In the master branch, rosrust
doesn't need any message generation. If you want to try out master:
Create a build.rs
in the root folder of your project (not the src/
), and in it:
#[macro_use]
extern crate rosrust;
rosmsg_main!("std_msgs/String","sensor_msgs/Imu");
You just list all the messages you need. Then in your main.rs
, you add:
#[macro_use]
extern crate rosrust;
rosmsg_include!();
After that, the rest is pretty much the same. You could create an IMU message with msg::sensor_msgs::Imu::new()
, and the rest of the API should work as before
For all of this to currently work, you need to depend on the master branch rosrust
, and depend on the newest serde
and serde_derive
.
Also, the echo you tried should work now, but I can't guarantee anything until I do more tests this weekend. I wrote all of this assuming you're eager to test things.
Great! It works fine, with a small patch.
Code is here, (actually it is not tutorial, just an example..) https://github.com/OTL/rosrust_tutorial
And I opened a pull request to fix the problem that happend in my environment.
https://github.com/adnanademovic/rosrust/pull/18
I understand your situation very well. You don't have to be harry up, and don't have to feel any pressure.
Thank you for excellent ROS/Rust experience!
Already patched in 👍
I use std::string::String
in so many places in the message generation, funny that I missed using it there, and it never failed!
I'll make sure to mention your example code in the README when I'm prepping the next release this weekend.
I'll close the issue as soon as I test some things myself too.
Added one more fix, and now the 0.5 version is released on crates.io!
Btw, your demo app could make good use of the env_logger
crate.
extern crate env_logger;
fn main() {
env_logger::init().unwrap()
// rest of the code
}
This is all you need to do. And in the homepage of the env_logger
doc you can see different logging levels. The reason I'm mentioning it is the fact that sometimes two nodes just won't connect, and you'd get an error message only if you have a logger. Those errors happen in different threads, and are caused by bad network connection attempts (somebody trying to connect to a sensor_msgs/Imu
publisher with an geometry_msgs/Twist
subscriber).
But, as the crate is far from finished, it would be good to see whenever errors happen, because it's more than likely that they can be caused by some undocumented edge cases in the ROS communication protocols, and you could report that kinda issues here then! :)
Have fun coding!
And thanks for the help!
I succeeded to write publisher and subscriber using rosrust! That's great. I can confirm that by
rostopic info /some_topic
, and subscriber says the message.But when I try
rostopic echo /some_topic
, it says nothing. Is this happen in your environment?