How to add ROS py client to the script interface

[130s]

Now ROS python Client is added but there's not yet a way to run it from script hironx.py, so the users have been only able to use it so far as a python module (or through acceptancetest_hironx.py but that's not intended to be used on regular basis).

I can think of the following 2 ways to allow users for the access to ROS py client, but I'm not sure which is better. Note that the background of this proposal is that there have been already users who've used to the current setting: i.e. calling RTM client's method by robot.*** -- so the both options below have to assure the backward compatibility:

Option-1. Instantiate ROS Client separately from HIRONX (RTM client).

• Users can run by:

  $ ipython -i `rospack find hironx_ros_bridge`/scripts/acceptancetest_hironx.py -- --host %HOSTNAME%
  IN [1]: robot.anymethod()    (calling RTM client)
  IN [2]: ros.anymethod()    (calling ROS client)

• Dis/Advantage (+ is advantage, - is obviously, the opposite)
  • + Clearer (RTM and ROS clients are not blended)
  • - Users need to remember the instance of ROS client is ros.

Option-2. Instantiate ROS Client inside of HIRONX (RTM client). Have it as a memebr variable.

• Users can run by:

  $ ipython -i `rospack find hironx_ros_bridge`/scripts/acceptancetest_hironx.py -- --host %HOSTNAME%
  IN [1]: robot.anymethod()    (calling RTM client)
  IN [2]: robot.ros.anymethod()    (calling ROS client)

• Dis/Advantage
  • + No change for child classes (e.g. NextageClient) to take advantage of the change.
  • + Less complicated? (no need to remember new instance).
  • - Semantically confusing: RTM client having ROS client as its member doesn't sound optimal.

I may be for Option-2 for its simplicity, but open to opinions / new suggestions.

[k-okada]

in ros_client, are you intend to deliver same API name as we have in hrpsys/rtm? or do you create more general commander that talk to JointTrajectoryAction?

If you want to provide same API, then invoking ipython .... hironx_ros.py ipython .... hironx_rtm.py and running same command robot.goInitial() may good.

If you provide different set of API, then robot.goInitial();; for rtm and robot.go_init() ;; for ros may simple. Even in this case, having hiroinx_ros.py, hironx_rtm.py may valid.

[130s]

in ros_client, are you intend to deliver same API name as we have in hrpsys/rtm?

No. That would have been ideal but I thought it wasn't necessary for the script, thinking (1) it takes too much time (incl. thorough testing) and (2) I couldn't think of usecase where users want to use the methods of the same name per each backend (RTM, ROS). Still, users can write their program choosing backend they like by importing HIRONX (RTM) or ROS_Client.

robot.goInitial();; for rtm and robot.go_init() ;; for ros may simple.

Hm, users might not care the detail of API so that they wouldn't know the difference of similar methods (e.g. goInitial and go_init).

My point (I forgot to mention): for general usecase, let users use RTM methods. Only the users with interest use ROS I/F, since RTM API covers more functionality.

[k-okada]

I see, Let's image how beginners start using the robot.

First one is who are interested in "Nextage" robot and want to learn it's control system, so they start learning from http://wiki.ros.org/rtmros_nextage/Tutorials/Programming, and write a program considering a connection between command that he issued and behavior of controllers.

Another one is who want to use "ROS Robot", so he/she may already have experience on other ROS robot like pr2/atlas/turtlebot and so on. So they know where to look for controlling robot (i.e http://wiki.ros.org/pr2_controllers/Tutorials/Moving%20the%20arm%20using%20the%20Joint%20Trajectory%20Action, http://wiki.gazebosim.org/wiki/Tutorials/drcsim/1.3/whole_body_trajectory). They do not interested in how the controller works, but just looking at ROS interfaces.

So, my impression here is using ROS and RTM interface at same time may not happen, or we can say it shouldn't happen. That's mean there are any undefined function/methods so need to fix.

so I think,

ipytohn .... hironx_rtm.py
$ robot.goInitial()

and

ipython ... hironx_ros.py
$ robot.go_init()

seems simple, and only core overdevelops uses.

ipython ...  acceptancetest_hironx.py
$ robot_rtm.goInit()
$ robot_ros.go_init()

BTW, ROS users point of view, ros_clinet.py should be more general, it should work on any type of robots that takes JointTrajectoryAction. (I agree this may take some time) and should put in more higher level of package, ros_control?.

[130s]

So, my impression here is using ROS and RTM interface at same time may not happen, or we can say it shouldn't happen. That's mean there are any undefined function/methods so need to fix.

Agreed in general.

What I haven't mentioned is that I think it makes sense to include MoveIt! I/F in this ROS client. In fact I've already included MoveGroupCommander in it (in order to easily implement Cartesian method. This can be questioned). That said, there could be cases where a user uses both RTM and ROS interfaces in the same application. How does this sound?

ipytohn .... hironx_rtm.py
$ robot.goInitial()

and

ipython ... hironx_ros.py
$ robot.go_init()

Keeping hironx.py saves existing users who might have built their app that relies on it.

So to summarize, my idea of what we'd want to get after this discussion:

Output-1) (Modified) hironx.py that also internally contains ROS client, as proposed in Option-2 in the OP. Users can:

$ ipython -i `rospack find hironx_ros_bridge`/scripts/hironx.py
IN [1]: robot.anymethod()    (calling RTM client)
IN [2]: robot.ros.anymethod()    (calling ROS client)

Output-2) (NEW, copied) hironx_rtm.py <-- Mere copy of the current hironx.py. Only RTM client. Output-3) (NEW) hironx_ros.py

[k-okada]

What I haven't mentioned is that I think it makes sense to include MoveIt! I/F in this ROS client.

I agree,

Out-1) (Modified) hironx.py that also internally contains ROS client, as

proposed in Option-2 in the OP. Users can:

$ ipython -i rospack find hironx_ros_bridge/scripts/hironx.py IN [1]: robot.anymethod() (calling RTM client) IN [2]: robot.ros.anymethod() (calling ROS client)

Out-2) (NEW, copied) hironx_rtm.py <-- Mere copy of the current hironx.py. Only RTM client. Out-3) (NEW) hironx_ros.py

I might not understand correctly, but once you start using ros-based client, you do not want to care about RTM stuff, (nameservers, model location ....), Thus, if you create ros-based client, it is better and safe not to depends on RTM.

So, ros_client.py is for general ros-based robot, which have joint trajectory action and joint_state and create hironx_ros.py that provide hiro-specific commands such as go initial pose or go offset pose that send command via ros topic.

Servo on/off procedure is also able to controlled via ros message.

[130s]

So, ros_client.py is for general ros-based robot, which have joint trajectory action and joint_state and create hironx_ros.py that provide hiro-specific commands such as go initial pose or go offset pose that send command via ros topic.

Yeah, and I briefly tried to create a prototype where I was too ambitious to aim generic api (not just joint trajectory action) and found it too hard. I think in the beginning we can just specifically use joint trajectory action.

Btw the best paper award of this IROS 2014 might be interesting for this purpose. https://www.youtube.com/watch?feature=player_embedded&v=VFYJ74cUUIQ