Best way to drive ODrive externally

12

Yeah, it’s already dangerous enough at that size :stuck_out_tongue:

I am currently taking a look at ROS and MoveIT, because that’s what we planned from the beginning, but then it kind of slipped from the todo list. I’ll see how difficult it is to get the odrive controlled from C++/ROS, because that’s actually the direct way, everything else is just inbetween.

Afterwards I might try the UDP part again and test the max speed on the Arduino and take a look at CAN. We might get away with configuring it, i just liked the idea that nothing is permanent on the odrive and all configuration is hard-coded in C++ and loaded at startup, just for reliability. It depends if everything we need can be done from CAN (resetting and homing), because we for example do not want it to home automatically on startup for safety reasons, only when you tell it to.

The idea was to have the Arduino inbetween and connect it to the PC with Ethernet, because then you have a single, robust, wired interface to the PC and it is completely universal to every device.

I still hate the idea of using usb. I am studying automation technology and control theory in school and it just hurts my heart to use something like usb for real time control. I would love it if CAN works, just because we can say that we used CAN :stuck_out_tongue: . Nevertheless, I will do some more experiments the following days, we’ll see how it goes.

13

But that will be tomorrow, it’s already 1:17 a.m. here in Austria

14

If you want to set the position continuously to a trajectory, you should try INPUT_MODE_POS_FILTER with input_filter_bandwidth tuned.

1 Like
15

Hey that sounds interesting, I thought of that if such a feature exists. Thanks i will certainly try that, maybe the frequency can be lowered then.

16

damn, that pos filter is working well :hot_face:

It’s working so well, no vibrations at all at 125Hz, exactly what we needed. Thanks for the advice.
I’m going to continue as planned, with the Arduino as the interface between Ethernet and UART native. We’ll see, maybe the frequency can be turned down even lower if it’s not necessary to be that high.

2 Likes
17

There are already some people using ROS to send/recieve ODrive CAN commands - it is much simpler to do this than to include the ODrive Python libraries - and you can do it from a C/C++ node, and it is not ‘connection-oriented’ like USB. CAN packets are fire-and-forget.
I think that is your best way forward.

What configuration do you need to do at runtime? Changing gains, velocity and torque limits maybe? It should be very easy for you to add CAN commands for these to the firmware.

18

I’ve looked into the CAN specification and I think all settings we strictly need are available. As i said, i just liked the idea of loading the parameters once on startup, just for robustness, because that means the odrive is not in charge of remembering settings and it would make sure that all odrive boards are configured equally and can be reconfigured easily without any unplugging. Not strictly necessary tho.

You are constantly talking about CAN in Linux / ROS / C++. How is that meant to work? Are there USB to CAN adapters? Or how is the CAN signal supposed to get out of Linux? I’m talking about the hardware interface.

We bought some of these just for testing, these are Arduino UART to CAN adapters AFAIK, haven’t tried them yet.

19

These are great: https://www.inno-maker.com/product/usb-can/ It’s even isolated too.

Don’t bother with UART-to-CAN, go for a native socketcan device like that one ^.

On Linux, those work out-of-the-box. Plug it in, and you get a network device called can0.
To bring it up: sudo ip link set dev can0 type can bitrate 500000; sudo ip link set dev can0 up
Then to dump frames to the terminal: candump -L can0

To write a C program to send/recieve CAN frames is trivial: Example C SocketCAN Code – Beyondlogic

There is also a driver for Windows for these things, but it only works in Python.

1 Like
20

Ah, i see, so it’s like a network interface. That makes it certainly usable as a realtime control in contraversy to usb.

Sound very interesting, i might investigate this in the future. Some time ago i already tried quite a bit getting position output from a CNC system like linuxcnc or Mach3 for example, although i didn’t quite know enough back then to get it working.

I imagine it should work quite well, taking realtime output from a CNC system and passing it on to the ODrives. Back then I did a lot in this direction, because I wanted to use a proper CNC interpreter for my homemade Arduino CNC with DC servos, another old project of mine, i might actually share this project as well, tho it has nothing to do with ODrive. However, it’s a 3 axis CNC machine based on an Arduino MKR Vidor 4000, where i programmed the FPGA to take homemade encoder signals and drive the DC motors to their position. It drives 3 DC servo motors, where each axis is controlled by a PID with 20kHz.

I basically made my own gcode interpreter on the Arduino with fully featured 3D trajectory control, with the same interface as GRBL, so that it can be used with the postprocessor and control software for GRBL. I basically remade the base idea of GRBL, but for servos instead of stepper motors. The problem is that GRBL runs over USB Serial and i wanted to change that, i really liked the idea of using realtime Ethernet.

But that was long ago, maybe i would be more successful nowadays. I would really like to upgrade my DIY CNC to a proper controller with realtime capable communication. If that works it could be easily adapted to run ODrive over a CAN network interface.

By the way, talking of CNC, there isn’t a ready to use solution for a CNC interpreter where i can simply get the axis desired position with some software and send it to whatever i want, right?

I tried hacking into systems like Mach3 or linuxcnc by connecting to Ethernet based controller hardware, but I wrote software to trick the system into thinking it’s actually such a commercial hardware module. This software would basically redirect the output to whatever system is used.

I saw so many CNCs and 3D printers, i still haven’t figured out how they work. I think some of them use special hardware boards that drive the ODrive with step/dir. Such a software that takes input from a CNC system virtually doesn’t exist, right? If so, please let me know! Hope it’s clear what i’m after…

21

To add to that, it’s not only conventional CNC milling what i’m after, but NC control in general. For this project we still need some kind of inverse kinematics and as i said, i tried to use a Beckhoff industrial PLC controller running inverse kinematics and somehow get the output and get it to the odrives.

If that worked, it could be adapted to anything, not only ODrive.

That part with the CAN network interface sounded perfect, it would be the direct way from the PLC to the ODrives as long as there’s no EtherCAT slave. Might try playing around more with PLCs in the future

22

So, I’ve worked with Beckhoff stuff quite bit in the past. I’m quite sure that Beckhoff have EtherCAT-to-CAN terminals that would allow you to send/recieve arbitrary CAN messages from within a PLC program, e.g. EL6751. It says CANopen but I believe it can also be used as raw CAN (layer 2) which should be compatible with ODrive’s CANsimple.

Curious as to why you’d use PLCs instead of ROS for IK though, if you are cost-constrained :stuck_out_tongue:

But, if you’re already working with PLCs, why not take an industrial servo drive that already speaks CANopen/DS402?
Beckhoff even have their own servo terminals e.g. EL7411, or they have stepper motor drives with feedback e.g. EL7041.
All pretty low current though compared to ODrive - there’s a bit of a power gap there between their little ‘servo slices’ and their multi-kW mains-fed industrial drives. Apparently they are made by two completely different departments within Beckhoff that don’t talk to or like eachother. (so I was told by a Beckhoff salesman)

23

Yeah this is really frustrating! I tried my own ODrive-based CNC mill project and that was the stumbling block I never got over. I had assumed that LinuxCNC would have ways to use something other than a parallel port step/dir interface, but it seems as if they have all gone really low-level just so they can support this stupid legacy bit-bashing interface.

The other issue is, that for CNC, you don’t really want the motor controller to smooth/filter your setpoints, and you need multi-axis coordinated motion, so the motor controllers can’t be in charge of their own velocity and position. Without a pretty sophisticated multi-axis motion controller, you end up having servos with the performance of steppers.

Btw speaking of EtherCAT, have you heard of PiCAT? This looks really interesting: Simple Robot: CiA 402 Motion control example for MAXPOS drive

24

I think for this project I’m going to try to make my own inverse kinematics, because it is relatively simple and in this case only 2-dimensional. For this project we only need a video of it moving for the deadline. Afterwards we can do whatever we want if we have time to.

I like Beckhoff PLCs for playing around, because it’s basically free. For anyone that doesn’t know, all software by Beckhoff can be easily downloaded for free on their website and you can play around with it for as long as you want, you only need to fill in a captcha once a week (this prevents you from distributing it commercially). Another thing is that they have their TwinCAT system, which can run on any PC. It can simply be downloaded and installed on a Windows 7 or 10 PC and it turns your old PC into a fully featured PLC. Because as I said the EtherCAT master is conventional Ethernet hardware, you can drive pretty much any industrial EtherCAT hardware in real time with basically any PC.

I had many old PCs, but many of them have so little RAM that i couldn’t even install Windows. What’s interesting for me is Beckhoff’s TwinCAT FreeBSD. Since a few years ago a FreeBSD version of their PLC software is available and can be downloaded for free, but I think it’s still in development. You can then install it on an old PC (because of FreeBSD it can also be ARM architecture) and it runs only the TwinCAT runtime, so then you can connect to your PC with another Windows PC with the development environment and access your old PC just like it was a conventional industrial PLC.

As i said, i’m not planning on building anything large with Beckhoff, because I’m a student and still very financially limited, but I like the marketing strategy of Beckhoff, because I can basically play around with industrial IK on a PLC and do Ethernet stuff and send data around and all of this without paying a cent.

This project was our first project to be financially backed by the school, which allowed us to get ODrive in the first place.

1 Like
25

I might actually share all my investigations in another thread, maybe someone finds time to continue.

For LinuxCNC there’s those MESA cards, they are plugged into the PC and have a very powerful FPGA on them which does all the work i think. There are also Ethernet MESA cards, that you can plug into the Ethernet port. I tried to write a software that implements the UDP protocol of these MESA cards, and then the software would run on the LinuxCNC PC and would simply communicate with LinuxCNC over localhost.

https://lonnox.de/mesakarten.html
Most of the Mesa card content is in german it seems

I got them to communicate but there were so many errors and the protocol was never fully implemented and it simply would have required much more time to read all the error logs, see what response was wrong, then implementing the response and then trying again. It worked, but I never got LinuxCNC to fully initialize the (‘virtual’) device.

Another thing i tried was the PoKeys devices, they are also Ethernet based CNC controllers. I can’t remember if only the desired position of each axis is transmitted or if the power for each motor is transmitted (in other words the entire control system), but i think both can be the case, either way would work for us.

These things: Ethernet CNC controller - PoKeys57E - flight simulators, automation -

The advantage with the PoKeys device is that it is more modern (not so industrial-documentation-20-years-old-and-never-changed like the LinuxCNC MESA cards) and they have a very well-documented protocol definition. Another thing is that there is a configuration software (think of it like the ODriveGUI but for PoKeys) and it’s easier to implement the entire protocol and test it with the configuration software and then try it with the real system.

I remember that I tried it with Mach3, so I ran my software on localhost and tried to trick Mach3 into thinking it’s connecting to a real Ethernet PoKeys device. Tho i didn’t really like Mach3 because it’s damn old and ugly and only runs on like Windows XP and probably not reliably on newer versions. Mach4 is no different. I can’t remember if the PoKeys device also worked with LinuxCNC, but I think so. I only remember that i was a lot more successful with PoKeys compared to the LinuxCNC MESA cards.

Actually now that i’m talking about it i’m getting interested again and would really like to try to implement the PoKeys protocol again, but i have more important things to do :stuck_out_tongue:

1 Like
26

Oh, and regarding the link, i don’t really understand what this is. Is this a Raspberry PI acting as an EtherCAT master and the board as a slave?

The board is a complete servo drive, right?

27

I think the Ethernet CNC controllers should work quite well. They don’t use EtherCAT, instead they use conventional UDP/IP Ethernet streaming like any networking application would. However, i think it’s fine for this application and actually not slower than EtherCAT, because it’s only a direct point-to-point connection and only connected to a single device.

28

You’re a little bit over the CAN limit for 2.0A with 4 axes:

You could split it into two nodes per axis…

We’ll eventually have CAN-FD up to 12mbps + Fibre-Over-CAN + a USB CAN dongle for ODrive Pro, so that should basically do what you need… not there yet though.

USB or UART is currently the most common. UART is fast if you’re using the short-form ASCII commands, but not very robust against noise. CAN is the way to go in that respect.

2 Likes
29

Also UART is point-to-point, so it only works for two axes at once, unless you have a second UART. And it can’t so easily be isolated.
You could always have a second CAN interface. :stuck_out_tongue:

Doesn’t UART also cause more CPU overhead on the ODrive end? I guess it’s got enough CPU spare though to process 100k characters per second for a 1Mb UART? You must be using DMA, I suppose.

Also, @HerrNamenlos123 may not be aware that ODrive Pro / V4 is NOT going to be open source… :cry:

2 Likes
30

Wow, that’s what I call effort to answer my questions!

Yeah, it wouldn’t be a problem to simply use two CAN buses concurrently, one for each odrive, if the bandwidth is not enough. Tho that isn’t scalable and it would be nice if you could simply plug in a third and a fourth, without changing anything.

I’m quite new to CAN, so I don’t really know a lot about it. The frequency was always given in examples as 1000kBaud, why is that? Is that THE standard speed or is it the maximum speed the ODrive supports right now? I also don’t know CAN-FD, but 12mbps sounds a lot!

I understand that CAN is the best for noise resistance. We are using UART for our project currently and I think we will keep it at least until the diploma thesis is finished, then we can do whatever we want. In the last days I was reading a bit in other threads and I read about ground loops and now that I truly understand what is meant by that i am actually scared we will also have problems with ground loops. I just hope it’s not going to be an issue because the motors are hopefully never going to consume a lot of current. We’ll see.

Actually i remember I also read something about optocouplers in the last days, do you think it’s a simple solution to make a small board with two optocouplers, that connect TX and RX from the Arduino and couple it to the ODrive’s GND? Should be quite easy in my imagination, I hope it is in reality as well.

1 Like
31

But the most important thing: Why did you always write data size 64 bits for every position in the CAN sheet? I thought all input_pos and encoder_estimate’s were conventional floats with 32 bits? Or have i screwed up really badly and they are actually all 64-bit doubles?

1 Like