Forum

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1]
Author Topic: Polargraph with a spray can
AlainB
Newbie
Posts: 1
Permalink
Post Polargraph with a spray can
on: July 9, 2015, 18:45
Quote

Hi there !

First of all thank's for your great project and thank's for sharing your code !

To make a long story short, It has been a while since I wanted to build an hecktor machine, but I've been discouraged by the fact the source code wasn't available (afaik)

So when I discovered your polargraph project It gave me the push to get back on rails.

So first thing first, here is my setup

- one mac with polargraph controller running
- two bipolar steppers
- two timing belts
- one 5kg servo
- two L298N Dual H Bridge
- one arduino uno
- and one spray can !

For this project I'm only interested in vector graphics drawing and as you can guess speed and accuracy are of great importance. (I like drips but I like them more when they are desired)

I started to draw a straight line "abecedaire" which rendered not exactly as expected but with a certain "hand style" though.

Then I figured a fact (that might have been covered in several other topics) which is to draw a straight line, the two motors start together, run the same speed but don't end together. This seems quite normal since they don't have the same ground to cover. If I'm right I think you avoided this problem by subcutting a line into small segments making this discordance insignificant.

You might have considered this other option, which is to set two different speeds for each motors allowing them to start and arrive at the same time, no matter the distance they have to run.

I rewrote the exec_drawBetweenPoint implementing that feature with satisfying results

void exec_drawBetweenPoints2(float p1a, float p1b, float p2a, float p2b, int maxSegmentLength)
{
  // ok, we're going to plot some dots between p1 and p2.  Using maths. I know! Brave new world etc.
  
  // First, convert these values to cartesian coordinates
  // We're going to figure out how many segments the line
  // needs chopping into.
  float c1x = getCartesianXFP(p1a, p1b);
  float c1y = getCartesianYFP(c1x, p1a);
  
  float c2x = getCartesianXFP(p2a, p2b);
  float c2y = getCartesianYFP(c2x, p2a);
  
  // test to see if it's on the page
  // AND ALSO TO see if the current position is on the page.
  // Remember, the native system can easily specify points that can't exist,
  // particularly up at the top.
  if (c2x > 20 
    && c2x<pageWidth-20 
    && c2y > 20 
    && c2y <pageHeight-20
    && c1x > 20 
    && c1x<pageWidth-20 
    && c1y > 20 
    && c1y <pageHeight-20 
    )
    {
    reportingPosition = false;
    float deltaA = p2a - p1a;    
    float deltaB = p2b - p1b;
    
    float speedA;
    float speedB;
    
    if (abs(deltaA) > abs(deltaB))
    {
      speedA = currentMaxSpeed;
      speedB = currentMaxSpeed*deltaB/deltaA;
    }
    else if(abs(deltaA) < abs(deltaB))
    {
      speedB = currentMaxSpeed;
      speedA = currentMaxSpeed*deltaA/deltaB;
      
    }else{
      speedA = speedB = currentMaxSpeed;
    }
  
    usingAcceleration = false;
    
    motorA.setSpeed(speedA);
    motorB.setSpeed(speedB);
    
    changeLength(p2a, p2b);
      
    // reset back to "normal" operation
    reportingPosition = true;
    usingAcceleration = true;
    reportPosition();
  }
  else
  {
    Serial.println("Line is not on the page. Skipping it.");
  }
//  outputAvailableMemory();
}

Well, apart from quite brutals accelerations (no acceleration means "infinite" acceleration right ?) my "abecedaire" looked better.

I think I'll compensate the accelerations with looping path (the hecktor solution) or with some sort of mechanical cushion system.

Anyway, I still have a problem, and that time I'm quite stuck with it at the moment.

When I started to draw curves I had a bigger acceleration issue AND a speed issue related to the fact that sending a long queue of C17 commands made the motors stop and go quite repetitively while I ideally would like them to run the full path smoothly.

I had good results with circle drawing (curves_drawCircle) since one command make the drawing of a complete path (even if it is still subcut into small segments of course). So I assumed I had to make a new command sending all the points of a path (already sampled into small segments) at once and then boom, THE big problem : memory

Here is an example of the command I'm sending

C61,8485.6316-8454.6336-8348.6397-8288.6436-,END

And AFAIK this is the longest command my arduino UNO can swallow with its goldfish SRAM.

So maybe my approach is not the good one but I can't figure a way of having the motors not stopping on every point (or at least not more than a few ms) with that setup. The motors could stop at the end of a path (when the spay can tip is released) and the biggest path won't have a thousand points but a maximum of four points is quite limitating.

After all what I'm trying to achieve is to :
- draw a svg with inkscape (that's ok)
- sample it into small segments (polargraph controller does it quite well even tough a small inkscape extension could do it too)
- send that to the machine and have a "smooth" movement while drawing a path (this is where I'm stuck)

If you or anyone have any idea I'd love to hear them !

Thanks

Alain
Image

sandy
Administrator
Posts: 1449
Permalink
Post Re: Polargraph with a spray can
on: July 11, 2015, 09:00
Quote

Oh this looks great - I love it! Of course, Hektor was the machine that got me started in drawing machine, in fact, in electronics and art and arduino and business! I've always wanted to try something with a spraycan, but never had the time, skill or open space to do it.

The C61 long-command idea can't work for the reason you've found. There is an overhead with the communication protocol, and it's not trivial. If you want to stream coordinates, then a stripped back protocol might be good, but extra work. Most other machine firmwares take this approach - a very sparse, simple command structure, which means its quick.

Removing any unnecessary communications might help with that - so snip out the reportPosition() calls for instance.

The second thing is command buffering. I've only added working command buffering into the arduino code fairly recently, so I wouldn't be surprised to find it didn't work that well.

Third thing. Tool head speed is really important for spray paint - you really want the nozzle to be moving over the surface at a constant, or at least a controllable speed. Polargraph controls motor speed, but does not work out the actual tool head speed.

I don't understand how your speed-matching straight-line algorithm works though - does this really result in straight lines? To create a line that is straight on the page, both motors have to alter their speed throughout the progress of the line, any static speeds will result in a curved line on the page. The sub-sectioning is to get a straight line, rather than to just mask the jaggedy lines.

My fix was to store the commands on a connected SD card, and read them from there, and lo the PolargraphSD was born. Super fast, but not interactive.

sandy noble

Pages: [1]
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.009 seconds.