Hi Julian,
We are trying to run the demo_const_torque_1_motor demo. Let us know if you are able to get it working and what your set up is.
We are going to try to switch from the PCAN-USB adapter to a PCAN-PCI card adapter? Not sure if that will make a difference but we will give it a try as we are running out of options.
Thanks,
Zac
Hello Zac,
I’m not sure either why it is not working for you but some hints that I can give:
When building on a non-Xenomai-system, we are using a typedef of rt_dev_ioctl to ioctl (so we can use the same code in both cases). So while it also says “rt_dev_ioctl” in the error message, it is not really using a Xenomai function.
According to the output of initialize_can_bus.sh the problem is that for some reason the CAN interface is not found (which results in the error you are getting). When initialised successfully, netstat -i should give an output similar to this (i.e. listing some CAN interfaces):
» netstat -i felixwidmaier@roboch2
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
can0 16 147734829 1 14800 0 2664560 0 0 0 ORU
can1 16 147575173 1 14798 0 2664560 0 0 0 ORU
can2 16 147707895 0 14802 0 2664560 0 0 0 ORU
can3 16 147844091 0 14805 0 2664560 0 0 0 ORU
can4 16 147789673 0 14801 0 2664560 0 0 0 ORU
can5 16 147930441 0 14805 0 2664560 0 0 0 ORU
enp0s31f 1500 4242396 0 0 0 26317 0 0 0 BMRU
enp180s0 1500 387300956 0 0 0 278401296 0 0 0 BMRU
lo 65536 33824 0 0 0 33824 0 0 0 LRU
Regarding USB vs PCI: I did some test with USB devices some time ago. From what I remember, there was no need to change anything to make it work with the USB device, so in general it should work. So I am not sure why it is not found in your case but at least this is the place where you should start debugging.
Note: We do still have some unresolved problems getting it to work reliably with CAN FD devices, though (both USB and PCI). So in case you decide to get a PCAN-PCI card, better get one without the “FD” capability. This issue is unrelated to the interface not being found, though.
Best,
Felix
Hello,
We managed to figure out what the problem was. With the PEAK System PCAN-USB adapter we had been using (exactly the same as what @felixwidmaier had shown in his latest reply) we had been using the PEAK system CAN drivers to initially communicate with the board over the mw_dual_motor_torque_ctrl firmware. However, for some reason to get the computer to recognize the can interface through ros2 and communicate effectively, we actually needed to uninstall the drivers. Once we uninstalled the drivers, the computer was able to recognize can0 and can1 and we had a similar output to netstat -i as you did. Then we were successfully able to build and run the blmc_drivers demos. We’re not completely sure why this solved the problem, we simply saw it on another forum and gave it a try.
Thanks so much for all your help! We’re excited to start fully working with the robot now and getting some more results
Thanks,
Zac
Glad to hear that you figured it out!
I didn’t think about this previously, but I think this makes sense. We are using the SocketCAN drivers that come with the kernel by default. With those the CAN device is handled as a kind of network interface.
The proprietary drivers by PEAK work differently, i.e. there a different API would need to be used to access the device (which is not supported by blmc_drivers).