Best way to drive ODrive externally

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
32

Yeah, UART is only for one ODrive for sure. However for our project there were only ever 2 ODrives planned and this was never going to be changed. In the beginning we actually wanted to create our own intermediate board with an STM32 microcontroller and custom firmware, that does the UDP and UART communication with some inverse kinematics in the middle. We would then have ordered the self-designed PCBs from JLCPCB preassembled with SMD parts. We already this this quite a lot in the past and it worked flawlessly!

Later while testing we used an Arduino for testing the UART for the ODrive and then we thought, actually why don’t we just use an Arduino? Then we switched to an Arduino MEGA because we needed a second UART interface and it turned out that it’s actually fast enough. Yesterday i tested UDP and UART at the same time for the first time and it worked very well. I thought UDP was the slowest part, but it’s really not. In my experiments i was able to send UDP packets from the PC to the Arduino and from the Arduino to the PC at the same time, independently. I was able to turn the frequency on both ends up to 2000Hz on both ends at 23 bytes data size. This is far more that enough for us. Below a cycle time of around ~450us the frequency of the Arduino sender went down and the Packets received at the Arduino were getting corrupted, I think the buffer was getting overwritten.

UART turned out to be a much greater problem, i could achieve a cycle time of around 3 to 5 ms for one ODrive, with minimal requests, sending all three and then parsing all three. This would be more with a second ODrive. However, since we found out that the filter works so well and is certainly usable for our use case, i don’t think it’s a problem, we should be good with a frequency of around 100 to 200 Hz.

On the Arduino? That would be nice. If we were to use an STM32 we could maybe get a lot more speed out of UART but I think it’s actually just fine the way it is right now.

What? No, i didn’t know that. That’s sad :cry:

When we started with ODrive we had a lot of problems with UART native because of the firmware bug and we started to use ODrive just 2 months after the bug was baked into the firmware. starting 2 months earlier would have saved us many many months of problem solving :neutral_face:

There was a lot of debugging in the firmware and so we were actually happy that ODrive was open-source because that allowed us to modify the firmware if no one else was going to do it.

So in that sense: I don’t want to pick on anyone but if it’s going to be closed source, it at least has to work reliably :wink:

1 Like
33

Plus, yesterday I tried to create Inverse Kinematics for our robotic arm and it actually took me just half an hour with only around ten lines of code doing the actual work! I think in the upcoming days i’m going to create a new thread just about this project and i’m going to share it there, i think this would be a more appropriate place for it than in this thread.

1 Like
34

Oh and another thing while I have you there, about the ODriveGUI and the ODrive PRO.

@Wetmelon knows I’m working on a new ODriveGUI. I created it because the original JavaScript/electron based ODriveGUI frustrated me tremendously and I decided to make my own. @Wetmelon then said in another thread that they don’t support the original ODriveGUI anymore and they actually want me to replace it with a new one, so I continued my work.

Later I was looking around and then I found the ODriveGUI for ODrive PRO in the browser and I was kind of shocked seeing such a good-looking ODriveGUI in the browser, which actually recognized my ODrive without any problems and connects it through the browser (though it couldn’t be controlled). It made me feel like my work was for nothing for a brief moment.

But is ODrive PRO going to always be a completely separate product compared to the ODrive v3.6? Or is there going to be such an ODriveGUI for v3.6 as well? I would of course be happy if it worked so easily!

I am currently working on Conan packaging for all of the C++ dependencies, so it can be easily built on any platform, if that’s done I might actually share it soon. It’s currently already fully functional and reliable, except for live plotting.

However, I think even if the browser GUI might take over, it’s still a good offline alternative, so i’m still going to continue my work.

1 Like
35

Many questions!

This is the maximum frequency for CAN2.0A/B. CAN-FD can go up to 12mbps during the data frame section.

Yes, use a proper digital isolator, like @SG-O did. https://github.com/SG-O/Isolator

Each data frame on CAN can hold up to 8 bytes. In the CANSimple spec, every message with data is always 8 bytes (the extra bytes aren’t a lot of overhead compared to all the arbitration etc). The floats are 32-bit single precision IEEE-754.

100% agree with you! We’re going as fast as we can :slight_smile: and that’s why Pro is listed as Beta.

Completely separate product. v3.6 will be considered a “legacy” product. The v3.6 GUI is not going to be improved further, and fibre on 3.6 is incompatible with the fibre protocol on v4/Pro / other future products. So the new web gui doesn’t work with 3.6 and vice-versa. If you create a nice GUI for v3.6, it would still be used by the community.

1 Like
36

That all makes sense, thanks for the clarification.

I think we’re going to try it without optocouplers for now, in case it’s not working we can still get some. Glad that it’s floats, otherwise everything i wrote would have been wrong :slightly_smiling_face:

Alright, got that.

37

I just created a new thread, showcasing this project in detail. Check it out if you’re interested.

It’s not complete yet, let me know if you want to know more about it!

1 Like