Dan
Forum Replies Created
-
Posts
-
Are you using at least Arduino 1.6.7?
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?
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.
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.
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.
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.
Please let me know if the new firmware is better. I’d love to see a pic of whatever you’re drawing! 🙂
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
I am running Arduino 1.6.7 and it compiles OK. Please update your Arduino and try again.
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.
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.
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…
email your phone number to [email protected]. I get free long distance calling for just such emergencies.
> 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.00H 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.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.
I notice that the error appears to be related to the slope of the line.
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.00n13, 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.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?
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.Huh!
Length of line affects amount of registration error?
Angle affects registration error?This would explain why circle style works perfectly – if there’s any error it is cancelled out by doing a complete turn. It also explains DXF files are my least favorite – random lines in every direction.
Please send us a pic/video when you get it doing something cool.
I’m looking at the thingiverse link and I can see the shoulder limit switch mount.
From where are you downloading?I could not see the tendon.dxf, so I uploaded it again.
http://www.thingiverse.com/thing:280263Can you show a picture? Is your pulley diameter ~1.27 cm?
It’s reading in DXF files and tracing the lines in the files directly into gcode lines. If the order of the lines seems a little wonky, it’s because the DXF file stores lines first by type (line, spline) and then by starting point ascending y axis. eg, the first line has a start at the bottom of the picture and the second line is the one that starts closests to the bottom. DXF files don’t care about continuity (one line starts where another ends) or bounding region (start point might be higher up the image than where the line travels). I’ve long wanted some kind of optimizer to find and remove these silly issues. spatial reconstruction is not a trivial task and the time it takes grows exponentially larger.
Each program is customized to a slightly different application.
Makelangelo has a few opening lines that tell the machine it’s settings (M101, D01). The settings used to be stored in the machine itself, and were later removed for reasons…. that I don’t remember at this moment. BTW, if you’re using our 20-tooth pulleys then update your pulley size settings because it should be D1 L1.27323 R1.27323
Pycam has many lines with no G command at the start. They are using a feature I only just learned about, which is to use the last-seen g command. Pycam is also expecting a rotating cutting tool (M3).
Makelangelo silently ignores commands it does not recognize. Most of Pycam would fail on Makelangelo.
A few people have requested a command-line only interface. It’s a big project to refactor things into a Model-View-Controller code design pattern, after which I can replace the View with a command line only View. Once it works it would be pretty trivial to run a Makelangelo off a Pi Zero or an ESP8266, which would be nice.
