Liteplacer ODrive demo

[WayOutWest]

https://www.youtube.com/watch?v=xwneqLq60Bw

Wow, anybody know more about this? Wish my machine could move like that. How's the accuracy?

[JuKu]

Oskar Weigl is the guy behind Orive project: https://hackaday.io/project/11583-odriv ... or-control. Odrive is a control board to drive brushless DC motors with acceleration trajectory and encoder feedback loop. He wanted to use LitePlacer as a prototyping pick and place machine as well as demo platform. I helped him to retrofit the machine with 1.5kW (!) DC motors, and he showed the demo in the video at Maker Faire Bay Area last week. Some issues on his side prevented XY demoing, but the X side demo was what you see. It was even more promising that you can see, as the demo used less than third of the available power; the mechanics couldn't take more. It was already twisting a bit and shaking, and using more power started to rip off the teeth from the belt.

Don't get too exited from this quite yet: The Odrive is at alpha development, and will take a good while before it is usable in a product. And ODrive alone is not sufficient, we'll need four channel control, valve and pump switches and so on. So, let me show you JuicyBoard, a modular machien control system: https://plugg.ee/. At Maker Faire, I was able to get Sherif (Sherif Eid, the guy behind JuicyBoard) and Oskar together, and the plan is to get an ODrive module (or connectgion module to ODrive board) to JuicyBoard system. As noted, the current mechanics are not sturdy enough for this kind of power, but if everything aligns perfectly, there is a possibility in hte future for a (very) fast LitePlacer2 machine, with heavy duty mechanics an ODrive motor drive.

> How's the accuracy?

This is still in development, so no real world results. But this is a closed loop control with encoder position feedback so in principle, it should be encoder limited. And very high resolution encoders are out there...

[WayOutWest]

Odrive is a control board to drive brushless DC motors with acceleration trajectory and encoder feedback loop.

Yes I know... i was one of the kickstarter backers for mechaduino, and probably one of the first people outside TropicalLabs to have one because I got impatient and oredered my own boards using TropicalLabs' GERBER files. My LitePlacer has been all-closed-loop control on the XYZ axes for a while now so this is nothing new. But the sheer power and acceleration in that video is mind-blowing.

Some issues on his side prevented XY demoing,

Can you elaborate? This was actually the only suspicious part of the demo. Is it simply a lack of multi-axis kinematics code, or something more serious?

Don't get too exited from this quite yet: The Odrive is at alpha development, and will take a good while before it is usable in a product. And ODrive alone is not sufficient, we'll need four channel control, valve and pump switches and so on.

Well, if you ask me that's the easy part, I already had to do all that to mechaduinoize my liteplacer (TinyG is gone gone gone and nowhere near it anymore). I actually started doing it before I surgically excised the TinyG from my machine, the less tasks I had it handling the happier I was.

So, let me show you JuicyBoard, a modular machien control system: https://plugg.ee/.

Personally I'm working towards exactly the opposite of that. Centralizing all of the control logic means you've got large bundles of wires running through the dragchain. My goal is to have nothing but +48V, ground, and two-wire RS485 running through the dragchain (video is sent via wifi using UDP packets). Chips are cheap, wires are a headache. Centralizing all the brains in one place like that leaves you with octopus-cables...

I studied Vbesmen's work pretty closely while rewriting the mechaduino firmware to get it to a point where I understood it. There's no need to go the TinyG route of all-singing-all-dancing-all-in-one JSON-GCode-to-wire-toggling. Vbesmen's approach, which I very strongly advocate, was to have each closed-loop motor run a PID loop internally and accept a stream of (time,goal-position) commands (like, 1.2ms from now you should be at rotational position "negative 947.1 degrees") and report back a stream of (time,actual-position) pairs. That (plus tuning the PID loop) is a very simple, clean API on top of which you can build pretty much whatever you need. For example, parse G-Code, plan out a bounded-jerk trapezoidal acceleration profile, and reduce it to a (time,position) stream. Unfortunately TinyG smashes these two components together and gets them all tangled up in each other. It's a shame, especially since there is really no need to be using GCode for a pick and place. Anyways, point being, you are probably closer than you think, just don't get trapped in the box of approaching everything the way TinyG does.

This is still in development, so no real world results. But this is a closed loop control with encoder position feedback so in principle, it should be encoder limited.

Since the encoder is on-axis rotary the limitation will be in the slack/backlash of the rest of the machine "downstream" from the rotary encoder. That's what I was mainly curious about.

[JuKu]

> But the sheer power and acceleration in that video is mind-blowing

Indeed - and it used only a fraction of what was available, the belt couldn't take more. (Upgrading the belts and corner supports is not a big issue)

> Is it simply a lack of multi-axis kinematics code

This. Oskar is working on it. As said, this is alpha stage at this point.

> Centralizing all of the control logic means you've got large bundles of wires

A very valid point, but the conclusion is not necessarily right. There needs to be central control somewhere; we need to synchronize xya moves, handle homing and limit switches etc. But it doesn't really matter where that is; it could be the pc, or a control board somewhere. It also doesn't matter where the drivers are. I also would like a scheme where the drivers and limit switch operations are at the motors, and only a bus and power needs to be routed. If a right kind of module appears, a central hub might be unnecessary, and have the coordination code at the pc. We'll see.

> Since the encoder is on-axis rotary the limitation will be in the slack/backlash of the rest of the machine "downstream" from the rotary encoder.

Correct. Real world performance remains to be seen. I don't have ODrive running, but I'd like to build an experimenting setup.

[GilchristT]

> Centralising all of the control logic means you've got large bundles of wires

Just a minor thing but if you look at the design of the Shapeoko 3, it uses a solid and much larger single beam for the Y axis.

This beam gives a significant amount of real estate for mounting control units on the rear. I've my GeckoDrive G540 motor driver on mine and it's only using about a third of the space. I intend to mount my SmoothStepper on it when I've spare time (ha!)

I'd imagine if you were looking at this sort of performance you'd be beefing up the axes anyway?

[JuKu]

> I'd imagine if you were looking at this sort of performance you'd be beefing up the axes anyway?

You bet. At 1/3 power, the belts couldn't take more, and there was visible (!) bending in the mechanics. The current hardware is fine for current motors, but woefully inadequate for a few kilowatts.

[madcowswe]

Hi there,
I'm Oskar, as was mentioned: I'm the guy behind ODrive.

First of all: Juha has been extremely helpful in our collaboration around the LitePlacer, and I just want to start by saying thanks Juha!

So as was mentioned, ODrive is not a finished product and many things, especially on the firmware side, is a work in progress. However, as can be seen in the below linked video, all the core components required for point-to-point movement should be in place.
Therefore, I want to reach out to see if there are any brave souls who are interested in upgrading their LitePlacer, or otherwise interesting in testing ODrive?



When it comes to the mechanical mods that we did: I have 2 spare sets of the steel plates that Juha got made for me. I am happy to send them along. There are two issues to be noted with that specific setup though: the max motor torque that it can handle is only about 0.7Nm, hence not making full use of the ODrive potential.
The other issue is that there were one or two errors in the plate design which means that you have to use a drill press or mill to modify them a bit.

Anyway, that specific mechanical mod, or otherwise, I'm very happy to give guidance and support, and most of all receive feedback on how to best use ODrive for PnP. So if you are interested feel free to reach out, either here (this post, or PM), or by email: oskar.weigl@odriverobotics.com.

Cheers!

[femtoduino]

I'll e-mail you shortly, and buy some ODrive stuff tomorrow. I have access to a drill press.

Hi there,
I'm Oskar, as was mentioned: I'm the guy behind ODrive.

First of all: Juha has been extremely helpful in our collaboration around the LitePlacer, and I just want to start by saying thanks Juha!

So as was mentioned, ODrive is not a finished product and many things, especially on the firmware side, is a work in progress. However, as can be seen in the below linked video, all the core components required for point-to-point movement should be in place.
Therefore, I want to reach out to see if there are any brave souls who are interested in upgrading their LitePlacer, or otherwise interesting in testing ODrive?



When it comes to the mechanical mods that we did: I have 2 spare sets of the steel plates that Juha got made for me. I am happy to send them along. There are two issues to be noted with that specific setup though: the max motor torque that it can handle is only about 0.7Nm, hence not making full use of the ODrive potential.
The other issue is that there were one or two errors in the plate design which means that you have to use a drill press or mill to modify them a bit.

Anyway, that specific mechanical mod, or otherwise, I'm very happy to give guidance and support, and most of all receive feedback on how to best use ODrive for PnP. So if you are interested feel free to reach out, either here (this post, or PM), or by email: oskar.weigl@odriverobotics.com.

Cheers!