Show EOL distros:
Package Summary
The rtmros_hironx package
- Maintainer status: maintained
- Maintainer: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, Isaac Isao Saito <iisaito AT kinugarage DOT com>
- Author: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>
- License: BSD
- Bug / feature tracker: https://github.com/start-jsk/rtmros_hironx/issues
- Source: git https://github.com/start-jsk/rtmros_hironx.git (branch: groovy-devel)
Package Summary
The rtmros_hironx package is an operating interface via ROS and OpenRTM, for Hiro and NEXTAGE OPEN dual-armed robots from Kawada Industries Inc.
NOTE for Hiro users: Utilizing this opensource controller for Hiro requires installation both on Controller Box (QNX-based) and Vision PC (Ubuntu Linux), and the steps for it are not shared publicly in order to avoid any possible inconvenience that can easily be caused by slight mis-operation during installation. Please contact TORK for an advice.
- Maintainer status: developed
- Maintainer: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, Isaac IY Saito <iisaito AT kinugarage DOT com>
- Author: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>
- License: BSD
- Bug / feature tracker: https://github.com/start-jsk/rtmros_hironx/issues
- Source: git https://github.com/start-jsk/rtmros_hironx.git (branch: hydro-devel)
Package Summary
The rtmros_hironx package is an operating interface via ROS and OpenRTM, for Hiro and NEXTAGE OPEN dual-armed robots from Kawada Industries Inc.
NOTE for Hiro users: Utilizing this opensource controller for Hiro requires installation both on Controller Box (QNX-based) and Vision PC (Ubuntu Linux), and the steps for it are not shared publicly in order to avoid any possible inconvenience that can easily be caused by slight mis-operation during installation. Please contact TORK for an advice.
- Maintainer status: developed
- Maintainer: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, TORK <dev AT opensource-robotics.tokyo DOT jp>
- Author: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, Isaac I.Y. Saito <iiysaito AT opensource-robotics.tokyo DOT jp>
- License: BSD
- Bug / feature tracker: https://github.com/start-jsk/rtmros_hironx/issues
- Source: git https://github.com/start-jsk/rtmros_hironx.git (branch: indigo-devel)
Package Summary
The rtmros_hironx package is an operating interface via ROS and OpenRTM, for Hiro and NEXTAGE OPEN dual-armed robots from Kawada Industries Inc.
NOTE for Hiro users: Utilizing this opensource controller for Hiro requires installation both on Controller Box (QNX-based) and Vision PC (Ubuntu Linux), and the steps for it are not shared publicly in order to avoid any possible inconvenience that can easily be caused by slight mis-operation during installation. Please contact TORK for an advice.
- Maintainer status: developed
- Maintainer: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, TORK <dev AT opensource-robotics.tokyo DOT jp>
- Author: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, Isaac I.Y. Saito <iiysaito AT opensource-robotics.tokyo DOT jp>
- License: BSD
- Bug / feature tracker: https://github.com/start-jsk/rtmros_hironx/issues
- Source: git https://github.com/start-jsk/rtmros_hironx.git (branch: indigo-devel)
Package Summary
The rtmros_hironx package is an operating interface via ROS and OpenRTM, for Hiro and NEXTAGE OPEN dual-armed robots from Kawada Industries Inc.
NOTE for Hiro users: Utilizing this opensource controller for Hiro requires installation both on Controller Box (QNX-based) and Vision PC (Ubuntu Linux), and the steps for it are not shared publicly in order to avoid any possible inconvenience that can easily be caused by slight mis-operation during installation. Please contact TORK for an advice.
- Maintainer status: developed
- Maintainer: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, TORK <dev AT opensource-robotics.tokyo DOT jp>
- Author: Kei Okada <k-okada AT jsk.t.u-tokyo.ac DOT jp>, Isaac I.Y. Saito <iiysaito AT opensource-robotics.tokyo DOT jp>
- License: BSD
- Bug / feature tracker: https://github.com/start-jsk/rtmros_hironx/issues
- Source: git https://github.com/start-jsk/rtmros_hironx.git (branch: indigo-devel)
Contents
DEVELOPMENTAL: This status indicates that this software is not yet production ready code. The software has some level of unit-testing. There are known issues and missing functionality. The APIs are unstable but unlikely to change drastically. Use in production systems will likely require modifications including improvements and/or bug fixes. For more information see the ROS-Industrial software status page. |
Software component
Fig. (click to magnify) Software components diagram both on QNX and Ubuntu for Hiro/NEXTAGE OPEN. You can see that users can write their own software to control the robot through ROS and hrpsys, how ever they like.
Note for Coordinate Frames for Hironx
Root of the frame tree is WAIST (instead of ROS standard base_link) due to the fact that originally this robot wasn't made to work on ROS.
Media coverage
ROS news related to Hiro twin-arm robot:
Installation, usage
Full-fledged user document incl. writing codes is found here.
FAQ
Moveit and dynamic scenes with HiroNXO
Can moveit plan a path and then change it during execution because a new obstacle appeared in the path? There are `move_group.plan()` and `move_group.go()` for static scenes. Do I need other commands for dynamic scenes?
For MoveIt! related feature, HiroNXO does no customization. So follow general MoveIt! way. MoveIt! has "allow re-plan" feature. This post might be of your interest.
Controlling joint motors directly with `Joint Trajectory Action Interface`
At the moment I am working on the low level API, the joint trajectory action interface to control the robot. Is it true that the joint trajectory controller directly control the joints (joint motors) of the robot? Because I thought that the robot can only be accessed via CORBA and ROS does not know anything about CORBA.
Your observation is correct; NEXTAGE OPEN does not provide direct controller access to the motor, from both ROS API and hrpsys API. This question is heard multiple times but the root is in its hardware API limitation that we, as the robot's opensource API maintainer, don't have control over.
Correct physical behavior of the simulator
Another question is, if the hrpsys simulator can also simulate the correct physical behavior when we control the joints directly (with Joint Trajectory Aciton). Let’s say my controller parameters are chosen wrong.. Will the robot arm overshoot?
TBA