Ros service /fts/Init freezes about ati_force_torque HOT 7 CLOSED

Hello,

if you are using adapter in as NET device than you have to use SocketCAN, PEAK-USB CAN is for char devices.

When you call init service you should at least get some error than communication to sensor is not possible or there are error. Are you getting these?
Also which driver for PEAK-USB CAN are you using? From kernel? If so then please install the newest driver from PEAK website.

from ati_force_torque.

Hello,

I have tried with SocketCAN as well, the same thing happened.
My kernel is 4.4.0-75-generic and I have tried PEAK-USB 7.15.2 driver, as well as the latest one 8.3.1.
I am not getting any messages. As soon as I start the service it does not show any output.

I am also using ros-canopen-indigo packages instead of cob_generic_can. I have the sensor mounted on a Schunk LWA4D robot and I need ros-canopen-indigo to run it. I am not sure if that helps.

Thanks!

from ati_force_torque.

But is your sensor on separate bus or the same as robots? Did you compile kernel for NET device?

currently I have no idea, since always when I had error in configuration I got some output in the terminal....

You have to have cob_generic_can package otherwise it will not work. The ros_canopen is completely different package.

from ati_force_torque.

Hello,

Thanks for your input, indeed I was missing the cob_generic_can package. I installed it and the fts/Init service does not freeze anymore. I am also using latest Peak driver as NET device.

However I am getting new errors. As soon as I initialize the sensor, I am getting the following:

Can not read Serial Number from FTS! Error: Receiving Message failed! Can not read Firmware version from FTS! ForceTorqueCtrl::ReadCountsPerUnit(): Can not read message! Can not read Counts Per Unit from FTS! ForceTorqueCtrl::ReadUnitCodes(): Can not read message! Can not read Unit Codes from FTS! Error: Receiving Message failed! [ INFO] [1494947612.201102893]: Autoinit: FTS could not be initilised! :/ [ INFO] [1494947612.202804801]: ForceTorque Sensor Node running. [ERROR] [1494947612.206334359]: "world" passed to lookupTransform argument target_frame does not exist. [ERROR] [1494947612.706550150]: "world" passed to lookupTransform argument target_frame does not exist.
The "world" errors result from my robot's URDF is not uploaded properly. But before that, all the previous errors seem to indicate that there is no message read from my sensor.
Currently, I have all the modules (arm, sensor, gripper) configured to run in the can0 port. I would like to ask, does the sensor need to be in other CAN port (e.g. can1) to operate properly?

Thanks!

from ati_force_torque.

OK, good that we made progress.

This is typical error when communication with sensor doesn't work properly. Try to check following:

1. Is the sensor powered?
2. (most probable error) Check the baudrate (default 250K) of your interface and sensor. You can set it in /etc/network/interfaces file with:

allow-hotplug can0
iface can0 can static
    bitrate 250000 restart-ms 100
    up ip link set $IFACE txqueuelen 20

3. Check ID of your sensor on the CAN network.

Theoretically it could work on the same bus. Nevertheless you have three different devices with at least two protocols on the same bus. This could work, but it can also be source for strange errors. If you are sure all three above points are correct than you can try to set DEBUG macro in ForceTorqueCtrl.cpp to see exactly which data you are getting from the CAN-bus.

from ati_force_torque.

Hello,

I was finally able to make the driver work. In the end, I had 2 problems with my setup:

• The first one was the bitrate. I was working with 500K while the driver works in 250K.
• The second one was that the sensor was able to transmit data only when connected to the AUX CAN port of LWA4D (and using 250K bitrate). That means that the robot and the sensor have to work in different physical CAN buses with different bitrates (as LWA4D works in 500K).

Thank you very much for all the help!

from ati_force_torque.

@nikmayr Thanks for your info!

This is good to know that the sensor and the robot should be on different physical buses.

from ati_force_torque.