Manipulating smoothie code

Controllers Smoothie
1

Hello,

I am currently working on a masters’ thesis project of designing, constructing, and controlling a linear input delta robot. I have already designed and constructed it, so it is time to control it. I purchased the smoothieboard because of its superior hardware to the arduino. After receiving the board and starting to set it up I am quickly realizing that way way way too much is done for me. I know that is horrible but I want to be able to control exactly what happens, not just adjust some parameters and trust the software to handle the rest.

First, I want to be able to change the trajectory generation of the software. It seems the default software uses a trapezoidal velocity profile, where I want to use a 5th order polynomial which is a little known simple method to ensure continuous position, velocity, and acceleration while avoiding infinite jerk spikes. If anyone is curious about this I can provide a link to the source article.

Second, I want to be able to change the way the software computes the inverse kinematics of the delta robot. My advisor has a different method which I would like to use.

Lastly, I would like to be able to cause the robot to move from one point to another with one joint move as opposed to a linear move (aka don’t chop it up into lots of small moves, just one big move) so that I can record the motion with a optical rotary encoder and compare it to the theoretical trajectory.

The solution to #2 seems relatively simple to me: change LinearDeltaSolution.cpp. Am I correct?

The solution to #1 seems a lot more complicated. I am guessing I have to modify Stepper.cpp but the code is very long and probably pretty complicated.

Is this the correct thing to do (modify those two files)? I have lots of coding experience and I took a c++ course a few years back which it looks like smoothieware is coded in. Lastly, to change this code I assume I just navigate to E:\Source\edge.zip\Smoothieware-edge\src\modules\robot and change them in notepad++ or notepad. Then re-zip edge.zip and replace it, followed by restarting the smoothieboard?

Any input is appreciated!

Imported from wikidot

2

Hey.

About #1, we have actually been working towards that for quite some time. It’s non-trivial.

First it requires doing some refactoring of the planning ( make it time-based instead of distance-based, add the 5th order math to planning ), acceleration ( do acceleration per-step, we have working code for this, but it’s not in mainstream smoothie yet, then do the 5th order math per-step ), and step generation.

It also obviously will mean more math to be done per-step, so lower step generation rates, which probably means it also requires a lot of optimization work.

If you are interested in implementing this, there is actually a lot of existing code, and a very extensive plan in place that makes sure nothing else gets broken and things are implemented the correct “smoothie way”, so tell me and we can work on this.

I can walk you through the existing code and what needs to be done so you get a better idea.

About #2, you are right, you want to change the arm solution.

About #3, that’s essentially going to mean a complete rewrite of all of robot/, which is pretty insane :slight_smile: It’s possible, but it’s insane. Segmentation works great for practical purposes, so it’s very unlikely that would get merged back into Smoothie, unless it provides some significant benefit.

About editing the code, you want to download the code, modify it, then compile it and place the compiled .bin file on the sd card and reset, see <compiling-smoothie [smoothieware.org]; and <<<FLOATING LINK: flashing-smoothie-firmware [smoothieware.org]>

Sorry for making everything so easy, apparently some people like that :slight_smile:

Cheers !

3

Thanks for the reply and the help! I am curious, are you guys working on implementing continuous acceleration for the smoothie, or the 5th/6th order polynomial method? There is actually a third order polynomial method that is commonly accepted as good in the robotics field but still results in an infinite jerk spike. If you are interested, my advisor (who worked as a roboticist at NASA) has made an improvement on the trajectory generation problem which is really quite simple. I know there are a lot of complicated methods of doing it out there but you should take a look at his article!

I messaged you a link to it.

You guys would probably be interested in the sixth order polynomial trajectory generation bit. It essentially uses a sixth order polynomial for position, velocity, acceleration, and jerk along with seven initial conditions (initial/final theta, initial/final angular velocity, initial and final acceleration, and the intermediate theta). It simplifies to a symbolic notation that you can plug everything into and get your trajectory polynomial, instead of an iterative or some other numerical method.

Instead of trying to become proficient enough at c++ to reverse engineer all of your code I think I may just use an arduino mega for my thesis, I am already an expert in arduino programming although it is severely lacking hardware-wise. I will just do the hard computations in the computer and send it the polynomial it is to follow with serial coms. Then use three interrupt timers to time the space between steps. I will definitely return to smoothieboard as soon as I don’t need to do it all myself for the sake of my thesis though haha, I plan on turning my delta robot into a 3d printer as soon as I am done with that.

4

Hey.

Right now, we are working on continuous acceleration. The plan is to then do S-curve ( 3rd order accel ), and then the more complicated stuff you’ll find in something like linuxcnc.

I looked at the article, it’s way over my head, but when I get more into implementing all this I’ll probably get it better.

About the arduino mega, Arduino code is essentially C++ ( with some of the memory management stuff removed ), so there you go, you are definitely proficient enough at C++ to understand and modify Smoothie code :slight_smile:

Cheers.