Comments (4)
It is hard to tell what's going on as every vendor handles things a little bit differently, but I will try to give some pointers.
cyclic synchronous position or profiled position mode (mode 1 or 8).
Do not use profiled position mode, it is not meant for updating the target constantly (-> use IP or CSP instead).
It is meant to send only a single command and let the motor reach the target before send a new one.
It works be filling a set-point buffer on the device, the length must be configured properly in the device or EDS.
ros_canopen resets the buffer, but perhaps this is not working properly in your case.
the commands seem to pile up in that the motors
Do you see that for all motors and CSP and PP mode?
Anywhere there are buffers that might be piling up
There is not much buffering done in ros_canopen.
All data is written at the end of update()
.
SocketCAN has a buffer, too. But be default it should be rather small (10 messages?).
mutex locks that may pile up with more nodes
Most of the locks are short-lived, just long enough to update the command values etc.
All target positions/velocities have been mapped to RPDOs, and we can see that in cansniffer output
Synchronous PDOs?
Have you checked the intervals?
All data from the devices should arrive in the first quarter of the sync interval.
ros_canopen will process the data in the middle of the interval and the bus must be fast enough so that the devices can load the data before the next sync.
and saw there are freezes in between update calls
update()
must not freeze.
Please make sure that there are no SDOs for anything motor related, as this will block the update loop.
(SDOs to the error register are run in a different thread).
However, this will not pile up commands, but it might delay the processing.
Can you suggest some places we can debug?
Test with a single motor and a controller which lets you choose the command, e.g JTC or the topic-based controllers.
Then analyse the CAN data and check if the commands change at all.
from ros_canopen.
Thanks for the prompt reply! I will stick to CSP, revise socketcan queue length, and test with JTC and topic controllers and report back. Now that you mention the socketcan queue, we may have made that too large.
Below are some clarifications.
Do you see that for all motors and CSP and PP mode?
Yes.
Synchronous PDOs?
Have you checked the intervals?
All data from the devices should arrive in the first quarter of the sync interval.
ros_canopen will process the data in the middle of the interval and the bus must be fast enough so that the devices can load the data before the next sync.
The slave devices are configured as asynchronous PDOs with 100ms update rate. We tried setting sync/interval_ms
to 0 and also 10 and 100 with no luck. Am I correct in guessing that, when using sync/interval_ms = 0
, ros_canopen
will process the data in the middle of the interval based on update_ms
instead?
Related question: do different PDOs run on different threads? What constitutes own thread in canopen_motor_node
?
update() must not freeze.
Please make sure that there are no SDOs for anything motor related, as this will block the update loop.
(SDOs to the error register are run in a different thread).
However, this will not pile up commands, but it might delay the processing.
We actually tried removing the EMCYLayer
after seeing SDOs to the error register with no luck. But it's good to know that the error register SDOs are on separate thread and should not block.
from ros_canopen.
The slave devices are configured as asynchronous PDOs with 100ms update rate
Why asynchronous? And why only at 10Hz (which limits your control to 5Hz..)
Please try synchronous PDOs or go for a higher PDO rate (80Hz?)
sync/interval_ms = 0, ros_canopen will process the data in the middle of the interval based on update_ms instead?
No, then PDOs get processed and sent at the update interval.
do different PDOs run on different threads?
No. PDOs are received in the CAN threads and written to the buffer.
Processing and sending is happening in a different buffer.
What constitutes own thread in canopen_motor_node?
This depends a little bit on the configuration.
The CAN driver is run in a separate thread. The SocketCAN driver uses boost::asio, which runs additional threads.
Then there the foreground thread for ROS callbacks (timers, subscriptions, servers).
CANopen layers (including ros_control) are run in one separate thread, basically a read, update, write cycle.
This is the main thread for all data processing.
The controllers often spawn additional threads, for example for action servers.
But it's good to know that the error register SDOs are on separate thread and should not block.
SDOs will always block.
That's why all data read or sent for control, should better be mapped to PDOs. Otherwise the update function will block.
from ros_canopen.
Thanks Mathias, no buffering now with synchronous PDOs with a lower sync interval and a revised txqueuelen for the CAN netdev. I am closing the issue.
from ros_canopen.
Related Issues (20)
- catkin_make failed
- Mode Switch timeout is too short for some drives HOT 1
- Can I transmit a rostopic detecting a pedestrian to a canframe. How do I do that using roscan open?
- Rostest canopen_master test fails occasionally
- I have encounterd errors when I use ros_canopen
- Unable to initialize driver: Supported drive modes (object 6502) is not valid HOT 7
- CAN Bridge Node can't differentiate between multiple interfaces after reception / before sending HOT 3
- I have encounterd errors when I use ros_canopen like below.
- Re-init error
- ROS2 can used this code? HOT 2
- Recovery from USB disconnection HOT 1
- Can device goes into an error state and the socketcan node never recovers HOT 1
- Canopen_master initializing failure with "std::bad_cast; Could not set transition" HOT 3
- Could not switch to mode 1, reason: Mode switch timed out. HOT 1
- Invoking "make -j12 -l12" failed HOT 1
- How to import the EDS files from servo motor manufacturers into the ros_canopen package? HOT 1
- CAN IDs of 0x18FFFFFF not showing up in candump
- [ERROR] internal error: 76 HOT 1
- Read CAN messages with ROS
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ros_canopen.