Closed riv-robot closed 3 years ago
The link was more meant as an example of a potential issue, not specific to this case.
Nothing else is running on the CAN bus other than the RevPi ConCAN module which acts as my hardware interface.
@robertjbush: And no other process that accesses the can0
(or whatever it is called in your system) interface?
@robertjbush: And no other process that accesses the can0 (or whatever it is called in your system) interface?
Nope, I ran find /proc/* -type f | grep can0$ | head
and netstat -ap -i can0
, sudo ss -tulpn
. Output from sudo netstat -tulpn
.
Nope, I ran find /proc/* -type f | grep can0$ | head and netstat -ap -i can0, sudo ss -tulpn. Output from sudo netstat -tulpn.
Does any of them show the canopen_motor_node
process?
@ipa-mdl
See below for output (it shows that the canopen_motor_node
process does indeed access the interface).
I am still stuck with the "halt" error....
See below for output (it shows that the canopen_motor_node process does indeed access the interface).
This only lists the TCP ports, which are used by ROS, but not CAN. Perhaps we have to log all CAN messages processed and sent by canopen_motor_node..
I am still stuck with the "halt" error....
Have you tried another switching state?
Success! 🟢🟢🟢
It has initialised successfully, finally...
I decided to go back to one of the 30 eds files I had tried (one I had labelled _BEST.dcf
from last weekend) and go back to a bare bones configuration (i.e. no heartbeat, not specifying any 'advanced' flags, even no switching state).
â›” Still not moving because moveit! can't recognise my ros controller but that's off topic.
I'd like to get to the bottom of this issue as I feel it's never good to leave errors in the background. If there's anything you need @ipa-mdl to be able to debug it further, just write it down here and I'll do it for you. The team doesn't have the expertise with C++ to debug further (not easy to find expert C++ engineers!) so I can't do much more until we hire someone.
Great to hear!
If there's anything you need @ipa-mdl to be able to debug it further, just write it down here and I'll do it for you.
I might have some time this week end to design a test case for the SDO communication on ARM. Including a trace option. I will keep you posted!
So what's the conclusion here (for now)?
@robertjbush: what was it that made it suddenly work?
@gavanderhoorn
1800sub1
sdo.cpp
, line 305, 308, 310 and 429. If offset, buffer and total are not constant then it's the same issue. sdo.cpp
comment out line 429 Root Cause: TBC, but most likely to be source code of canopen_master rather than external factors
I have added a test case (#428) and it passed on ARM64 as well.
Please test this branch locally as well (catkin_make run_tests
), without commenting out anything..
Corrective Action: in sdo.cpp comment out line 429
Commenting out the error detection is not a solution.
Commenting out the error detection is not a solution.
You can read Read FMEA definitions here (see books). Corrective Action is not a solution by definition.
Please test this branch locally as well (catkin_make run_tests), without commenting out anything..
Will do as soon as I get my motor moving.
You can read Read FMEA definitions here (see books). Corrective Action is not a solution by definition.
Let me rephrase then: It is not a proper corrective action either. Instead mitigating the failure (or its effect), you just comment the singe line which would report it to the caller. This is like painting the error light black.
Will do as soon as I get my motor moving.
I truly understand that this is your priority, but if SDOs are not working properly this might affect the motion signals. Especially since we cannot rule out (yet) that there is some issue with memory alignment, which would be present for PDOs as well.
Ok understood, so:
catkin_make run_tests
for ros_canopen
no errors.catkin_make_isolated --catkin-make-args run_tests
does give a worrying error and failed before completion (in tf2
):My plan of action is:
As a general note, I wish I had these tests earlier or that I would have thought about doing them earlier because they help in debugging system installation and package installation. A note on the ros_canopen wiki page would help those with less experience, like myself.
💚 Updated the RevPi image to Buster and the issue disappeared. For those who own a RevPi (Connect, Core, Compact, Flat) and want to use ROS make sure you take advantage of last weeks much overdue release of Buster.
The test suite was very helpful in debugging, thank you @ipa-mdl, please add it to the package and wiki for future users. And likewise the catkin workspace advice @gavanderhoorn was very helpful in setting up my fresh install. Its way quicker and robust!
To finish on a negative note, publishing to the command topic /canopen/positioner_controller/command
still just hangs and doesn't execute a position based move....I suppose its time to open a ROS answers thread as this one can be closed.
I've got a blocker on canopen_master (CANopen communication). The current state is that all plumbing is done, both controller and CAN bus seems to be ok but the ros_canopen fails on launch. I have just one device, a Schneider LXM28A and my CAN master is a RevPi Connect with ConCAN module. Attached are the following:
sdo.cpp (canopen_master)
can::BufferedReader::ScopedEnabler enabler(reader_);
if(result){ interface_->send(last_msg = UploadInitiateRequest(clientid, entry)); }else{ interface->send(last_msg = DownloadInitiateRequest(client_id, entry, buffer, offset)); }
boost::this_thread::disable_interruption di; can::Frame msg;
while(!done){ if(!reader_.read(&msg,boost::chrono::seconds(1))) { abort(0x05040000); // SDO protocol timed out. ROSCANOPEN_ERROR("canopen_master", "Did not receive a response message"); break; } if(!processFrame(msg)){ ROSCANOPEN_ERROR("canopen_master", "Could not process message"); break; } } if(offset == 0 || offset != total){ THROW_WITH_KEY(TimeoutException("SDO"), ObjectDict::Key(*current_entry)); }
if(result) *result=buffer;
}