# Epos_hardware write output error when running example.launch

Hello,

I am working with EPOS2 70/10 and a maxon EC motor whose shaft is already attached to load. I am using epos_hardware indigo-devel branch package in UBuntu 14.04 x86 4.4.0-38-generic and ROS indigo. I am trying to use the epos_hardware package in order to control velocity on motor. After dealing with the usb rights problems (further info solved in other questions), now I am able to detect the motor using list_devices node. I just adapted the example's launch, urdf and yaml files in order to match my motor settings.

The problem is than when running the launch file (which loads motor settings and enables velocity and position controller) loads the controllers (joint_state and velocity_controller), starts them (look at info message below), the green led is running continously (which means that is properly working) and then the following message appears:

[INFO] [WallTime: 1475677663.913912] Started controllers: joint_state_controller1, velocity_controller1

Write processed successfully, but number of bytes written is 0: Operation now in progress
Write processed successfully, but number of bytes written is 0: Operation now in progress
Write processed successfully, but number of bytes written is 0: Operation now in progress


When trying to set a velocity (rostopic pub /velocity_controller/command std_msgs/Float64 '##'; #:Number between my motor velocity range) the /diagnosis topic shows me this:

---
seq: 501
stamp:
secs: 1475678169
nsecs: 978535919
frame_id: ''
status:
-
level: 0
name: epos_hardware: my_joint_actuator1: Motor
message: Enabled
hardware_id: 662080006194
values:
-
key: Actuator Name
value: test_joint_actuator1
-
key: Enabled
value: True
-
key: Fault
value: False
-
key: Voltage Enabled
value: True
-
key: Quickstop
value: True
-
key: Warning
value: False
-
level: 1
name: epos_hardware: my_joint_actuator1: Motor Output
message: Nominal Current Exceeded (Current: 10.506000 A)
hardware_id: 662080006194
values:
-
key: Commanded Velocity
value: 250 rpm
-
key: Operation Mode
value: Profile Velocity Mode
-
key: Nominal Current
value: 9.8399999999999999 A
-
key: Max Current
value: 10.5 A
-
key: Position
value: 0 rotations
-
key: Velocity
value: 0 rpm
-
key: Torque
value: 10.506 Nm
-
key: Current
value: 10.506 A
-
key: Target Reached
value: True
-
key: Current Limit Active
value: False


So, velocity and position tells me that the shaft is not moving but torque is supposedly not zero (no access to see shaft as is already installed on the machine) and current is even sometimes exceeding my nominal values. From this I take that the problem may be that:

• The load is too much for the motor torque to even move.
• There might be a problem with the epos_library function when accessing to the parameters or a problem with communication.
• Kernel compatibility problem
• Combination of both or other random issue (because former team members were able to run the motor free shaft with this package).

From what I have read, the command library functions return 0 in case that they are unsuccessful so this is the main reason why I am focusing the problem of not moving the load on this error instead of the overload case. Yet, I do not know any way to check ...

edit retag close merge delete

Sort by » oldest newest most voted

At this point I kept working with the package. I wanted to manage multiple EPOS in a CAN net by managing them through accessing to one of them via USB. The following message was kept being printed periodically as I mentioned in my question:

Write processed successfully, but number of bytes written is 0: Operation now in progress
Write processed successfully, but number of bytes written is 0: Operation now in progress
Write processed successfully, but number of bytes written is 0: Operation now in progress


I could launch the controller but I lost control of the EPOS after sometime by not know reason. I did not know if the problem was due to the limited handling package capability of EPOS or if I was not defining rigth my URDF or if there was some kind of bug in the implementation of the controllers of the hardware abstraction of ros_control (not so much reliable documentation explaining in detail its behavior).

The level of documentation of this package is quite poor from my point of view. A lot of explanations on the ROS Code API is missing and it gets really messy to look debug sometimes. It is a great idea but it gives the sensation that the work was left have done (as realease version was published as 0.0.3).

The USB connection works but when trying to make it work in the configuration I was testing the USB falls making it impossible to communicate with the EPOS unless the code is relaunch. Then you have to pray for the system to be able to clear errors on the first try.

I debugged my code, my URDF and I was not understanding the reasons behind this. Also tried in Windows LabView 2015 and the system did not lost control, the problem of the implementation of this package is that depends on dll libraries which are not supported in Linux based OS so I could not (yet) working with the linux library implementation of epos control.

It seems that the USB communication is not suitable or robust enough so I would recommend to change to RS232 (google the differences on how the communication is done in each case). At least now it looks that I am not experiencing the USB connection fall but I will update with my results in future.

Hope I can save you some time that this problem has taken from me.

more

@Bogdar_ Thank you for your answer! I am also now trying to switch from USB to RS232 but I am not able to use epos_hardware package to initialize the motor. I have in the past successfully used USB connection with epos_hardware. I have also used the EPOS_studio package to control motor through RS232 before trying with ROS. What are all the changes needed in the yaml file to shift from USB to RS232?

more

So I replaced MAXON RS232 as the protocol stackname with Maxon_RS232 and it started working! Thanks for the help!

( 2018-08-13 08:00:18 -0600 )edit

Yeap, back on the days this was a great headache for me. I had a 1 master-3 slaves configuration, since changing the protocol I had no problem. I am glad this has help you to save time!

( 2018-08-13 13:20:00 -0600 )edit