Comau

Supporto

Lorem ipsum dolor sit amet, consectetur adipisci elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.


Lorem ipsum dolor sit amet, consectetur adipisci elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.

e.DO People Learn Robotics Forums Software Correct e.DO Simulation in ROS

This topic contains 16 replies, has 5 voices, and was last updated by  Yoan Mollard 1 month, 2 weeks ago.

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #6364

    Stefan Profanter
    Participant

    Dear all,
    I created a cleaned up and working version of the RViz and Gazebo simulation for the e.DO Robot.
    The original package which is provided by Comau did not start up and the model which is used there is completely broken (wrong axes, different length of joints, …).

    With my Version you can use RViz to plan a path and then control the e.DO robot in simulation. If someone wants to write a wrapper for the real robot, then you could even use RViz to control the real robot.

    The packages you need are on my github Account:

    https://github.com/Pro/eDO_description

    https://github.com/Pro/edo_gazebo
    https://github.com/Pro/edo_gripper_moveit

    https://github.com/Pro/edo_gripper

    @comau:
    Feel free to take my implementation and fork it to your repository.

    BR
    Stefan

    #6373

    Comau
    Keymaster

    Hi Stefan,
    Thank you for your developments, we are really happy that the community is proactive. However, the Virtual e.DO is not internal to Comau but developed by an external contributor.

    Your passion is really appreciated.

    Best regards

    #7271

    Hi Stefan,

    I’m trying to use your RViz simulation but am having difficulty getting it to work. When I load any of your configurations into RViz I get the error under RobotModel saying “Parameter [robot_description] does not exist, and was not found by searchParam()”. I’ve looked around for a solution to this problem and have spent a few hours trying to figure it out, but I can’t. Do you know how this problem can be solved?

    Best,
    Gabe

    #7275

    Stefan Profanter
    Participant

    Hi Gabe,
    did you use all my packages I listed above?

    You can not use the ones from Comau since they are full of bugs and wrong annotations.

    https://github.com/Pro/edo_gazebo
    https://github.com/Pro/edo_gripper
    https://github.com/Pro/eDO_description

    Optionally:

    https://github.com/Pro/eDO_moveit

    
    mkdir edo_test && cd edo_test
    mkdir src
    cd src
    catkin_init_workspace
    git clone https://github.com/Pro/edo_gazebo
    git clone https://github.com/Pro/edo_gripper
    git clone https://github.com/Pro/eDO_description
    cd ..
    catkin_make
    

    Then open two terminals with the commands

    
    roslaunch edo_description edo_upload.launch
    roslaunch edo_description test.launch
    

    That gives you the image as shown here:
    https://github.com/Pro/eDO_description

    Are these the steps you followed?

    Make sure that you start a clean rosmaster, otherwise the description sometimes fails.

    BR
    STefan

    #7282

    Hi Stefan,

    Your last message was very helpful. I am still running into troubles however. When I try “roslaunch eDO_description edo_upload.launch” I get the following error:

    RLException: [edo_upload.launch] is neither a launch file in package [eDO_description] nor is [eDO_description] a launch file name
    The traceback for the exception was written to the log file

    I double checked the package and file names and they are correct. I’m not sure what to do to fix this. Do you know what to do here?

    Thanks and best,
    Gabe

    #7285

    Stefan Profanter
    Participant

    Note the lowercase package name in my command and your version which uses “eDO”.
    Maybe that’s the issue?

    Also make sure that there isn’t any other package with the same name already in your ROS workspace, e.g. the original one from comau. You should only have the ones listed above.

    BR
    Stefan

    #7288

    Hey Stefan,

    I’ve tried multiple combinations of eDo, edo, eDO etc… I’m still getting the same error.

    When I search the options available in the roslaunch command I see all of the other packages that I already had installed in addition to the packages I got from your Github. The only difference is that all of the packages that I’ve tried to load from you Github have a / trailing them (e.g. eDO_description/), whereas the other packages don’t have the / (e.g. catkin).

    This makes me think that when I ran catkin_make, packages available to ros were not created from the Github repositories. Perhaps I’m missing something big or not understanding an important concept. Do you understand whats going on here?

    Thanks and best,
    Gabe

    #7291

    Stefan Profanter
    Participant

    I guess that you are mixing multiple ROS environments. Try to start a clean ROS environment by removing all the source /opt/ros.../setup.bash and source /home/..../devel/setup.bash from your .bashrc

    Then open a new terminal and only source /opt/ros/melodic/setup.bash. After that roslaunch shouldn’t show any packages.

    Then create a new ros workspace as shown above and source /home/.../my_fancy_workspace/devel/setup.bash

    Hope that helps.

    Otherwise you will need to do more googling.

    BR
    Stefan

    #8162

    Stefan Profanter
    Participant

    I guess that you are mixing multiple ROS environments. Try to start a clean ROS environment by removing all the source /opt/ros.../setup.bash and source /home/..../devel/setup.bash from your .bashrc

    Then open a new terminal and only source /opt/ros/melodic/setup.bash. After that roslaunch shouldn’t show any packages.

    Then create a new ros workspace as shown above and source /home/.../my_fancy_workspace/devel/setup.bash

    Hope that helps.

    Otherwise you will need to do more googling.

    BR
    Stefan

    #7294

    Yoan Mollard
    Participant

    Hey Stephan,

    Thank you for this improvement! I’m on the way to complete the MoveIt package so that it can take control over an actual (real) robot.
    Unless I missed something, Comau has not documented the ROS interface. Here are the nodes running on all e.DO robots:
    ROS nodes

    We need 2 things to take over control from MoveIt: 1. the /joint_states publisher and 2. the /follow_joint_trajectory controller:

    1. Getting /joint_states is easy from the /usb_jnt_state topic. I sketched a joint state publisher there.

    2. Sending robot trajectories is a little bit more touchy without documentation. I assume /algo_jnt_ctrl is a good basis to send joint commands. It’s published at 100Hz by the algorithm-something node that looks like a place that stores motions you can replay (I’m unsure). So I disabled this thing in a first step (rosservice call /algo_control_switch_srv "mode: 1" Mode 0 means “take control”, mode 1 means “release control”), by trying to publish on /algo_jnt_ctrl by myself. That gave no motion, probably because joints were not powered. This is managed by the “state machine”, which has the following states (translated from italian code comments):

    INIT = 0, /* Initial State */
    NOT_CALIBRATE = 1, /* Not calibrated */
    CALIBRATE = 2, /* Calibrated */
    MOVE = 3, /* Move execution in progress */
    JOG = 4, /* Jog execution in progress */
    MACHINE_ERROR = 5, /* Error state, needing a reboot */
    BRAKED = 6 /* brake active, no motor power supply */ 
    COMMAND_STATE = 255 /* Temporary state when a command is executed */

    At first boot, rostopic echo /machine_state -n1 returns state 0 (INIT). I don’t know yet how to commute the machine state, but I assume it has to be CALIBRATE in order to accept joint commands, re-using the last calibration data.

    Also I haven’t differentiated topic /machine_algo_jnt_state from /usb_jnt_state. Could it be uncalibrated vs calibrated states? The “USB” term does not suggest that difference, though.

    Any input is appreciated!

    • This reply was modified 1 week, 4 days ago by  syn_admin.
    • This reply was modified 1 week, 4 days ago by  syn_admin.
    #7321

    Andrej Pangercic
    Participant

    At fortiss we also did not find any proper documentation about ROS interface and had to reverse engineer some stuff from eDO_ui source which was silently removed from Comau github page :/

    You can check my github project where is a python script which is a poor replacemnt for Android App. It could give some ideas how robot’s state is changing. In the README is also mention project eDO_manual_ctrl which has cpp interface for manualy control a robot.

    We did some experiments with Robotics library [1] which can send joint data 100 times per second of the desired trajectory to a robot. Our data flow is like this:
    1. We disabled autostart of ministarter bash script at Rasberry Pi and edit it. Inside we comment out rosrun edo_core_pkg edo_algorithms. Every time we turn on the robot, in first ssh window ministarter needs to start and in the second window rosrun edo_core_pkg edo_algorithms needs to run.
    2. We start our python script which turns on motors and calibrates the joints, you can also use an app for this, AFAIK re-using calibration data is not possible since the robot has no batteries to store encoders data.
    3. After the robot is turned on and calibrated, we kill edo_algorithms node and send joint data from Robotics library directly to /algo_jnt_ctrl topic. Maybe with rosservice call /algo_control_switch_srv you could disable edo_algorithms node instead of killing it. We did not test this situation, yet.

    Our next step would be to check what exactly does code on the Raspberry Pi, but we did not have time for this.

    [1] https://www.roboticslibrary.org/

    I hope this can help a bit.

    Best, Andrej

    #7326

    Yoan Mollard
    Participant

    Hi Andrej,

    Thank you very much and congrats for this script, it helps a lot, it’s a great retro-engineering work!

    I can’t take over joint control with the script properly, though:

    • With h key, I’m stuck in an infinite loop in send_movement_command, which means that no MOVE ACK is received (and robot does not move)
    • With j key, I can see a MovementCommand being publish successfully on /bridge_jog but the robot does not move

    I’m not exactly proceeding like you since I have not modified the ministarter script, but I get this result whatever edo_algorithm is started, stopped via rosservice call, or killed.
    Why did you disabled autostart of edo_algorithms if you need to start it manually for calibration at every boot up anyway?

    Subsidiary questions:
    1. Have you understood the difference between /bridge_jog and /algo_jnt_ctrl?
    2. Have you got a local copy of the repo silently deleted by Comau? Does it have an opensource license file?
    3. Also, is your robot also slow/jerky when using the Android app (and ONLY the Android app with no custom ROS thing started)? For instance during calibration procedure started with the app, even at 100% speed, I have to get excited on the +/- buttons so that motors deign to move of a few degrees (see video).

    #7330

    Andrej Pangercic
    Participant

    Hi Yoan,

    let me try to reply to some of your questions.

    – I did not clarify which version od EDO’s Raspberry Pi we are running, it is 2.2.1
    – You are stuck in send_movement_command -> Probably MOVE ACK comes back too fast and since this is a single threaded script, it might skip it. We did not notice this problem often and that’s why it is hard to /debugfix it.
    – Jogging does not work. -> Which status code are you having from /machine_state topic when you are trying to jog? Also, you should check /bridge_jog message send from an Android app and send from a script.
    – Disabling edo_algorithms -> If we wanted to send joint data to a robot from an extern PC this was an only know solution. Also, our idea was to remove most of the stuff on Raspberry Pi and replace it with Robotics Library.
    – Difference between /bridge_jog and /algo_jnt_ctrl. /algo_jnt_ctrl topics are used by rosserial, which actually actuates the robot’s joints. /bridge_jog is just one input to an algorithm node and the other is /bridge_move.
    – For a copy of an Android App, I would recommend that you contact Comau directly.
    – We gave up using App on our old tablet. The app is working slowly and there is an extra delay because of the wifi connection.

    #7337

    Yoan Mollard
    Participant

    Thank you Andrej!

    Update: Problem fixed. I had messed up with ROS_MASTER_URI and ROS_IP as I was running your script from remote.

    Indeed, versions might give a clue E.do is a version edo_2.3.1911.680.
    The eDo_ui has a licensed copy here.

    #8163

    Yoan Mollard
    Participant

    Hi Andrej! How did you came to these movement command and movement type = 74 and types? In the UI codes and message format of MovementCommand are different than yours.

    I’m implementing a PID controller for MoveIt. I’m looking for the right parameters to send closed-loop joint commands in real time. It looks like JOG messages don’t do the job, because specifying several joints at a time e.g. msg_mc.target.joints_data = [1, 1, 1, 1, 1, 0.2, 0, 0, 0, 0] seems to align to the lowest (non-zero) speed (here 0.2), so I can’t command joints at different paces.

    I’ll give a try with msg_mc.move_command = 77. Additionally it has a non-zero delay that looks interesting, could it be a timeout in case the PID does not send data fast enough? Any thought about that?

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic.