ros_canopen Homing method AccessType

asked 2021-06-15 03:15:31 -0500

157 ●14 ●20 ●23 http://www.roboprotos.com

Hi,

The Homing method (object 0x6098) AccessType is usually defined as "RW" in documentations for read and write permission, and sometimes written "rww" in EDS/DCF files when it can be mapped to a PDO:

AccessType=rww

I have a working setup using ros_canopen and two maxon EPOS4 controllers. To get it working I had to change the Homing method AccessType to "const" in my DCF files:

AccessType=const

When I execute my launch file using Homing method default AccessType "rww", I have the following error:

abort6098#0, reason: Invalid value for parameter (download only).
Could not process message

Referring to another post showing examples, there is an example where the Homing method AccessType is "const", and another example where it is "rw".

As I don't have access to those robot hardware, does anybody knows whether or not those 2 example are working properly, and more generally, is it intended to have to modify the AccessType to "const" ?

Ideally I would like to keep my original DCF file unchanged to reflect exactly my controllers, and only change parameters from the ROS config files. Modifying the DCF file seems not the right way to do and it can become difficult or impossible to use the file to restore the controller parameters using the manufacturer tools.

Many thanks!

edit retag flag offensive close merge delete

add a comment

answered 2021-06-15 10:06:39 -0500

Mathias Lüdtke

1596 ●2 ●26 ●26

I have a working setup using ros_canopen and two maxon EPOS4 controllers. To get it working I had to change the Homing method AccessType to "const" in my DCF files:

This should not be needed.. (Unless the object is const in the device's object directory.

As I don't have access to those robot hardware, does anybody knows whether or not those 2 example are working properly,

These are only examples, they show the production settings of Care-O-bot 4!

We did not use homing for the Schunk hardware, so we disabled it. But in the supported drive modes (0x6502), not via the homing method (0x6098).

Ideally I would like to keep my original DCF file unchanged to reflect exactly my controllers, and only change parameters from the ROS config files

You can specify dcf_overlay to set your parameter values from ROS.

Our approach was:

Clean-up EDS (if needed)
Create DCF with common settings, espcially PDO mappings
Overwrite settings in dcf_overlay for device-specific properties like limits and homing offset

edit flag offensive delete link

Comments

"This should not be needed.. (Unless the object is const in the device's object directory."

I agree, and I think I found the reason. My controller firmware specification doesn't define Homing method 0. So trying to set it to 0 either in the DCF file or with a dcf_overlay gives the above error "Invalid value for parameter" as the init service is trying to write that value to the device. However if I change the AccessType to const in the DCF, I guess it's ignoring that SDO command. Do you confirm that ?

Also in the 2 examples, the Elmo is using the Homing method "35", and has an AccessType of rw, so this confirms that const is not necessary when the Homing method value is defined in the controller firmware. And the second example is const with a value to 0, which seems to imply that an ...(more)

Cyril Jourdan ( 2021-06-24 05:04:08 -0500 )edit

In this particular case I would set the "DefaultValue" to "0" in the EDS. This way ros_canopen skips the homing, but does not write the data to the device.

Homing method 35 is different. It homes the device to the current position -> current absoulute position will be 0 afterwards.

I can't find the firmware specification of that robot to see what the original AccessType should be. Do you know what the datasheet says ?

It should be "rw" and it is mandatory, if the CiA402 homing mode is supported.

Mathias Lüdtke ( 2021-06-24 06:13:12 -0500 )edit

Setting the DefaultValue to 0 works indeed, thanks. Do you think the writing of the Homing method value could be skipped based on the dcf_overlay value 0 instead of the DefaultValue 0, to avoid manual editing of the DCF file ? Does it seems a good enhancement to propose in a GitHub issue ?

Cyril Jourdan ( 2021-06-24 07:03:49 -0500 )edit

Do you think the writing of the Homing method value could be skipped based on the dcf_overlay value 0 instead of the DefaultValue 0

No. Because the dcf_overlay is meant to set ParameterValue. But we can talk about a eds_overlay. IMHO it is better to fix this in the original EDS. (0 is the DefaultValue according to the standard)

Mathias Lüdtke ( 2021-06-25 07:52:18 -0500 )edit

add a comment

ros_canopen Homing method AccessType

1 Answer

Comments

Question Tools

Stats

Related questions

ros_canopen Homing method AccessType edit

1 Answer

Comments

Question Tools

Stats

Related questions

ros_canopen Homing method AccessType