openrr / openrr Goto Github PK

View Code? Open in Web Editor NEW

466.0 466.0 26.0 89.42 MB

Open Rust Robotics

License: Apache License 2.0

Rust 99.31% CMake 0.01% Shell 0.68%

robotics robotics-programming rust rust-lang

openrr's Introduction

openrr: `Open Rust Robotics`

For developers and future users

OpenRR (pronounced like "opener") is Open Rust Robotics platform.

It's heavily under development.

Supported Platforms

OS	Core	GUI	ROS	ROS2
Linux (Ubuntu)	✔	✔	✔	✔
macOS	✔	✔	✔
Windows	✔	✔

You can use ROS without ROS installation on Linux/macOS.
ROS2 Support is experimental. See arci-ros2 for details.

Dependencies

Linux

sudo apt install cmake build-essential libudev-dev xorg-dev libglu1-mesa-dev libasound2-dev libxkbcommon-dev protobuf-compiler

cmake build-essential (openrr-planner (assimp-sys))
libudev-dev (arci-gamepad-gilrs)
xorg-dev libglu1-mesa-dev libxkbcommon-dev (openrr-gui (egui))
libasound2-dev (arci-speak-audio)
protobuf-compiler (openrr-remote)

Architecture

arci is a hardware abstraction layer for openrr. Currently ROS1 and urdf-viz (as a static simulator (actually it's just a viewer)) are implemented.

You can write platform/hardware independent code if you use arci traits.

What is OpenRR?

OpenRR contains..

abstract robot interfaces (arci)
concrete implementation of the interfaces (arci-ros, arci-urdf-viz, ...)
library which uses the interfaces (openrr-client, ...)
tools (openrr-apps)
pure libraries nothing to do with arci (openrr-planner, ...)

Tools

Currently we have some tools to control real/sim robots.

See openrr-apps for details.

joint_trajectory_sender

Inspired by joint_state_publisher_gui

You can use this GUI not only for ROS but anything if you implement arci::JointTrajectoryClient and write a small binary main function.

robot_command

General CLI to access arci robot clients. It supports not only sending joint trajectory directly but it supports inverse kinematics with self-collision check, and navigation.

Format

To format use nightly rustfmt,

cargo +nightly fmt

License

Licensed under the Apache License, Version 2.0.

Related openrr repositories

k : kinematics library
ros-nalgebra : rosrust nalgebra converter generator
rrt : RRT-dual-connect path planner
trajectory : trajectory interpolator
urdf-rs : URDF parser
urdf-viz: URDF visualizer
~~gear~~ : (deprecated) motion planning library, but it is openrr-planner now.

Why OpenRR?

We strongly believe that Rust is the future of robotics. OpenRR is the world first robotics platform which is made by Rust, made for Rust. It can be a reference, a base for the future robotic people, like us.

Contribution

We appreciate for your any contributions! Create an issue at first!

Here is a discord server.

Using OpenRR

You can read the tutorial books at the following links.

openrr's People

Contributors

Stargazers

Watchers

openrr's Issues

Make rosrust::init process more easy

    #[cfg(feature = "ros")]
    let use_ros = robot_config.has_ros_clients();
    #[cfg(feature = "ros")]
    if use_ros {
        arci_ros::init("openrr_apps_joint_position_sender");
    }

can be

    robot_config.prepare("node_name");

and

  fn prepare(&self, name: &str) {
      #[cfg(feature = "ros")]
      if self.has_ros_clients() {
          arci_ros::init(name);
      }
   }

assimp-rs is deleted

We uses assimp-rs = 0.3.1, but the repo has been deleted.
https://crates.io/crates/assimp
https://github.com/Eljay/assimp-rs

It seems that below repo is working and the name has been changed to open-asset-importer (to avoid naming collision, probably).
https://github.com/Vurich/assimp-rs

It might be better to migrate to open-asset-importer if it's good enough.

Release v0.0.1

I don't know how to release workspace style crates.

release v0.0.1
continue to develop
release every two months (??)

Enable ros feature in openrr-apps as default

Currently if we enable ros feature as default, building on Windows become difficult.
If we could switch default feature by OS, it can be done easily but it seems that it is not possible for me.
How should we solve the situation?

Publish v0.0.3

openrr-gui: joint_position_sender: Depending on how to move slider, response on urdf-viz side is very slow

This is due to joint_position_sender calls send_joint_positions every time the slider moves, but I'm not yet very clear how to fix this.

GUI can tell if the user is clicking on the slider, so I think it's maybe a good idea to reduce the frequency of calling send_joint_positions while the user is clicking on the slider.

arci-gamepad-gilrs is not working in MacOS

Below logic prevent the process.
I don't know why but .gamepads() is empty but it works if the check functionality is disabled in MacOS.

openrr/arci-gamepad-gilrs/src/lib.rs

Lines 199 to 207 in 406bcfc

    
           for (connected_id, gamepad) in gil.gamepads() { 
        
               info!("{} is {:?}", gamepad.name(), gamepad.power_info()); 
        
               if id == connected_id.into() { 
        
                   is_found = true; 
        
               } 
        
           } 
        
           if !is_found { 
        
               panic!("No Gamepad id={} is found", id); 
        
           }

Test coverage > 70%

Add doc comments as much as possible

Use #[non_exhaustive] on more types

There are some other types that might be better to use #[non_exhaustive].

Add coverage report

ncollide3d became now parry!

https://www.dimforge.com/

ncollide3d is maintained, but it does not seem to be upgraded.

We have to consider to migrate to parry. I don't know what is the difference and we can use it actually.

https://github.com/dimforge/parry

Change Speak trait interface

Current

pub trait Speaker: Send + Sync {
    fn speak(&self, message: &str);
}

Proposed

pub trait Speaker: Send + Sync {
    async fn speak(&self, message: &str) -> Result<()>;
}

It should be async because it takes sometime to finish speaking.
And it might be failed.

Add commandline tool example

works on urdf-viz/ROS on win/mac/linux

openrr-gui (joint_position_sender) small improvements

Change duration of send_joint_positions: 1 nano sec -> 100msec (1nano sec is super small. 100msec can be acceptable) (Optional: Set the duration by GUI); #135
Button label: Center -> Zero: Center means (high limit + low limit) * 0.5 normally. It works as zero position now. (And sending center is useless actually (sending zero is useful)); #134

Divide arci::Navigation into arci::Navigation and arci::Localization?

Navigation::send_pose() -> Navigation::send_goal_pose()
Navigation::current_pose() -> X
Localization::current_pose() -> Pose and frame_id?
Localization::current_pose(frame_id: &str) -> Pose?

Update kiss3d and nalgebra

It seems kiss3d 0.29 that fixes sebcrozet/kiss3d#262 has been released, but that depends on a new version of nalgebra (0.24).

openrr/Cargo.toml

Lines 33 to 34 in 89cec32

    
           # https://github.com/sebcrozet/kiss3d/issues/262 
        
           kiss3d = { git = "https://github.com/sebcrozet/kiss3d", rev = "6274d50" }

Some dependencies need to be updated first for openrr to switch to kiss 0.29 and nalgebra 0.24.

See #121 for the current status.

arci-ros2 Navigation

ros2 implementation

navigation #364
cmd_vel #291
#718

arci plugin system

We want make it a plugin!

Is it possible to do that for async trait?

Add licenses in all source files

Test Coverage >70% for arci and so on.

Apply Rust1.50 clippy

https://github.com/openrr/openrr/actions/runs/559197074

1.50 has been released!

arci-choreonoid implementation

Add pr2 openrr_apps sample

Support arci-speak-cmd in openrr-apps::RobotConfig

openrr-gui: Determine the crate where the application will be placed

#98 adds the application part of openrr-gui as an example, but we want to be able to install with cargo install in the future. Should we move it to openrr-apps?

RobotConfig urdf path problem

When It is relative, the path is from the config file (It is not described in the README.md
). This was useful for some cases, but it's difficult for everyone (everyone needs to edit config file to try our samples.).
If it's a full path, it works fine. But not good.
This can be solved by more configureable parameter system #78 but it is a future.

How about adding --urdf-path argument to overwrite the config? Then we can use rospack if we want.

Add description in the README.md about relative path
Add --urdf-path for all apps

Use tokio=1.0

tokio is already reached version 1.0.0.
We should use it instead of 0.2 or 0.3.

Add arci-gamepad-girls

We want to add more non ros implementation for arci.

RosNavClient::send_pose() return Ok even if timeout!!

It's not clear what should send_pose() returns, but i think it's a bug.

Make it clear what should send_pose() returns
fix it

In the #144, there are discuss about the naming of send_pose()

Navigation::send_pose() -> Navigation::send_goal_pose()

send_pose() is not send_goal_pose().
It's actually move_to.

Use environmental variable to set config for openrr_apps_*

I'm thinking that openrr_apps_robot_config is like a shell program.
We have to think of calling it many times.
The config argument is verbose!

Using env variable are dangerous and it causes bugs, but there are no way to make it realize what i want to do.

Implement local command arci::Speak

arci::Speak can be implemented as a local command.

We can use bellow commands depends on the OS.

MacOS: say
Linux: espeak (not default but easy to use)
Windows: I don't know!

Configurable parameter system

toml is simple, and it's great. But sometimes we need more complicated configurable parameter system.

replace value by argument
include other toml files from toml file
overwrite default values by another toml file

We have to use google at first to confirm that there are no system which realize our needs.

use openrr-* except for openrr-apps

Include libraries in openrr crate.

https://github.com/openrr/openrr/blob/main/openrr/src/lib.rs

Add teleop example to use openrr

Intelligent teleoperation example

Automate release process

Releasing openrr is complecated!!

Make it possible to build arci-ros on MacOS/Windows

I think it is possible if the program (build.rs) downloads the msg files into some directories.

Improve arci/src/waits.rs logic (JointTrajectoryClient)

Current logic waits until |target - current| is smaller than threshold with constant timeout.
If the timeout is 10sec, and the motion duration is 20sec(call this input duration bellow), it returns timeout error always.
We need some improvements about it.
I think this issue means that we want to reduce the timeout sec, because timeout sometimes happens, and it prevent debug/development.
Basicly we need to add duration to wait() function at first.

Plan1: Just use total timeout( = input duration + timeout)
Plan2: Start checking after input duration and wait until (input duration + timeout).
Plan3: If we want to return fast, even if the time is not elapsed but the target is reached, start checking a little before the input duration.

Plan1 is fine?

Features

Add text box(?) to set the duration. #101 (comment) (Currently I ordered to use 100msec); done in #210
The unit of time should be f64 sec.

Bugfixes

Depending on how to move slider, response on urdf-viz side is very slow #108; fixed by #130

Resolve TODOs

fixed by #281

openrr/openrr-gui/src/joint_position_sender.rs

Lines 52 to 53 in 1896893

    
           // TODO: If the urdf file read by `robot_client` and this urdf file are different, we should emit an error. 
        
           let mut robot = urdf_rs::read_file(urdf_path)?;

openrr/openrr-gui/src/joint_position_sender.rs

Lines 139 to 142 in 1896893

    
           // TODO: Currently, we have separate states for each joint_trajectory_client, 
        
           // but we initialize/update joint_positions based on current_joint_positions 
        
           // when joint_trajectory_client changed. Do we really need to separate state? 
        
           joint_states: HashMap<String, Vec<JointState>>,

Decide how to handle errors. fixed by #257

openrr/openrr-gui/src/joint_position_sender.rs

Lines 208 to 209 in 1896893

// TODO: Decide how to handle errors.

Message::UpdateAll(vec![Default::default(); len])

openrr/openrr-gui/src/joint_position_sender.rs

Lines 301 to 302 in 1896893

// TODO: Decide how to handle errors.

Message::Ignore
done in #134

openrr/openrr-gui/src/joint_position_sender.rs

Lines 238 to 239 in 1896893

// TODO: is the center always 0.00?

joint_state.position = 0.0;
(Blocked on upstream)

openrr/openrr-gui/src/joint_position_sender.rs

Line 367 in 1896893

// TODO: set horizontal_alignment on TextInput, once https://github.com/hecrj/iced/pull/373 merged and released.

done in #241

openrr/openrr-gui/src/error.rs

Lines 16 to 18 in 1896893

    
           // TODO: iced::Error doesn't implement Send/Sync, so for now, convert it to a string. 
        
           // Without this, it cannot be used in combination with `anyhow::Result`. 
        
           // https://github.com/hecrj/iced/issues/516

pending in #663

openrr/openrr-gui/src/style.rs

Lines 1 to 2 in 1896893

    
           // TODO: It's painful to recompile this crate every time I change the style. 
        
           // So remove and replace with https://github.com/taiki-e/iced_style_config or alternatives.

openrr-planner: Support velocity limit

Current implementation lacks calculation of the duration.
It can be calculated by the joint velocity limits.

More openrr-gui

GUI to set ik target (openrr::client::IkClient)
GUI to set BaseVelocity (arci::MoveBase) like this; #323

Implement wav speaker

I want a robot speak Japanese or more language, using Speaker trait.

https://github.com/openrr/openrr/blob/main/arci/src/traits/speaker.rs

If there are a code bellow,

speaker.speak("move to zero");

Say 'こんにちは'.

The struct will be like below

struct AudioSpeaker {
  message_to_file_path: HashMap,
}

impl Speaker for AudioSpeaker {
  fn speak(&self, message: &str) {
    if let Some(path) = message_to_file_path(message) {
      play_file(path);
    }
  }
}

You can use some libraries like, https://github.com/RustAudio/rodio.

Let's create new crate arci-speak-audio.

clean up ros-msgs

There are so many cmake files...

cargo doc warning on arci

 Documenting arci v0.0.1 (/var/lib/jenkins/workspace/openrr-docs/arci)
warning: unresolved link to `i`
  --> arci/src/clients/joint_velocity_limiter.rs:10:40
   |
10 | /// The duration for a TrajectoryPoint[i] is set to
   |                                        ^ the module `joint_velocity_limiter` contains no item named `i`
   |
   = note: `#[warn(broken_intra_doc_links)]` on by default
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

warning: unresolved link to `i`
  --> arci/src/clients/joint_velocity_limiter.rs:10:40
   |
10 | /// The duration for a TrajectoryPoint[i] is set to
   |                                        ^ the module `joint_velocity_limiter` contains no item named `i`
   |
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

Update Top README.md

Current README.md is empty.

send_joint_positions GUI

send joint positions from GUI like
http://wiki.ros.org/joint_state_publisher

Input: urdf file and toml config file
Output: JointTrajectoryCline send_joint_positions()
Load urdf file and get joint names and joint limits.
Creat Slider bar using the joint names and limits.
Send joint positions when slider is moved.

arci-ros and arci-urdf-viz should be used as implementations of JointTrajectoryClient.

Update openrr-app/README.md

We can install apps using cargo install now.
Let's update it for new commer!

Support arci-speak-audio in openrr-apps::RobotConfig

Related with #140 .

Let's do this same time.

	for (connected_id, gamepad) in gil.gamepads() {
	info!("{} is {:?}", gamepad.name(), gamepad.power_info());
	if id == connected_id.into() {
	is_found = true;
	}
	}
	if !is_found {
	panic!("No Gamepad id={} is found", id);
	}

	# https://github.com/sebcrozet/kiss3d/issues/262
	kiss3d = { git = "https://github.com/sebcrozet/kiss3d", rev = "6274d50" }

	// TODO: If the urdf file read by `robot_client` and this urdf file are different, we should emit an error.
	let mut robot = urdf_rs::read_file(urdf_path)?;

	// TODO: Currently, we have separate states for each joint_trajectory_client,
	// but we initialize/update joint_positions based on current_joint_positions
	// when joint_trajectory_client changed. Do we really need to separate state?
	joint_states: HashMap<String, Vec<JointState>>,

	// TODO: Decide how to handle errors.
	Message::UpdateAll(vec![Default::default(); len])

	// TODO: is the center always 0.00?
	joint_state.position = 0.0;

	// TODO: iced::Error doesn't implement Send/Sync, so for now, convert it to a string.
	// Without this, it cannot be used in combination with `anyhow::Result`.
	// https://github.com/hecrj/iced/issues/516

	// TODO: It's painful to recompile this crate every time I change the style.
	// So remove and replace with https://github.com/taiki-e/iced_style_config or alternatives.