The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Taking & making images.
A Great Blue Heron kept watch over us from the decaying spillway as we walked along on Old Mill Road:
A mid-stream perch provided a better vantage point:
The concrete slab in the lower right corner came from the dam breast.
The camera never lies, but if you could look upward just a bit, you’d see the unending stream of cars passing by on Red Oaks Mill Road at the Rt 376 intersection …
We often see a hawk perched atop a street lamp along Hooker Avenue, but this is the closest we’ve come:
That first wingbeat must be exhilarating:
There doesn’t seem to be much behind the notion of reincarnation, but one interation as a bird would be edifying…
In the course of running off some Superformula plots, I found what must be my original stash of B-size plotter paper. Although it wasn’t archival paper and has yellowed a bit with age, it’s the smoothest and creamiest paper I’ve touched in quite some time: far nicer than the cheap stuff I picked up while reconditioning the HP 7475A plotter & its assorted pens.
Once in a while, all my errors and omissions cancel out enough to produce interesting results on that historic paper, hereby documented for future reference…
A triangle starburst:
A symmetric starburst:
Complex meshed ovals:
They look better in person, of course. Although inkjet printers produce more accurate results in less time, those old pen plots definitely look better in some sense.
The demo program lets you jam a fixed set of parameters into the plot, so (at least in principle) one could reproduce a plot from the parameters in the lower right corner. Here you go:
The triangle starburst:
The symmetric starburst:
The meshed ovals:
The current Python / Chiplotle source code as a GitHub gist:
| from chiplotle import * | |
| from math import * | |
| from datetime import * | |
| from time import * | |
| from types import * | |
| import random | |
| def superformula_polar(a, b, m, n1, n2, n3, phi): | |
| ''' Computes the position of the point on a | |
| superformula curve. | |
| Superformula has first been proposed by Johan Gielis | |
| and is a generalization of superellipse. | |
| see: http://en.wikipedia.org/wiki/Superformula | |
| Tweaked to return polar coordinates | |
| ''' | |
| t1 = cos(m * phi / 4.0) / a | |
| t1 = abs(t1) | |
| t1 = pow(t1, n2) | |
| t2 = sin(m * phi / 4.0) / b | |
| t2 = abs(t2) | |
| t2 = pow(t2, n3) | |
| t3 = -1 / float(n1) | |
| r = pow(t1 + t2, t3) | |
| if abs(r) == 0: | |
| return (0, 0) | |
| else: | |
| # return (r * cos(phi), r * sin(phi)) | |
| return (r, phi) | |
| def supershape(width, height, m, n1, n2, n3, | |
| point_count=10 * 1000, percentage=1.0, a=1.0, b=1.0, travel=None): | |
| '''Supershape, generated using the superformula first proposed | |
| by Johan Gielis. | |
| – `points_count` is the total number of points to compute. | |
| – `travel` is the length of the outline drawn in radians. | |
| 3.1416 * 2 is a complete cycle. | |
| ''' | |
| travel = travel or (10 * 2 * pi) | |
| # compute points… | |
| phis = [i * travel / point_count | |
| for i in range(1 + int(point_count * percentage))] | |
| points = [superformula_polar(a, b, m, n1, n2, n3, x) for x in phis] | |
| # scale and transpose… | |
| path = [] | |
| for r, a in points: | |
| x = width * r * cos(a) | |
| y = height * r * sin(a) | |
| path.append(Coordinate(x, y)) | |
| return Path(path) | |
| # RUN DEMO CODE | |
| if __name__ == '__main__': | |
| override = False | |
| plt = instantiate_plotters()[0] | |
| # plt.write('IN;') | |
| if plt.margins.soft.width < 11000: # A=10365 B=16640 | |
| maxplotx = (plt.margins.soft.width / 2) – 100 | |
| maxploty = (plt.margins.soft.height / 2) – 150 | |
| legendx = maxplotx – 2900 | |
| legendy = -(maxploty – 750) | |
| tscale = 0.45 | |
| numpens = 4 | |
| # prime/10 = number of spikes | |
| m_values = [n / 10.0 for n in [11, 13, 17, 19, 23]] | |
| # ring-ness 0.1 to 2.0, higher is larger | |
| n1_values = [ | |
| n / 100.0 for n in range(55, 75, 2) + range(80, 120, 5) + range(120, 200, 10)] | |
| else: | |
| maxplotx = plt.margins.soft.width / 2 | |
| maxploty = plt.margins.soft.height / 2 | |
| legendx = maxplotx – 3000 | |
| legendy = -(maxploty – 900) | |
| tscale = 0.45 | |
| numpens = 6 | |
| m_values = [n / 10.0 for n in [11, 13, 17, 19, 23, 29, 31, | |
| 37, 41, 43, 47, 53, 59]] # prime/10 = number of spikes | |
| # ring-ness 0.1 to 2.0, higher is larger | |
| n1_values = [ | |
| n / 100.0 for n in range(15, 75, 2) + range(80, 120, 5) + range(120, 200, 10)] | |
| print " Max: ({},{})".format(maxplotx, maxploty) | |
| # spiky-ness 0.1 to 2.0, higher is spiky-er (mostly) | |
| n2_values = [ | |
| n / 100.0 for n in range(10, 60, 2) + range(65, 100, 5) + range(110, 200, 10)] | |
| plt.write(chr(27) + '.H200:') # set hardware handshake block size | |
| plt.set_origin_center() | |
| # scale based on B size characters | |
| plt.write(hpgl.SI(tscale * 0.285, tscale * 0.375)) | |
| # slow speed for those abrupt spikes | |
| plt.write(hpgl.VS(10)) | |
| while True: | |
| # standard loadout has pen 1 = fine black | |
| plt.write(hpgl.PA([(legendx, legendy)])) | |
| pen = 1 | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy)])) | |
| plt.write(hpgl.LB("Started " + str(datetime.today()))) | |
| if override: | |
| m = 4.1 | |
| n1_list = [1.15, 0.90, 0.25, 0.59, 0.51, 0.23] | |
| n2_list = [0.70, 0.58, 0.32, 0.28, 0.56, 0.26] | |
| else: | |
| m = random.choice(m_values) | |
| n1_list = random.sample(n1_values, numpens) | |
| n2_list = random.sample(n2_values, numpens) | |
| pen = 1 | |
| for n1, n2 in zip(n1_list, n2_list): | |
| n3 = n2 | |
| print "{0} – m: {1:.1f}, n1: {2:.2f}, n2=n3: {3:.2f}".format(pen, m, n1, n2) | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * pen)])) | |
| plt.write( | |
| hpgl.LB("Pen {0}: m={1:.1f} n1={2:.2f} n2=n3={3:.2f}".format(pen, m, n1, n2))) | |
| e = supershape(maxplotx, maxploty, m, n1, n2, n3) | |
| plt.write(e) | |
| pen = pen + 1 if (pen % numpens) else 1 | |
| pen = 1 | |
| plt.select_pen(pen) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * (numpens + 1))])) | |
| plt.write(hpgl.LB("Ended " + str(datetime.today()))) | |
| plt.write(hpgl.PA([(legendx, legendy – 100 * (numpens + 2))])) | |
| plt.write(hpgl.LB("More at https://softsolder.com/?s=7475a")) | |
| plt.select_pen(0) | |
| plt.write(hpgl.PA([(-maxplotx,maxploty)])) | |
| print "Waiting for plotter… ignore timeout errors!" | |
| sleep(40) | |
| while NoneType is type(plt.status): | |
| sleep(5) | |
| print "Load more paper, then …" | |
| print " … Press ENTER on the plotter to continue" | |
| plt.clear_digitizer() | |
| plt.digitize_point() | |
| plotstatus = plt.status | |
| while (NoneType is type(plotstatus)) or (0 == int(plotstatus) & 0x04): | |
| plotstatus = plt.status | |
| print "Digitized: " + str(plt.digitized_point) | |
We ride through the intersection at the Rt 55 end of Burnett Blvd a lot, because it’s the only route between Raymond Avenue and the Dutchess Rail Trail. Previous posts have documented the signal timing, but this sequence shows the situation we’ve feared from the beginning… cross traffic not stopping because we are in the intersection with an opposing green light.
I’m towing a trailer with three bags of groceries.
The sequence numbers indicate the frame at 60 f/s.
T +0.000 = our signal just turned green:
T +1.250 s = the drivers ahead of us release their brakes and begin rolling:
T +2.400 s = we begin rolling:
It’s worth noting that we cannot start any earlier, unless you regard jumping the green and passing cars at an intersection as Good Practices, which we don’t.
T +7.217 s = the yellow signal goes on in our direction:
That’s six whole seconds from the time the cars started rolling and 4.8 s from the time we started.
Notice the white car to our right that’s stopped in the leftmost eastbound lane of Rt 55.
T +12.100 s = our signal turns red:
I’ve reached the middle of the intersection, Mary’s about centered on the three eastbound lanes of Rt 55.
T +13.333 s = the opposing signal turns green:
Traffic in both directions of Rt 55 can now begin moving, but the white car remains stopped; it’s almost directly behind me in the leftmost lane. Because Mary is following the curved line guide lines, she’s just entering the rightmost lane. What you can’t see is a black car approaching from behind her that didn’t have to stop.
T +20.950 s = the car in the right lane that didn’t have to stop passes me:
I’m 140 feet from the stop line (figured with the distance calculator):
At 40 mph = 60 ft/s, that car passed the stop line 2.3 s earlier, at T +18.7 s, when I was still crossing the right lane.
It’s entirely likely that the driver didn’t see either of us while approaching the intersection, because he (let’s assume a he for the sake of discussion) had a green light nearly 5 s = 300 ft before reaching the stop line. Unless he’s paying more attention than most drivers, he was intent on the signal to judge whether he must slow down; for the last 7.3 s he’s known that the intersection is clear, because nobody else should be in the intersection against his green signal.
T +24.667 s = The white car in the left lane passes Mary:
All I’m asking NYSDOT to do is lengthen the signal timing so we’re not caught in the middle of the intersection by opposing traffic with a green signal. Adding a few seconds onto the yellow and minimum cycle time doesn’t seem unreasonable, but it’s been six months since I reported the problem with no action; I’ve pinged their Bicycle & Pedestrian coordinator several times with no response.
If their engineers are “studying” the situation, it’s not producing any visible results; they haven’t asked me for any additional data.
I Am Not A Lawyer, but I think my collection of photos should provide sufficient evidence to convince a jury that NYSDOT is totally liable for any bicycling injuries at that intersection, based on the inability of cyclists to meet the signal timing. I really don’t want to find out if I’m right…
Well, a picture of my circuitry, anyhow, there in the upper-right corner:
It’s the avalanche noise random number generator:
I’m pretty sure they color-negatived it to suppress that retina-burn magenta PETG holder.
It wasn’t for my column, but the Tinny cover painting for Circuit Cellar Issue 29 (“Measurement and Control”) hangs near my desk:
Back then, I was writing the Firmware Furnace column. Ah, those were the days…
Rolling through the back of the Vassar Campus, watching a murder of crows on the lawn, when all of a sudden:
That squirrel passed about three feet in front of Mary’s bike, running flat out and, at 60 frame/s, touched the ground every 200 ms:
Figuring a squirrel body+tail is 1.5 ft long and it covers 3 of those units with every leap, it’s moving at 22 ft/s = 15 mph. That’s about as fast as we travel…
After 95 minutes on a pleasant ride with temperature around 55 °F, the STK C battery had 0.59 W·h remaining (dark green trace):
The last time around, it had 1.85 W·h after 61 minutes. Subtracting the two (and ignoring that it may have started with slightly different charges and behave differently at different temperatures) says the camera used 1.26 W·h = 76 W·min in 34 minutes, which averages out to 2.2 W.
That’s close enough to the “a bit over 2 W” figured from those partial-to-empty measurements for me.
The discharge tests from early November:
The best STK battery (D) holds just under 4.2 A·h, so its absolute longest run time could be 110-ish minutes. That graph shows the A cell was just about done after 75 minutes, so changing the battery after an hour still makes sense; you never know what will happen during the last few minutes of a ride…
The Smell of Molten Projects in the Morning 