switch raws and cob3s to new canopen base driver

[floweisshardt]

currently done and tested for cob4-2 (see #405).
Instructions see #405 (comment)

@destogl will test with raw3-5

[mathias-luedtke]

It does not work for cob-3, because steer and drive are coupled mechanically.
If we want to support them, first ros-industrial/ros_canopen#101 needs to be addressed and second a specialised motor node needs to be written.

[destogl]

@ipa-fmw: Thanks for nice instructions.

I will do it. But probably not before march because currently I have other student working on the robot using powercube but I will try to port also the powercube to use SocketCAN (it shouldn't be too hard) and than I test every thing.

[mathias-luedtke]

@destogl: a SocketCAN-based powercube driver sound interesting. socketcan_interface already encapsulates most aspect. In addition there is a new topic-base interface (http://wiki.ros.org/socketcan_bridge)

[destogl]

@ipa-mdl Thanks! I prefer library-like interface for this kind of stuff. We should have already one implementation which is independent of socketcan_interface, I am looking to integrate it in the next days.

off-topic: There are also few other nice stuff we did with powercube (ipa320/schunk_modular_robotics#156) but it is too dirty for merge. I will clean it an make few PRs.

[fmessmer]

Take care and note of https://github.com/ipa320/cob_control/issues/98!

Old ELMOs need to be set to UM=2 persistently and velocity sensor needs to be enabled (see #445)

[andreeatulbure]

Hello,

I and @destogl tried to test the ros_canopen config #405 on the raw3-5. We followed the config steps described in #405
System set-up:

• overlay cob_driver with ipa320/cob_driver#258
• source overlay https://github.com/ros-industrial/ros_canopen.git
• source overlay: https://github.com/ros-controls/ros_control.git (maybe optional)
• disable peak driver and activate socketcan peak_usb
• configure socketcan with bitrate 1000000

Config (based on #417) :

• in base_driver.yaml:
  add missing wheel
  update homing_offset (EncOffsetIncr in base/CanCtrl.ini)
  check homing_event (HomingDigIn in base/CanCtrl.ini)
  add "606A": "1" # read velocity from velocity sensor
• in base_controller.yaml:
  add missing wheel and update according to base/Platform.ini

The wheels move asynchronously, not synchronously as they do using the old driver. They move to the limit-position, but they stay there and do not move back to zero-position. In the old driver file, CanCtrlPltfCOb3.cpp begining with line 1136, there is some code to move the wheels to zero position but it is written that "// this could be handled also by the elmos themselve". That does not happen in our case.

We do not receive any errors in the console regarding unsuccessful initialization or something similar. What we get is:

Loaded joint_state_controller
Loaded twist_controller
Loaded odometry_controller
Started ['joint_state_controller'] successfully
Started ['twist_controller'] successfully
Started ['odometry_controller'] successfully
[base/base_controller_spawner-12] process has finished cleanly

Do you have any idea what might be wrong?

Thanks,
Andreea

[fmessmer]

When working in on #588 I wondered why we still use the "old" base driver for raw3-1 and raw3-3....
I thought we already switched those to use canopen?
That would also give @destogl and @andreeatulbure a better template for raw3-5

@ipa-mdl @ipa-bnm @ipa-mig
Did we only do this on hardware and not play it back to ipa320?

[mathias-luedtke]

I thought we already switched those to use canopen?

I don't think so.
Only as a test.

[mgruhler]

@ipa-fxm this has only been a test.

[floweisshardt]

if the test was succesfull, what prevents us from changing it permanently? would reduce a lot of code overhead with the old base_drive_chain...

[mathias-luedtke]

if the test was succesfull, what prevents us from changing it permanently?

These were the very first tests..
Back then we discovered problems with the homing switch.
These should be resolved now, because we have cob_elmo_homing.

[fmessmer]

Where are those changes and configs? robot-hw only? raw3-1 or raw3-3? do you remember?

[mathias-luedtke]

do you remember?

Not really..
I think, this is the full raw config for the controller: https://github.com/ipa320/cob_control/blob/indigo_dev/cob_omni_drive_controller/doc/full_overlay_example.yaml

I guess it would be easier start from scratch or to extend the cob4-2 config.

[mathias-luedtke]

@andreeatulbure: It would be great if you could point us to the config you have tested.

[andreeatulbure]

Here is the config I used: https://github.com/andreeatulbure/test/tree/indigo_dev/cob_hardware_config/raw3-5/config
For base_controller.yaml I did not use the full_overlay_example file because when using it there have been errors while loading the three controllers.

[mathias-luedtke]

@andreeatulbure:

please add https://github.com/ipa320/cob_robots/blob/indigo_dev/cob_hardware_config/cob4-2/config/base_controller.yaml#L12 to your config

Have you set UM=2?
(https://github.com/ipa320/canopen_test_utils)

rosrun canopen_test_utils canopen_elmo_console can0 1 <<< "UM"
(test for 1 to 6)

[andreeatulbure]

@ipa-mdl
I added the line to my config and ran the rosrun command which returned UM=2. But it still does the same thing as before.

[andreeatulbure]

It is working now

[mathias-luedtke]

[Just finished writing before the last message ;)]

@andreeatulbure: I am sorry, I haven't read your error description properly. I guess I was confused by "limit position" and "zero position" and thought that homing does not work at all.

However, setting the required_drive_mode was correct anyway ^^

The wheels move asynchronously, not synchronously as they do using the old driver.

This is the intended behaviour.

They move to the limit-position,

So homing works and the new "zero" position was set.

but they stay there and do not move back to zero-position.

Moving to the "neutral" position is just for visual inspection by the user, but is not required for moving the base.
With the new design, moving to the neutral position is not handled in the driver anymore.
It is done in twist_controller, which was started successfully (according to you log output).
The neutral position is the command that is used until the the first twist command was received.

You can adapt it with the steer_neutral_position option (example). Values could be taken from Platform.ini

[fmessmer]

I am willing to have a look at this for raw3-3 but need assistance from @ipa320/navigation-push (for sudo access) as well as maybe @ipa-mdl/@ipa-bnm (for can-driver/canopen support)

[jabbenseth]

After migrating raw3-3 to canopen a few things we (@ipa-mdl) had to do different than described in #405 (comment)

1. We did not need a source overlay of ros_control

2. The whole configuration for the driver was different. The CAN Card we use does not work with the peak_pci drivers. Instead we installed the driver supplied by peak (http://www.peak-system.com/fileadmin/media/linux/index.htm) version 8.3.1 and build it with make NET=NETDEV_SUPPORT (!! The manual differs from the website in this point. The manual is correct !!).

3. Adjust the bitrate of the interface for the driver: See the chapter 3.3 in the manual for "Configure Software" (add options pcan bitrate=1M to /etc/modprobe.d/pcan.conf)

4. After the installation of the new pcan driver load the module with sudo modprobe pcan and continue with

configure socketcan with bitrate 1000000: http://wiki.ros.org/socketcan_interface#Initialize_NIC

Note: Right now the raw3-3 has some issues running with the new drivers

[fmessmer]

Note: Right now the raw3-3 has some issues running with the new drivers

Issue is #661 (comment)
I'm on it

[mathias-luedtke]

@ipa-jba: Step 3 should be optional

[fmessmer]

raw3-3 is migrated....only missing platform is raw3-1
@ipa-mig @ipa-jba and @ipa-rmb will sync to find a time slot where the migration could be scheduled...

[ipa-rmb]

Yes we talked already, we can start on 18.5. but preferably on 22.5.

[fmessmer]

@ipa-rmb @ipa-jba @ipa-mig
have you scheduled a hackathon for the raw3-1 canopen migration yet?

[mgruhler]

not yet. But I guess @ipa-rmb and @ipa-jba need to take the lead on this...

[ipa-rmb]

As far as I can remember @ipa-jba asked me for possible time slots doing this upgrade. I am aware of the following next presentations of the robot: 19.7., 25.7., and maybe 2.8.
The work can be done at anytime in between with sufficient time until the next demo (and everything should work again afterwards). However, please also ask @ipa-bfb and Falk as well whether they have scheduled work on the robot.

[ipa-rmb]

Raw3-1 will also be used in the morning of 21.7.

[fmessmer]

Demo's scheduled:

• 19.7.
• 21.7.
• 25.7.
• 02.8.

@ipa-bfb @ipa-fke @ipa-jba please add to the list...then schedule a session...consider 2-3 days to ensure everything is running smooth...preferably sync with @ipa-mig as did the Elmo tuning for raw3-3!

26.7.+27.7.?

[ipa-rmb]

I am fine with 26.7.+27.7.

[fmessmer]

@ipa-jba
are you available on those dates?
(at least ask @ipa-mig about the Elmo tuning procedure!)

[jabbenseth]

I think I can make it work

[fmessmer]

@ipa-jba FYI
ipa320/care-o-bot#42 (comment)

[fmessmer]

raw3-1 is migrated in #702
which is the last robot (which is still supported) that uses the old "base-drive-chain"-setup

as a follow-up now several launch files and packages become obsolete....cleanup is tracked in new issue #703

[ipa-rmb]

We possibly have a filming appointment with Rainer next Wednesday and afterwards the setup of raw3-1 can be updated completely (including the new torso module).

[destogl]

Hi all,

We still have some small issues that robots gets to edge of stability. Reason for that are controller parameters. Can you give me again link where parameterization process is described? I believe that we are currently the only one using short version of platform, therefore we need a bit different parameters.

Thanks!

[fmessmer]

raw3-3 uses base_short, too
and it's been running for quite a while with canopen now...

did you re-run the native Elmo tuning routine in the Elmo software?

[destogl]

did you re-run the native Elmo tuning routine in the Elmo software?

No. Can you please point me how to do this?

[jabbenseth]

that robots gets to edge of stability.
Does does the emergency stop / stuck detector trigger, or is it more of a shaking which gets really strong if the robot rotated on place?

We had the shaking but it was solved setting UM=2 for the drive wheels.
Stuck detector is relaxed now and should not trigger that easy (if you are running low on battery for example)