[Dan]

The AMS2 uses 1/16th microstepping, the maximum. If you feel it is too much you’re welcome to change to SINGLE or INTERLEAVE, which should increase the step size for faster drawing at lower precision.

I can’t guarantee that either one will work with the changes I made to AFMotorDrawbot. I only officially support the kit we make and sell. I may have made optimizations that only work with MICROSTEPPING.

[Dan]

There are two parts to the project.

The robot is loaded with FIRMWARE, which teaches it how to move the motors and listen to a language called GCODE. By sending the right commands you can make the robot do what you want.

Sitting there typing out the commands by hand is so 1965. The Java SOFTWARE makes a nice interface with a menu with buttons and a preview. The software can send all the GCODE to the robot (one line at a time) and has some built in tests to prevent user mistakes.

GCODE mostly tells the robot how to move in lines – move here, move there, move up, move down. The software can make a set of line instructions with the Generators. These include fractals and a few other patterns. The real trick is Converters that look at a picture you chooose. Each converter looks at the picture in a different way and creates a different set of line commands in GCODE.

As an aside, if you write a sweet new Generator or Converter, I’ll include it in the project and you’ll be able to say your code runs on thousands of robots around the world. That might look good on a resume.

Lastly, the software can read some kinds of DXF files. DXF files describe lines already, so they show up in the software exactly as you saved them from some other app. You can save DXF files from Inkscape (free), Fusion360, Solidworks, and more.

[Dan]

I’m not familiar with the ffleurey version of Makelangelo.

Nice robot!

[Dan]

Uh…. if you see MOTHERBOARD=2 then your version of the firmware is very very old.

RAMPS support has existed in the the Makelangelo firmware for some time now.

I’m looking in firmware_rumba/configure.h at line ~147

#if MOTHERBOARD == BOARD_RAMPS
#define MOTOR_0_DIR_PIN (55)
#define MOTOR_0_STEP_PIN (54)
#define MOTOR_0_ENABLE_PIN (38)
#define MOTOR_0_LIMIT_SWITCH_PIN (3) /* X min */

#define MOTOR_1_DIR_PIN (61)
#define MOTOR_1_STEP_PIN (60)
#define MOTOR_1_ENABLE_PIN (56)
#define MOTOR_1_LIMIT_SWITCH_PIN (14) /* Y min */

[Dan]

This is a known arduino issue. They have promised to fix it in 1.6.11.

[Dan]

Uh…. a width change of 10mm is more than enough to see a visible difference. Perhaps I don’t understand your description. Can you post photos or video of what’s going on?

[Dan]

Are you using at least Arduino 1.6.7?

[Dan]

Our motors are 400 steps per turn. The number of steps per turn is hard coded into the firmware. You’ll need to change that number and upload the firmware again.

Does that help?

[Dan]

18″x18″ won’t matter when your GPS has a resolution of +/-360″.

CNCs and 3D printers can get great accuracy because the moving piece is attached to the frame. literally the frame of reference is always fixed. A lawn mower moving over the grass is detached from the frame of reference.

Put another way: you’ll need to find a method to accurately calculate the position of your lawn mower to within 18″ (probably much less than that) relative to your house and lawn. If you can find that, the rest is (relatively) easy. One could drive the lawn mower around in “record” mode, then play back the same recording later to get a pretty good cut of your lawn every time.

[Dan]

If you have a way to make the software more efficient please send in your pull request to the github project.

We do not officially support DIY machines from non-customers, but let’s try.

I suggest you post photos of your setup, a list of your parts, and your software settings. Then maybe someone in these forums can see what’s different.

[Dan]

aha. From the original post I didn’t realize it was a four wheel, or that you were trying to mow a lawn with a robot. It sounded like a DIY segway.

This is considered a very challenging problem you’ve picked. There is usually a difference between where the robot thinks it is positioned and where it is actually positioned. Even GPS only has an accuracy of +/-20′. So as the robot drives around with a fast moving blade, it might drive over the petunias or the curb and into the street.

gcodes and mcodes can tell the robot to move, but have no way to tell the robot “oh and pay attention to your surroundings. don’t run over the garden hose.” a remote will be necessary – the only way I see this working right now is exclusively by RC driving. An RC remote can be attached to an arduino, which will read the PWM signals from the remote, translate one PWM to an angle value and another to a speed value, and command the h bridges to drive the motors.

I’d start by getting a signal from the RC controller to the arduino to Serial (google it) to my PC, and when those numbers are sane then I’d attach the motors (without wheels) and test forward, back, left, and right steering. finally I’d mount all that on a frame. You’ll probably want a separate 9v power supply for the arduino, as it’s easier than adding a voltage divider to run the arduino from the same power supply as the motors.

[Dan]

How did you choose this list of parts? I suspect if you use a 9DOF sensor then you won’t need a range finder – the 9DOF can tell which way it is tilting and then drive the wheels accordingly.

C++ is overkill for most Arduino projects. There are lots of examples online and in the Arduino program to get you started with C. I would build up like so:

– a sketch to drive a motor forward, backward, forward, backward…
– a sketch to read the 9DOF sensor tilt
– a sketch to read the 9DOF sensor tilt and drive the motors forward or back. At this point you might be able to stand on the platform and have it self balance.
– a sketch to read a potentiometer
– adding potentiometer to the previous sketch for left/right turning.

Everything after that is a hardware design problem – where to put the on/off switch, how to mount the batteries, how to build the steering column so you can turn the pot without letting go of the handles, etc.

[Dan]

Please let me know if the new firmware is better. I’d love to see a pic of whatever you’re drawing! 🙂

[Dan]

Hi Ugi,

The dev version is for developers. The only way to run it (reliably) is to build it in Eclipse and run it from there. Instructions can be found here: https://github.com/marginallyclever/makelangelo/wiki

[Dan]

I am running Arduino 1.6.7 and it compiles OK. Please update your Arduino and try again.

[Dan]

Hi!

1) is the state always reversed from the description on the button?

2) I haven’t noticed. Please send me your source image and settings so I can try it myself.

Note to self: make a way to export settings easily.

3) I recently found that the teleport command (G92) was in a different unit of measurement from everything else, for no good reason. I’ve fixed it, but that means all old gcode files would need their G92 command updated. Where it said G92 X[A] Y[B], A and B are 10x larger now (to be mm like everything else)

I was going to detail this in the next Makelangelo software update, which I am testing now.

[Dan]

Please grab the latest here and give it a try. I just ran a long difficult drawing that usually fails and it came out better than I’ve ever seen before.

https://github.com/MarginallyClever/Makelangelo

[Dan]

I am running tests on a machine calibrated to your settings, with the motors unplugged. I have to wait while it draws in real time, which is ~3 minutes wait for every attempt. Not long enough to go do something else! Patience, Dan, patience…

[Dan]

email your phone number to [email protected]. I get free long distance calling for just such emergencies.

[Dan]

> N13 G01 X460 Y840     H0=202965 H1=66541  G0=-73525 G1=-62597 X46.00 Y84.00
> N22 G01 X460 Y840     H0=202965 H1=66541  G0=-73525 G1=-62597 X46.00 Y84.00
> N35 G01 X460 Y840     H0=202965 H1=66541  G0=-73603 G1=-62675 X46.00 Y84.00

H values are obtained from IK(x,y,h0,h1); in polargraph_line(). Something in the way bresenham’s algorithm is counting the number of diagonal steps has produced a rounding error. I’m getting closer to the source of the problem.

[Dan]

when someone sends gcode it triggers line_safe(), which is written to prevent any rounding errors from screwing up the end of a line. line_safe() then calls polargraph_line(), which does the IK, which does not change anywhere on the board, and is independent of the current pen position.

[Dan]

I notice that the error appears to be related to the slope of the line.

[Dan]

This is the first time I’ve had a test case that accurately reproduces the issue. Thank you, @jportway!

I modded the firmware to count the global total number of steps taken each direction.

> N4 G92 X0 Y89.58657   G0=0       G1=0      X0.00 Y89.59
> N8 G01 X-460 Y-20     G0=-57740  G1=138459 X-46.00 Y
> N11 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N13 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N15 G01 X460 Y-20     G0=-138341 G1=57858  X46.00 Y-2
> N17 G01 X-460 Y-20    G0=-57740  G1=138459 X-46.00 Y
> N20 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N22 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N24 G01 X460 Y-20     G0=-138341 G1=57858  X46.00 Y-2
> N26 G01 X-460 Y-20    G0=-57740  G1=138459 X-46.00 Y
> N29 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N31 G01 X460 Y-20     G0=-138445 G1=57884  X46.00 Y-2
> N33 G01 X-460 Y-20    G0=-57844  G1=138485 X-46.00 Y
> N35 G01 X460 Y840     G0=-73603  G1=-62675 X46.00 Y84.00

> N13 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N22 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N35 G01 X460 Y840     G0=-73603  G1=-62675 X46.00 Y84.00

n13, n22, and n35 are supposed to be identical but the global number of steps has changed.
I can now confirm and test for a very small counting error that is accumulating over time.
This is now my top priority.

[Dan]

I wonder if this happens with firmware_ams. that would imply it’s an IK problem, not a stepping problem.

If you draw a triangle right 1m, down 1m, and back to home, you see the difference of a few mm, yes?

[Dan]

I have looked for it in the past and no success yet.
I suspect there is a <= that should be < and it is causing an off-by-one error.

[Author]

Posts