Once I've got the firmware ironed out I intend to write up the ESP32 build as an instructable or at the very least a series of blogposts - it's actually really straightforward and easy to breadboard so the Polarshield v3 board itself is much less necessary than the old v2 was for the Arduino.
At the moment I'm just getting the ESP32 to be feature-complete compared to the old version, and I keep on coming across bits that I've forgotten about (like SD card reading, oops). As you probably know though, the ESP32 has got stacks of memory and horsepower so I really want to make it much more standalone eventually, able to read SVGs and bitmaps directly. The main problem I have with that is that I'm not good with programming of any real sophistication in C, so that might be a micropython project for another day.
Wireless is the other freebie with the ESP32. Not working on it yet, but I'm told (and I read) that a bluetooth serial port is reasonably reliable. I'm skeptical!
sn
↧
Re: Compiling issues
↧
Re: Kia Ora from New Zealand
hello
i am new here
_______________
Malaysia tour packages
↧
↧
Re: Repeatable Errors on Plots
Ok, good news and bad news:
Good news is I got a chance to draw out the hilbert curve svg that you were trying. Bad news is that it drew out fine - no distortion.
I used the current version of the Polargraph controller, with the SVG at the same scale as yours, on the same sized page. My machine is not the same size as yours, but not far off.
The hardware is different though: I'm using a Polarshield, which sits on an Arduino MEGA 2560 and wires up two A3988 motor drivers, hardwired to microstep at 8x.
Usually this uses the polargraph_server_polarshield firmware, but I also tried with the polargraph_server_a1 firmware, with serial steppers configured - same result.
![Image]()
The rest of the hardware is a 9v, 2.66A PSU and two NEMA 17HS13-0404S steppers, motor speed and acceleration were around 2500 (that includes microsteps, so it'd be 5000 on yours to move at an equivalent speed on the page).
Hypothesis: This hilbert curve is a bit of a "torture test", cramming in as much back-and-forth as possible to try and prompt tiny errors, then magnify the consequences of it. I'd be amazed that physical errors (overshooting or dropping steps) would be so consistent between runs, and that there was no sign of them during other drawings (the crown)... But I've been amazed before. Perhaps if you drew hundreds of tiny crowns you'd find that they lost integrity too.
On my stepper drivers I can tune the current to give more or less torque/grip. If yours can also, look at bumping them up a little and see if that makes any difference.
This is a fascinating exploration!
You could try to replicate my settings more exactly by changing to step multiplier of 8 (will still work fine, but will lose half of it's internal resolution) if that's appealing. I don't imagine it will make any difference though.
The rest of the hardware is a 9v, 2.66A PSU and two NEMA 17HS13-0404S steppers, motor speed and acceleration were around 2500 (that includes microsteps, so it'd be 5000 on yours to move at an equivalent speed on the page).
Hypothesis: This hilbert curve is a bit of a "torture test", cramming in as much back-and-forth as possible to try and prompt tiny errors, then magnify the consequences of it. I'd be amazed that physical errors (overshooting or dropping steps) would be so consistent between runs, and that there was no sign of them during other drawings (the crown)... But I've been amazed before. Perhaps if you drew hundreds of tiny crowns you'd find that they lost integrity too.
On my stepper drivers I can tune the current to give more or less torque/grip. If yours can also, look at bumping them up a little and see if that makes any difference.
This is a fascinating exploration!
You could try to replicate my settings more exactly by changing to step multiplier of 8 (will still work fine, but will lose half of it's internal resolution) if that's appealing. I don't imagine it will make any difference though.
↧
Re: Drawbots from around the web
DrawBot Badge (preview) by Bart Dring
http://www.buildlog.net/blog/2018/09/drawbot-badge-preview/
![Image]()
↧
Re: Invert Masked Colour
Nice man. I've sent you a PM regarding some problems Ive had on your forum too.
Did you have a chance to look at it?
↧
↧
Re: Invert Masked Colour
Nope - couldn't PM you...
Here goes:
Gday Sandy,
I have tried a few times to login to talk about this but I've had a heap of problems logging in. I keep getting errors with the recapture verification. No matter what I do, I seem to fail the recapture verification.
I run a VPN (in my router) and two AdBlockers in Google Chrome. If I kill all of these processes I can login but it still goes through three to five recapture processes.
It kind of makes it difficult to login and after 10 or so mins of trying I give up.
↧
Re: Invert Masked Colour
The forum captcha might not be ideal for everyone, but the level of capcha'ing means I only have to kick/delete/cleanup spam every week as opposed to hundreds of times a day.
I've just pushed a change to https://github.com/euphy/polargraphcontroller that includes a new button to change how the mask works, so it either
1) does nothing
2) hides pixels that match the colour
3) hides pixels that _don't_ match the colour
I think 3 has the same effect as inverting - let me know if I've understood properly (sandy at polargraph co uk if you can't get onto the forum) and if it works for you!
It could really do with a better colour picker!
sn
↧
Trying to compile Polagraph 3.0 firmware on Lolin 32
Greetings!
i love your upgrade on your Polargraph 3.0 board.
I downloaded the firmware from your Github, and am having some trouble compiling it. This is before even getting it on the board.
1). I included the board ESP32 etc in the preferences, so I can choose my board.
When compiling I have had these errors:
1) fatal error: ESP32_Servo.h: No such file or directory
I added the Library ESP32Servo by John Bennett Vs. 0.1.0
But it is ESP32Servo.h not ESP32_Servo.h
I took out the underscore in the sketch. But am I using the correct library?
2) fatal error: ESP32Ticker.h No such file or directory compilation terminated. I did not find that library for ESP32, just standard arduino.
3) fatal error: Metro.h: No such file or directory compilation terminated.
I downloaded a Metro library from github, but I read there are several versions. Where can I find the one you use here?
4) error: #error "You could try defining ENCODER_DO_NOT_USE_INTERRUPTS as a kludge."
#error "You could try defining ENCODER_DO_NOT_USE_INTERRUPTS as a kludge."
I'd love to get this running.
Any suggestions would be appreciated.
Max
↧
Re: Trying to compile Polagraph 3.0 firmware on Lolin 32
Hi Max, you're the first to try the new platform :) It's far from settled!
Just a couple of days ago I've changed the structure of the project so it includes the libraries I'm using. Some of them are going to stay, some might change. I'm using PlatformIO (with VSCode) to actually write these days, so that folder structure is a platformio project folder structure. Usefully, it allows you to have local copies of libraries installed per project, rather than everything having to share global copies. Dangerously, that's allowed me to make some local modifications, so that's why I've rolled the libraries into the repo.
1) ESP32_Servo ... I'm confused about the provenance of the version I'm using, the library.properties file describes it as John K BEnnett's v1.0, but very recent changes (last 4 days) have updated a few things about it, namely to 0.1.0 and there's a new co-author and it's got no underscores anymore! I think I just have an old version.
2) ESP Ticker... This is Bert Melis' Ticker-esp32 (https://github.com/bertmelis/Ticker-esp32) but it's also recently been merged into the main Arduino core for ESP32. However! I've hacked a local version that has microsecond timing rather than millisecond. That is included in the current lib/Ticker folder of the polargraph firmware. Right at this minute, the code doesn't use the microsecond timing (attach_micros()) because I'm trying a different approach to get more even stepping. I've not settled on the best way to do that yet. Actually I've got an uneven-ness that I'm trying to figure out if its in the hardware (the new polarshield v3) or in the software. I've got some days free over the next week to try to get to the bottom of that.
3) Metro is this one: https://github.com/thomasfredericks/Metro-Arduino-Wiring
4) Encoders aren't even really used yet but the library is there. The standard lib needs a couple of extra lines in direct_pin_read.h (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/lib/Encoder/utility/direct_pin_read.h#L33-L39) and interrupt_pins.h (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/lib/Encoder/utility/interrupt_pins.h#L176-L207) to make it work with ESP32. This was tested to make sure that it compiled and that the numbers changed when I twiddled the encoders, but I haven't tested whether it works in a realistic situation.
Most of it works ok, but there's a big question over the basic stepping engine. The most recent changes push the calls to motor.run() into a separate task in the the ESP32 operating system, and then call that task periodically with a task notification, and the task notification is driven by a timer that creates an interrupt every 100us. It works (amazingly) and does trigger that runMotors() task 10,000 times a second which is what I'm looking for. BUT, I can hear serious quantisation ("banding") in the acceleration profile, and when I step really slowly it's obvious that there are steps being quantised. I don't think it's missing steps as such, in the sense that the full motor steps are happening, but microstepping isn't smooth. I can't imagine that the software has anything to do with that, so that's why I'm going to focus on some hardware tests this weekend (I've got some beta testers waiting for these new machines!).
The old method of running the stepper motors was completely synchronous, so it'd block while stepping until the target position was reached. It made it really simple and also guaranteed that there was absolutely nothing else happening at the time, no interrupts, no competing tasks (well UNO/MEGA doesn't have multitasking). So I'm not clear if the way this new stepping pattern sounds is bad or if it's just different.
The pinouts for the motors are probably obvious from the code but shout if you get stuck. You might have a problem with the display & touchscreen if you don't have one connected, because it will try to do a screen calibration (touch the corners etc) if it detects that the screen hasn't been calibrated yet. You can probably avoid it by commenting out the call to touch_calibrate() (https://github.com/euphy/polargraph_server_polarshield_esp32/blob/master/src/configuration.ino#L169) but also be aware that the touch response might get triggered by something else if those touch lines aren't controlled.
Good luck! Would love to hear if you get results.
sn
↧
↧
Re: Trying to compile Polagraph 3.0 firmware on Lolin 32
Thank you!
I'm not in a rush. I follow you on Instagram. I keep coming back to this project every once in awhile. I really like playing with these ESPs. I can't believe how cheap they are and capable.
I'm working on some Scara robot stuff too.
↧
Buying Polargraph v3.0 Questions
Hey Sandy, are you planning to offer a "just the new electronics kit" for those of us who want to upgrade? If so, when-ish?
↧
Windows driver
I read the article in the forum where the polargraph was used as a large format plotter to print the patterns for a giant 3d bear
http://www.polargraph.co.uk/2013/02/polargraph-pepakura-and-corrugated-cardboard-giant-office-bear/
One thing led to another and I'm interested in attempting something similar but smaller to start with.
At some point I will need to print from Pepakura , I'm not at that stage yet but I wondered if you had ever considered writing a Windows printer driver for the Polargraph Sandy
↧
Re: Windows driver
Pepakura exports SVG files which the polargraph software handles fine, so there should be no problem.
↧
↧
Re: Buying Polargraph v3.0 Questions
Hi! Hope you're well! At the moment the new machine doesn't do anything different to the old one so there's no real reason to upgrade. Once I roll some new features into it then it'll be worthwhile. Possible new features will be:
* Changing machine spec from the touch UI (rather than having to usb-tether for it). This could probably be back-ported to v2 hardware easily enough.
* Connect serial port wirelessly, either bluetooth or wifi. The hardware is all there for this, but I think this is more complicated than it seems at first.
* Control the machine with a simple built-in ui accessed via a browser. I sure don't want to be writing a web UI using C, so I need to investigate how to build this in something more suitable (python probably) and how it can co-exist with the realtime motor-driving part of the machine.
* Encoders for closed-loop movement, fault tolerance, using the gondola as an input device. In a simple form this was actually well-tested with the Polargraph Pro for the Science Festival a couple of years ago. The Polarshield v3 has pins for it, but needs a good motor/encoder unit designed.
* Endstop switches for auto-homing. Pins are ready for it on v3, but no hardware yet to plug into it.
* Direct draw from SVG or bitmap on SD card. I think this is practical on this machine, but the UI needs a bit of thinking - how to specify size, position etc.
Until those features start creeping into the code, v3 is just a replacement rather than an upgrade. That said, I would like beta testers for the new machine.
sn
↧
Re: Windows driver
Yes I did look at running as a printer driver at one point, but I got too startled by Windows programming. It's not trivial and SVG export / import _usually_ works fine like Kongorilla says.
sn
↧
stripping down the code to bear minimum?
hello
hows it going
i have an idea and would like some help
im curently using the polargraph adfruit version code and its working fine.
this code:https://github.com/euphy/polargraph_server_a1
but id like to learn how to do it myself and was looking to try stripping down the code to the bare basic code needed.
so far the code
uses
sd card fucnitons
eeprom functions
pen up/down functions
and much more including gcode conversion.
but really thats to much to understand.just yet so im trying to create a simple sketch that allows me to just write something like this in loop to draw a square.
void loop(){
drawline(40,0 ) //i.e right 40
delay()
drawline(40.-40 ) //up 40
delay()
drawline( -40.-40)//left 40
delay()
drawline(-40,0)//down 40
}
is there someone that could help point me in the direction of which functions do the processing of kinematics.
i understand the theory of making a vplotter but still a bit over my head.
so far i have understood that i get lenght of thread moved per each step.
and if i know the distance from motor to motor i can then somehow create a x,y coordinates system and convert it to lenghts of thread to each motor and increment them as needed to create a line. but thats where i blow up hah.
if anyone could give me some advice it would be great
thanks
↧
Re: stripping down the code to bear minimum?
Hi plottingmad! Yes, the vast majority of the code in most drawbots is to handle the command protocol rather than the actual drawing mechanics. That's the good news, because it really means that the actual drawing mechanics are pretty small and simple.
This code that formed the AS220 machine (https://web.archive.org/web/20090522073800/http://www.as220.org:80/labs/Code/drawbotErikSatie.txt) was the first I saw with source attached. Some of this still lives on inside Polargraph actually - spiral pixel uses these curve routines.
It's reasonably understandable on it's own, and it's about as stripped back as you'll get I think, there's no comms or commands as such.
In Polargraph, look in the util.ino file for the kinematics - there's a couple of functions in there:
float getMachineA(float cX, float cY)
{
float a = sqrt(sq(cX)+sq(cY));
return a;
}
float getMachineB(float cX, float cY)
{
float b = sqrt(sq((pageWidth)-cX)+sq(cY));
return b;
}
https://github.com/euphy/polargraph_server_a1/blob/master/util.ino#L165-L174
Given a cartesian x and y, these two above work out the length of cord A and cord B, ie the distance to the top left and right corners of the surface.
long getCartesianX(float aPos, float bPos)
{
long calcX = long((pow(pageWidth, 2) - pow(bPos, 2) + pow(aPos, 2)) / (pageWidth*2));
return calcX;
}
long getCartesianY(long cX, float aPos) {
long calcY = long(sqrt(pow(aPos,2)-pow(cX,2)));
return calcY;
}
https://github.com/euphy/polargraph_server_a1/blob/master/util.ino#L225-L242
The two above do it in the opposite way, converting the native machine coordinates (distance from the top corners) into cartesian coordinates. Note that you need to work out the cartesian X first, and use it as a parameter to work out the Y.
sn
↧
↧
Re: stripping down the code to bear minimum?
hey sandy thanks for the reply already i have understood allot more about whats going on..
and the code you gave me from AS220 Labs is very easy to read compared to a full blown vplotter with eeprom and such.
but as im not a naturally math man or programmer i still have more questions now.
in your code for the polargraph i notice you use the accel stepper lib can i ask why you did not make you own step function to drive them high low?
is the accel stepper lib good ?
im only asking as i have recently been trying to learn about interrupts and port manipulation via the amazing tut from iforce2d here :https://www.youtube.com/watch?v=fHAO7SW-SZI
which has really helped me learn more about motors.
i have taken out all the circle and drawing of the image to completely simplify it to just lines up,down,left or right
i have added some comments with an abundance of questions.sorry!
i was unable to get the original stepper.h to work as i have no clue what pins do step/dir on the adafruit v1 motor shield
i read here https://learn.adafruit.com/adafruit-motor-shield/faq
that these pins are used but with a serial-to-parallel latch which i think does not use step and dir ?
so i changed to the original AFmotor shield lib.
i have uploaded the code at paste bin with come more questions here.
https://pastebin.com/bJkdHDzE
i understand your getmachineA();
the same as the old drawbot code here
int a1= sqrt(pow(x1,2)+pow(y1,2));
int b1= sqrt(pow((w-x1),2)+pow(y1,2));
but if i get the distance to top right/left motors i.e length of steps i dont understand in which way i call up or down?is it minus for left and down and + for right and up?
thanks again man im going to be playing tonight.
↧
Re: Drawing Gallery - For Finished Drawings -
↧
Re: stripping down the code to bear minimum?
Have a look at my version here: https://pastebin.com/kmM5nU7z I've not tested it but it compiles at least.
I've added some extra comments and cleaned up the variable names a bit to make them more clear hopefully.
You should use the AFMotor library if you've got an Adafruit style Motorshield with L293D H-bridge drivers. Those are not stepper drivers so there is no step+direction pins that you can simply drive high or low to make a step happen. You have to set the specific combination of the four stepper motor wires in a specific sequence in order to make a move.
Accelstepper supports non-blocking motor stepping and obviously acceleration. I think it's brilliant.
Regarding your last point, I'm not sure I understand. IF motorA is top-left, and motorB is top-right: Moving motorA plus will make the pen move down the drawing surface in a curve, swinging around motorB which isn't moving. Moving motorA minus will pull the pen up the page in the same arc.
Motor motorB plus will move the pen down in a curve, as it swings around motorA which isn't moving. Moving motorB minus will pull the pen up the page in the same arc.
All of the target positions are absolute, and positive though. It's not possible to move the pen to a negative position (it would be off the top of the machine!).
sn
↧