Heuristic (AI) calibration for delta printers on Smoothie

[ZakRabbit]

The FSR would attach like a probe in one of the "Min" Stops while the "Max" stops would be for the limit switches at the top. You would still need the top switches to home & calibrate the Delta.


[img]http://i.imgur.com/keOPkoC.png[/img]

Perfect, thank you. I figured that to be the case, but I wanted to make sure. 626pilot, thank you so much for the work you've put into this! The rest of you, thank you for your help, this is a wonderful community.

[jlmccuan]

I got my USB stalling issues fixed by using a firmware.bin that has the msd_disable function included so I can turn off sd card access. Evidently the newest firmware has this left out. But it doesn't have your calibration functions. Would you mind compiling your firmware with msd_disable functionality?

[bubbasnow]

alright got my smoothie up and running... lets do this!!

[img]https://lh3.googleusercontent.com/hJh49 ... 16-h965-no[/img]

[bubbasnow]

Ive got everything up and going now, calibrations went good. Im looking to get my second extruder hooked up and i noticed that the config for delta machines is using "extruder_module_enable" but all other configs are using "extruder.hotend1.enable ". Am I ok with updating these parameters or will it break something?

[626Pilot]

Ive got everything up and going now, calibrations went good. Im looking to get my second extruder hooked up and i noticed that the config for delta machines is using "extruder_module_enable" but all other configs are using "extruder.hotend1.enable ". Am I ok with updating these parameters or will it break something?

Did you get this figured out?

[bubbasnow]

yes sure did!! working great definitely getting more print area out of this thing then before! I think i need to work on my switch setup to improve reliability.

its sad that you aren't developing for smoothie anymore.

[626Pilot]

This post gave me an idea.

The best calibration I've obtained so far is an average positional error of around 40 microns, on one of Brian's MAX Metal frames. Every time I've added another variable, the positional error has gone down further. These remain:

• Tower lean (ideally 0, but hard to obtain under realistic conditions)
• All carriage U-joints, including slop
• All arms (no "virtual" arms made from two adjacent ones)
• Whether the arms have anti-lash straps
• All effector U-joints, including slop
• Effector height offset (vertical distance between centers of joints, and the bottom surface of the effector)
• Tool height offset (vertical distance from bottom surface of effector to the end of the hot end/probe/laser/whatever)
• Weight of the arms (with or without straps), and end effector with everything installed

Carriage U-joints don't necessarily wear in an even fashion, although simulating slop as though it happens evenly will probably produce better results than not simulating it at all. Therefore, the slop could be simulated according to whether anti-lash straps are installed.

Arms are strapped:

• We assume that each is drawn towards its neighbor by up to some value - let's say 1mm.
• Each joint is modeled independently, so any arm can have differing amounts of slop in both joints.
• Two neighboring arms can have different amounts of slop. We aren't using a virtual "compound" arm anymore, so we can simulate the full physical system as it really is.
• We simulate the elasticity of the straps. If the effector's acceleration exceeds a certain value, we begin to make the straps "give", allowing lash to be simulated (and hopefully compensated for) at high accelerations relative to effector mass.

Arms aren't strapped:

• We assume that each hangs down by up to some value (1mm).
• As above, we can use the accelerations of the platform and carriages to allow the joints to "bounce around" in real time. Imagine installing a tiny chandelier in a van. If you accelerate the van, the chandelier swings backwards. If you turn right, the chandelier leans to the left. We would model that "equal, opposite reaction."

Since we're accounting for individual arm lengths, we can simulate the effects of arms not all being the same length. That can rotate the effector slightly out of plane. Tower lean has the same effect. If we know how far the tool projects beneath the effector, we can find a way to correct for that in real time. The forward kinematics are easy, but the inverse kinematics might require some kind of heuristic. It would have to produce "good enough" results in very few iterations, without fail. Newton-Raphson or something similar might work.

If no suitable heuristic can be found, we'd have to forego some of the corrections, but not all. Tower lean and joint slop are still useful. You can combine them with the real-time acceleration of the effector and carriages to figure out an offset, and add that to the requested position in order to get the (approximated) real carriage positions necessary to produce the requested effector position. The tweaked rotation of the effector may still be useful for correcting for errors in Z, if not X or Y.

[626Pilot]

yes sure did!! working great definitely getting more print area out of this thing then before! I think i need to work on my switch setup to improve reliability.

its sad that you aren't developing for smoothie anymore.

I haven't settled on a new controller yet (looks like either BBB+CRAMPS or Duet). I'm still looking through the source code for the software behind both of those. Leaning towards the Duet because although it's gross Arduino IDE stuff, it's still fast-ish (84MHz), RISC, has 64+32K RAM, and - most importantly - the software looks to be both much simpler, and much less dependent on gathering information from disparate sources. Still, I like the BBB's hardware a lot better. It has exponentially more CPU speed and RAM, making it that much more future-proof. I can see people still running BBB+CRAMPS in five years, but the Duet, not so much - it's too limited to survive that long, I think. There will be more and more new stuff that people will come to expect, stuff that needs more RAM.

That's another reason for me to look beyond Smoothie. It has less RAM than the Duet, won't drive as many steppers, AND it's going to be superseded by the Smoothie 2 next year. My routines take up enough RAM that it's difficult (or impossible?) to run an LCD panel while the main calibration routine is running, which means I probably can't ever integrate it into the menu system, which means it will never come with the user experience it deserves. Not on the Smoothieboard.

The Smoothie 2 platform will have no such issues, running on an Edison microcontroller with ample RAM and an independent sub-processor for real-time tasks. In that way, it's like the BeagleBone solution. However, rather than sitting on top of an OS and requiring stuff from multiple projects that don't necessarily stay in sync with each other, the firmware will run on the bare metal. There will be no configuration or integration issues from having to deal with a separate OS. However, the port is still in its early days - no motion control, lots of things commented out - and I would be surprised if they shipped before Summer 2016.

After they shipped me a board with two capacitors falling off, and Uberclock didn't answer two requests for replacement over the course of a month, I lost confidence in both their manufacturing and after-sale support. It seems to me that my open-source work ought to work for me, to help me make money, in order to earn the time I spend on it. That means I need to develop for a platform I can rely on in production, one where I don't have to worry about things like this.

In the long term, I'd like to develop on a platform that's going to last for a good long time. Maybe that's the BBB. I could even see going back to the Smoothie platform, although they'd have to already be shipping the Smoothie 2 for awhile, and I'd have to not see people complaining about bad service levels when the hardware has a problem. (In other words, not this year.) If I have to migrate away from the Smoothieboard 1 to find a stable production stack, I'm not going to go back and do more development for it - it would have to be the Smoothieboard 2, because if they can get their hardware and service issues sorted out, that platform will have legs for years. The fact that Smoothie runs on bare metal, and you don't have to worry about integration issues or disparate information sources, is what gives it a big advantage.

There are other things I want to do for whatever firmware I wind up going with. For example, Repetier firmware has a temperature controller based on a "dead time" algorithm rather than PID. The only thing the algorithm needs to know is how long it takes the heater to "get underway" from a cold start - and that's easy to derive just from looking at the temperature graph in Repetier Host. It worked really well for me when I was still running that firmware, both for my hot end and heated bed. If I have enough time, I'd like to bring that to whatever firmware I settle on. I've become pretty good at PID tuning by hand, good enough to get my heated bed to stabilize within 0.5C when the auto-tuned PID had it oscillating by over a degree. Even so, it's too much work - and there's too much hocus pocus involved.

There are other things too, like abstracting the robot so that you can have multiple different robots (even different types of robots) on one board. For example, you could have axes ABC on a delta, and axes PQR on a SCARA. You'd use the SCARA to pick parts from a large shelf, and it would present them to a picker on the delta. The delta would then grasp the component and move it into position. The way Smoothie and all other firmware I've seen so far works, you can't have one type of robot on ABC and another on PQR. All the axes have to be for one robot alone.

I'm rambling. Long story short, if I come up with any new innovations between now and the time when I select my next platform, I will push an update and post about it here.

[bubbasnow]

In the long term, I'd like to develop on a platform that's going to last for a good long time. Maybe that's the BBB. I could even see going back to the Smoothie platform, although they'd have to already be shipping the Smoothie 2 for awhile, and I'd have to not see people complaining about bad service levels when the hardware has a problem. (In other words, not this year.) If I have to migrate away from the Smoothieboard 1 to find a stable production stack, I'm not going to go back and do more development for it - it would have to be the Smoothieboard 2, because if they can get their hardware and service issues sorted out, that platform will have legs for years. The fact that Smoothie runs on bare metal, and you don't have to worry about integration issues or disparate information sources, is what gives it a big advantage.

There are other things I want to do for whatever firmware I wind up going with. For example, Repetier firmware has a temperature controller based on a "dead time" algorithm rather than PID. The only thing the algorithm needs to know is how long it takes the heater to "get underway" from a cold start - and that's easy to derive just from looking at the temperature graph in Repetier Host. It worked really well for me when I was still running that firmware, both for my hot end and heated bed. If I have enough time, I'd like to bring that to whatever firmware I settle on. I've become pretty good at PID tuning by hand, good enough to get my heated bed to stabilize within 0.5C when the auto-tuned PID had it oscillating by over a degree. Even so, it's too much work - and there's too much hocus pocus involved.

There are other things too, like abstracting the robot so that you can have multiple different robots (even different types of robots) on one board. For example, you could have axes ABC on a delta, and axes PQR on a SCARA. You'd use the SCARA to pick parts from a large shelf, and it would present them to a picker on the delta. The delta would then grasp the component and move it into position. The way Smoothie and all other firmware I've seen so far works, you can't have one type of robot on ABC and another on PQR. All the axes have to be for one robot alone.

I'm rambling. Long story short, if I come up with any new innovations between now and the time when I select my next platform, I will push an update and post about it here.

well i hope you choose bbb, currently i have a delta machine with changeable heads. i run different profiles based on my needs and turn off or on steppers accordingly. single extrusion, dual extrusion, and laser ether for example. but you could easy expand to use the same board and just move it to a Cartesian style or w/e. you could even use one of them expandable driver board, i think they are supporting 10 steppers or more. you could use first steppers for machine A, and second steppers for machine B

[626Pilot]

well i hope you choose bbb, currently i have a delta machine with changeable heads. i run different profiles based on my needs and turn off or on steppers accordingly. single extrusion, dual extrusion, and laser ether for example. but you could easy expand to use the same board and just move it to a Cartesian style or w/e. you could even use one of them expandable driver board, i think they are supporting 10 steppers or more. you could use first steppers for machine A, and second steppers for machine B

How do you like the BBB, and what cape are you using with it?

[bubbasnow]

bebopr++ with a expanded board peppr/take-5 so i can get the 5 drivers.

I like it, the printer works, it uses the standard gcode not reprap type so takes some adjustment with the slicers.

[626Pilot]

Was it a lot of trouble to get that set up and run day-to-day? How did you get started?

[bubbasnow]

it is definitely missing a-z single source documentation... but with the google group and a few posts here and there on peoples blogs it solved any issues i was having. There are definitely some people doing some really cool things with machinekit on the bbb, i would recommend getting your hands on one and get some motors spinning.

https://groups.google.com/forum/#!forum/machinekit
https://designmakeshare.wordpress.com/2 ... libration/
http://www.machinekit.io/docs/home/
http://beagleboard.org/project/MachineKit/
http://basdebruijn.com/category/machinekit/
http://blog.machinekit.io/p/hardware-capes.html

[626Pilot]

Was looking at the RollieBrator source and noticed something interesting:

https://github.com/RollieRowland/Delta- ... n.cs#L2299" onclick="window.open(this.href);return false;

I notice that he figures out the top tower radii & angles by doing what looks to be simple math. If his method is correct, this could be used to figure out the {X, Y, Z} of all tower endpoints. Tower lean could be discovered by measuring the angle of the vector between the top and bottom of a tower.

I'm putting this here to remind myself later, although I don't know whether it will be useful.

[mhackney]

Hey, quick question on the current state of Heuristic calibration...

I think it was back in March when I last tried it and ran into the issues running it with the ethernet enabled and/or the LCD screen. I just commissioned a new smoothie on a mini kossel and wanted to give it another shot. What is the recommendation now?

On a side note, this is one of 2 smoothies I got at the delta group buy. No issues with caps on these boards but I did notice these are 1.0a boards and have different caps than the 1.0 boards. They are both the surface mount type but the new one is much larger so you would think there would be better area to bond to the board.

[626Pilot]

I think it was back in March when I last tried it and ran into the issues running it with the ethernet enabled and/or the LCD screen. I just commissioned a new smoothie on a mini kossel and wanted to give it another shot. What is the recommendation now?

Reasonable. I suppose I should say something about the "official" status of this Smoothie fork, and my plans for the future.

Since March, I have made substantial improvements to my fork. The probing grid was increased from 5x5 to 7x7. One of the heaviest operations in the heuristics was optimized to run very, very fast, so the annealing finishes in a few seconds rather than a minute. Lots of RAM usage was migrated off the main 32K bus onto one of the 16K buses, so there should be more "main" RAM available. Whether that means you can run Ethernet+GLCD, I don't know. You could try. I would be interested to see the results.

Ideally, I wouldn't have had any trouble getting my bad board exchanged, and would've happily stayed with the Smoothieboard until its successor comes out next year. I could've cleaned up my fork and got the calibration system accepted into Smoothie, and it might have then become a part of the Smoothie 2 firmware. My recent trouble with Uberclock has pushed up my timeline, and made it clear that I need to find a new hardware vendor now. Sadly, that also means finding new firmware.

Before I jump ship, which is likely to happen this month, I would like to merge in all the changes to Smoothie over the last couple of months. There have been some improvements in PID autotune, and probably some other things I haven't seen yet.

If the Smoothie team ships the Smoothieboard 2 next year, and they have a north American supplier who can run a stable, responsive business, I may look at returning. However, I may decide not to if I get heavily invested in some other platform. I am a little steamed that the hardware support has gone down the tubes like this, and I don't know that I want to jump out of the platform only to return a year later. It will be a pain in the ass to migrate and I don't know if I want to do that twice. I also know that some people have bought Smoothieboards specifically to run my fork, and I don't want to jerk people around by asking them to buy a new controller every twelve months.

However, my thinking is necessarily more long-term. If the SB2 is the solution that will still be around in 2020, with the best firmware, easiest configuration, etc., then that's what I'll do. (Uberclock would either have to resume normal operations, or be replaced by another vendor - I simply have no way to deal with them as they are now. I must have reliable after-sale support from any vendor I deal with.) I need to service a small fleet of 3D printers, and I'm willing to endure some pain up front if it means I have a great platform that will stay around for years. I don't know if the Duet will still have legs then, but I feel reasonably certain that controllers like BeagleBone and Smoothie 2 - with tons of RAM and fast CPUs - will be sufficiently future-proof to stick around for that long.

I would also ask the community here what they wanted. I already have a thread in The Lounge asking what controllers people use, or want to. If next year comes and I look at returning to Smoothie, I would want to check in with everyone. It might turn out that the BBB or BBP controller is a better deal anyway, particularly if the Linux end can be sorted out and made as simple as possible.

Frankly, I think basing hardware on the Arduino Due (i.e., the Duet board) was a short-sighted decision. If the Duet was running on a chip with even just 256K RAM, it would be WAAAAAY more future-proof. This decision to use processors with baby amounts of RAM is like Bill Gates saying "640K should be enough for anyone." As soon as you say that, the very second you say that, someone is going to come up with a way to use the machine that requires more than you "think" they'll need. By 2020, the Duet will look every bit as out-of-breath as the Arduino boards do today. Yet, I'm still considering the Duet because it seems like some people already run it, and it has simpler software. I guess the choice is down to "go with the least evil."

[bubbasnow]

Hey, quick question on the current state of Heuristic calibration...

I think it was back in March when I last tried it and ran into the issues running it with the ethernet enabled and/or the LCD screen. I just commissioned a new smoothie on a mini kossel and wanted to give it another shot. What is the recommendation now?

On a side note, this is one of 2 smoothies I got at the delta group buy. No issues with caps on these boards but I did notice these are 1.0a boards and have different caps than the 1.0 boards. They are both the surface mount type but the new one is much larger so you would think there would be better area to bond to the board.

I pulled back in Aug and had to comment out the GLCD and Ethernet to get this to complete. which was totally fine while the machine was sitting next to my computer.

[Nylocke]

I still personally think Smoothie is the way to go. I've been able to successfully order from the EU supplier, and I haven't had problems with quality control (well, not me, my school, but it pretty much means the same). Its a little wonky coming from a lot of Repetier and Marlin use at times, but the Kossel has been pretty slick running it. We need some more adoption by manufactures in my opinion, we need the RAMBo, X3 Pro, Melezi, Printrboard, etc equivalents capable of smoothie. I think more manufactures would offer more quality options.

[626Pilot]

I still personally think Smoothie is the way to go. I've been able to successfully order from the EU supplier, and I haven't had problems with quality control (well, not me, my school, but it pretty much means the same). Its a little wonky coming from a lot of Repetier and Marlin use at times, but the Kossel has been pretty slick running it. We need some more adoption by manufactures in my opinion, we need the RAMBo, X3 Pro, Melezi, Printrboard, etc equivalents capable of smoothie. I think more manufactures would offer more quality options.

UltiMachine (makers of the RAMBo) is working on a successor, but it's SAM3X (Arduino Due) based. If someone ported Smoothie to that platform, there would be BOATLOADS of controllers that would run it. I think the open source 3D printing community is more interested in SAM3X boards than anything else because it's from Atmel, which is like Jesus to them or something.

Of course, Smoothie was created by people who manufacture Smoothieboards so that they'd be able to sell the boards. Realistically, there's nothing in it for them to port Smoothie to the SAM3X family. I don't know if the SAM3X has a real C++ compiler or not, but maybe it does. I know Atmel's 8-bit C++ compiler is weird and old and non-standard. The SAM3X is much more capable, so maybe they gave it a real compiler.

[Nylocke]

Heres hoping.

[626Pilot]

As discussed in the RollieBrator thread, I added support for per-tower scaling. This is functionally equivalent to adjusting the steps/mm.

Clone: https://github.com/626Pilot/Smoothieware.git" onclick="window.open(this.href);return false;
Firmware download: https://github.com/626Pilot/Smoothiewar ... rmware.bin" onclick="window.open(this.href);return false;

The annealing command used to be G31 OPQRS. Now it's G31 HOPQRS. The tower scaling is activated by S. You can try it with different annealing temperatures, e.g. G31 HOPQR S0.01, S0.1, etc. Let me know if the annealer actually modifies the tower scaling variables (you can see that when it prints out the kinematics). On my machine, it barely touches them, and never on the best settings it could find.

Speaking of the best settings it could find, there is a pretty cool new feature, aside from the tower scaling. It will remember the absolute best score (lowest energy) it was able to find, and use those settings when it finishes annealing. Before, it would just stay on the last settings it arrived at, which aren't necessarily the best. (The energy can have a tendency to "bounce" upwards after it finds the best possible settings - this is intended to make that behavior better.)

Anyway, please let me know how it works for you. The tower scaling thing I'm not sure about, but I definitely want to see if people get better results with the "use best settings" feature.

[bubbasnow]

my metal frame should be in my hands monday, i will set that up and test this out! thanks for your hard work!!

side note, ive been pushing gcode to my smoothie with octopi, now that it has a small easy screen to use with it, its possible to forever disable Ethernet and glcd.

[RMLynch]

To 626Pilot,

I've been working on getting a "reputable" and rather large company here in Ottawa, Ontario, Canada to be a reseller of the Smoothieboard. I don't want to mention any names as of now until things become more clear, but as of now, they currently sell and stock the BeagleBone's, Raspberry Pi's, Arduino, etc...

I personally know the Manager of the main store here (he's a great guy & very helpful) and he's already sent out the information to the head office/owner that I forwarded to him.

If all goes well, we could end up with a great retailer for Smoothieboard here in Canada.

Just thought I'd put this out there for everyone. As of now, I had to order two Smoothieboards from RobotSeed and they were great to deal with! It just would be nice to have a "reputable" reseller here in North America!

One that has been around for a LONG time!

[626Pilot]

my metal frame should be in my hands monday, i will set that up and test this out! thanks for your hard work!!

And thank you!

I've been working on getting a "reputable" and rather large company here in Ottawa, Ontario, Canada to be a reseller of the Smoothieboard.

IMO, they should be sold on Amazon. Free 1-2 day shipping if you have Prime, they handle all returns and exchanges, etc.

[RMLynch]

Well at least this way (or something similar) it's rather easy to "speak" with someone in the event of a problem.

More personable I feel.