Well, I solved all the problems. To the point that the robot has been drawing for nearly 7 hours and the sound is horrific. Even show tunes can't drown it out. (Video here)
The lines would always get out of sync at the same point on the wall, so I figured that my counter weights (mannequin hands) were not heavy enough, causing the belts to slip when it got to a certain point. No problem, I attached heavier hands. That made the steppers not really move at all. So, logic dictates the belts weren't slipping but struggling, so far lighter counter weights were required. Luckily I have a selection of hands. The robot is now rocking some sweet plastic hands from a partially articulated 1960s mannequin with pointy boobs.
The lines getting out of sync on smaller drawings is far less apparent as the steppers weren't having to move as much, hence why I only picked up on this as I drew bigger.
Today's drawings were A2 size, the second one taking 5 hours. Next step is to draw A1 which will double the drawing time. The poor wee motor shield will need its own fan soon, the heatsinks just aren't cutting it.
Things I have learned about getting the robot to draw problem free
- Never be organized by bringing in other things to do while it's drawing like books and thesis writings
- Never set up the camera & tripod to make a stop motion of said robot
These things guarantee robot failure.
Bring on the wall size drawings!
We did so many drawings!
I say 'we' because the robot and I are a partnership now.
I can't realise my artistic dreams without it and it can't operate without my drawings.
I nailed the drawing size issue (pulley size was set wrong so they weren't rotating enough, so the pen didn't move as far as it was supposed to)
I re-measured the wall for the 5th time and got another set of numbers (the correct ones)
I fed the robot the G code of my face and it worked really well. (Of course)
THEN I figured it was time to do some actual drawings instead of my face.
SO in Inkscape I converted some drawings to vectors and simplified the paths so there's slightly less lines to draw. The images are saved as .dxf (Drawing Interchange Format), then opened in the drawbot app on my Linux machine, converted to G code, saved as .ngc.
Then I can open the .ngc file in the drawbot app on my windows netbook which is connected to the robot. It's a terribly messy work around but until I can get Linux to see the robot in the java app that's how it goes. Ideally the drawbot app on the netbook should just take the .ngc, convert it to G code and draw.
I set the robot to draw A1 size, double checked it knew where the paper ended (so I don't draw on the wall) Everything was looking good so I hit the draw button. Then shit got weird. It was supposed to be drawing a circle but it clearly wasn't. The app keeps track of where it's at with the drawing and it wasn't matching up to what was happening on the wall. I stopped the drawing, double checked all the measurements in the drawbot app and gave it a different image. It drew the outline of the image correctly but when filling in the detail it was all over the show.
Naturally I thought the computer has just spat out some dodgy G Code, no problem. I can generate some more. After all, the files have been through a few conversions; .XCF > .PNG > .DXF > .NGC. So I re-set the robot and fed it the G code of my face, knowing that it has drawn from that code before with no issues. Annnnd that's where the logic ended. Robot ended up drawing my face stretched horizontally, then it decided that its 'home' point was at the bottom of the wall, not the centre where I set it to.
At this point I've got no idea what the fuck it's up to, given I haven't changed anything other than paper size. I'm going to re-flash the Arduino with the drawbot firmware and give it another go tomorrow. There is no logical reason this will work given I didn't alter anything important. But with windows you never know.
I'll also continue working on getting the setup to run under Linux. This is where I'm at:
The Arduino IDE under Linux can see the robot but the java based drawbot app can't. (Even if I run the app as root) I think it's something to do with serial port permissions under Linux.
To date I have:
For now I'm just trying to get my main computer to pick up the Arduino in the java app, when it does I will re-create the setup on an old laptop. The robot will never run under Linux on the netbook because the HDD is formatted as NTFS in order to dual boot with windows. Linux won't run a java app when the HDD file system is NTFS for security reasons that Google says can't be bypassed. Linux file systems are typically formatted to ext3 or ext4. Not a lot would give me more pleasure than removing the windows partition for good but it does come in handy twice a year. (Also borrowing a laptop to test something in windows means using windows 10 and I struggle to even find the control panel)
In the long run it's important for me to get the drawbot running solely on Linux as I'm strongly against closed source computing. What's the point of creating an entirely open source robot but it has to run through windows? The only reason I keep a small windows partition on my netbook is for testing things like powerpoint presentations which don't always port over from Linux well (which I have to use at art school occasionally)
End goal is to return to this:
Turns out the issue with the robot was the shit G code generation done in the app under windows. Another reason I avoid windows at all costs.
Generating the G code under a Linux OS, opening it under the app in windows is a functional work around for now. Generating G code for the images under windows adds weird functions to the start of the code, freaking the robot out. Despite doing it all within the robot's native app on both OS's, I've decided that Windows must be missing a dependency and I have no idea what it is. Linux will go 'Hey, I see you're after this package, in order for it to run you need these too, I'll go ahead and install them for you"
The remaining issue of drawing size stems from my poor math, and this is why:
It really needs a better name than that.
Anyway. It was all physically built. It moved and kinda drew images. Queue celebratory wines!
The software I was using to control the machine was terribly buggy and changing the variables of pen and pixel draw size etc was a nightmare. They would only sometimes change in the UI, I'd end up editing some values in notepad, then re-starting the app. Which took forever. In the end I gave up and found something better. This turned out to be a massive improvement - temporarily.
The image handling of the new program is amazing, it turns an image into a single line which is interpreted as a bunch of Gcode. (essentially X Y coordinates). I hit the draw button and it sprung into life, sounding like R2D2 on acid, as it was pointed out to me. The stepper motors were going way too fast causing a jittery line. No problem, I'll just go into the firmware code and set the speed a bit lower. And it hasn't worked since.
I've re-downloaded a fresh version of the firmware, uploaded it to the arduino and still it won't draw. I can hit various buttons in the software that tell it to move the pen left/right up/down and it complies. But as soon as I send it the Gcode to draw, it won't move. I'm at a total loss.
So I've relocated the moving parts home where I will continue to figure this all out while sitting around in my PJs, drinking cups of tea whilst listening to k.d. Lang and various show tunes in order to keep myself calm.
I will figure this out, it's just taking longer than expected.
Sporadic rants of an angry queer feminist artist. Regular updates on Instagram