My journey to Python continues. I’ve been playing on a Raspberry Pi project and it’s been working quite well! In the meantime, I’ve still got work to do, and lately (at work) I’ve had to deal with a lot of screenshots that get emailed, and when I started it was just a few, so I’d open the PNG files in Photoshop, resize them, and save them out as compressed JPG files. This started to get painful as I had to do more of them, and as a fun little comparison, while Photoshop CS5 runs quite fast on my 2012 MacBookPro, Photoshop CC 2019 is terrible on my 2017 iMac.
Side-rant: I hate Adobe’s forced subscription model, and Photoshop CS5 does most of what I need to do. Adobe’s Creative Cloud is caught in an forced update cycle where they have to add things, many of which may not be useful (to you) and are probably resource hogs, too. CC 2017 was quite a bit faster than CC 2019. (End of rant!)
Anyway, back to Python. Since I’m often looking for excuses to write Python lately, I checked to see if there was an easy way to resize images and convert from PNG to JPG. There sure is, and it took me just a few minutes to find some working code. This sped up my screenshot situation quite a bit! The one hiccup in finding Python example code online is that it’s often for Python 2.x instead of Python 3.x and needs some minor adjustments.
While typing Python commands in the terminal was working fine, I’ve been around the block before with this sort of thing… In fact, in 2012 Wilfredo Sanchez put out DropScript and I used it for many Perl scripts to make my life easier. Luckily I wasn’t the only fan of DropScript, and there’s a modern version of DropScript! Oh yeah, so the way it works is that you can take a script (written in whatever language) and make it run when you drop files on it. It’s a customizable droplet. I remember I had a big folder full of droplets for web development and file management. It was handy.
So it took another 10 minutes, but I converted my Python script to a DropScript application so now things are even faster… drag and drop, no typing!
I still need to make my Python a little more accepting. For instance, I have to drop files on it, but it would be nice to be able to drop a folder full of files onto it. Baby steps, right? I’ll keep hacking away at Python as I get time. And I will admit, the cleanliness of Python is sort of nice…
In the interest of not waiting too long after I build something to share it here, I’m going to drop a bunch of random info into this post, knowing that it may not be well written or cohesive, but I’ve decided that’s okay…
Logo is an educational programming language known for its use of turtle graphics. Commands for movement produce drawings on a screen that teach students to understand, predict and think about the turtle’s motion by imagining what they would do if they were the turtle.
And finally, if you’re not familiar with Brinn Labs (where this was created) we are were the exhibit development group of a children’s museum, and we make made safe, durable, fun, educational exhibits for museums and other institutions, mostly aimed at early learners.
Here’s the original concept I shared with the team. Things always change during the development process, but this is still pretty close to what we came up with.
In designing the physical board and pieces, I took inspiration from the block interface used by Scratch. In Scratch pieces fit together to help you figure out where things go, and color also help denote function.
Here’s a mock-up of the board where the pieces will go. The board has pockets that the pieces fit into, and in each pocket is a sensor that reads the back of the piece. Note that the pieces only fit into the pocket that matches the function. You can’t put a direction piece into the color pocket. The pieces also cannot fit in backwards or be rotated in the wrong direction. Designing this to work took some time, and it’s all there to help you get it right.
The right side shows the indent for the loop code, as well as the use of parens that many programming languages use. Note that the loop pieces are not required, but if you put in the beginning loop statement and not the end loop statement (or vice versa) you’ll get an error.
We’re using the QTR-8RC Reflectance Sensor Array boards from Pololu. Each pocket has one sensor board to read the barcode on the back of the pieces. The barcode allows us to use a binary code for each piece. This means no technology is embedded into the pieces, and they’re (fairly) cheap and easy to replace as needed.
Here’s a look at the print file for some of the pieces, showing the back. You can also (faintly) see the cut lines for the pieces.
Here’s a portion of the binary code for some of the pieces. We actually doubled it up as a sort of checksum to make sure things were read right.
Each sensor is mounted from the back of the panel with a 3D printed mount that sets it right below the surface. We found a gray filament that was a pretty close match to the gray HDPE we used for the front panel. The top part of the sensor mount matches the holes milled into the HDPE by the CNC router, and includes the radius of a 1/4″ router bit.
My favorite part about 3D printing the sensor mounts is that you can set the height of the part where the screws go to match the screws you use and the material you are screwing into so they go in the exact distance you want, and not too far. No screws poking through material, and no screws not inserted enough to get a good hold.
We couldn’t leave the sensors exposed, so we laser cut clear acrylic pieces to place into the pockets. Hopefully they’ll stand up to the abuse they’ll get, but if they get too scratched or worn, it’s easy to swap in a new one. (If you’re keep track, we’ve used a 3D printer, laser cutter, and CNC machine so far…)
Here’s a look at a mock-up of the pieces. This is an early iteration but shows some of the color choices as well as all the pieces together.
I’m not showing you the inside of the cabinet, but all of the sensors connect to a microcontroller that is connected to a computer. The microcontroller reads the sensors, determines which pieces are in which pockets, and reads the button presses to run the code on the computer and reset things.
To program the turtle, you put the pieces in the tray, and press “Run”. If you get an error it will show on screen and also blink an LED on the board for the “line” where the error is. Once you correct your error(s) you can hit “Run” again and watch your code execute. You can run over and over until you want to clear the screen by pressing the “Reset” button, which clears things and sends the turtle back home.
We didn’t implement pen up/pen down, because this is a simplified version meant for young children/early learners. I think that as far as a STEM component it turned out well, and creating it allowed me to combine my love of computers, programming, turtles, Logo, and design into something awesome.
I hope Seymour Papert would be proud of this. If you’re not familiar with his work, he’s been considered the world’s foremost expert on how technology can provide new ways to learn and teach mathematics, thinking in general, and other subjects.
People laughed at Seymour Papert in the 1960s, more than half a century ago, when he vividly talked about children using computers as instruments for learning and for enhancing creativity, innovation, and “concretizing” computational thinking.
Here’s some kids having a good time learning about coding!
We recently got a uArm Swift Pro robot arm at Brinn Labs and I’ve been putting it through its paces. It comes with software called uArm Studio that lets you do a lot of things, but for this post I’ll focus on drawing (or “plotting”) using a pen.
One of the tools I’ve used in the past with the Egg-Bot was StippleGen2 from our friends at Evil Mad Scientist Laboratories. StippleGen2 is a program written in Processing that takes an image and converts it into a series of lines, or more specifically, a single line, which is suitable for plotting.
Above is the image I started with, an “8-bit heart” as I call it. It’s a simple black and white image of a low-res heart. (Great for Valentine’s Day, right?)
After running the heart through StippleGen2 and choosing the appropriate complexity of the line drawing I wanted, I saved out the file as an SVG format vector file. Perfect for plotting. (In fact, since it’s a single line, the z axis never has to move up once it starts.)
I fired up uArm Studio and chose the Draw/Laser feature, and then loaded in the SVG file. I did have to scale it up a bit, as I still don’t have the exact dimensions I should use for artwork in uArm Studio.
Once the file is loaded, you hit start and there’s a step where you set the z axis so it know where the pen hits the paper. At this step, I wish there was a little more control over how the z axis moves. I think the smallest increment is one millimeter, and I think it should be smaller. (Most CNC software has some adjustment to how much you move things, so I can see adding in 0.5mm and perhaps 0.2mm as well.)
While the uArm Swift Pro is awesome, I’m still going to be a little critical… One of the issues I’ve come across in the Draw/Laser part of the software is that the speed seems to be hard-coded, with no way to adjust it to go faster (or slower.) As someone who understands G-code and how CNC machines work, I found this a little annoying…
So I set about to find a solution. I first posted a message on the forum, but then Chinese New Year hit and it seemed as though it would be two weeks (or more) before I got an answer. I had dug around and found that the G-code created by the Draw/Laser part of the software generates a file and drops it at ~/uarm/Temp/files/gcode/tmp_pen.gcode and I assumed that by editing the feedrate in that file, I could speed things up… I was right!
My first attempt was to connect with the arm using Universal Gcode Sender, which in this case was not universal, and failed to properly talk to the arm. I dug around a bit more and found simple_stream.py which is a Python script to stream G-code to a device. Sadly, it was not compatible with Python3, but luckily, I’ve been writing a lot of Python lately, so I fixed it.
After I got it working (that is, after much hacking at the original code) I found that I could easily speed up the drawing to half the time. In this case, 5 minutes with the Python script versus 10 minutes with uArm Studio. For TSP art, great precision tends not to matter too much, and I think I could speed it up even more.
I’ll work on cleaning up my Python code and seeing if I can get it online in case others want to muck around with it.
I started playing around with the #plottertwitter thing and wanted to do some creative coding with Processing, and at least one person asked about the code, so I’ve included it below.
Instead of drawing a rectangle, I’m creating a shape, and then varying the position of it a bit more with each row that is drawn. I reused some code I’ve used plenty of times before that keeps track of where things are drawn so the code knows when to start a new row, and when the screen is filled. After it draws a screen full it will save a PDF and exit.
Once you have a PDF (which is a vector file) you can make your plotter (or laser cutter, or CNC machine) do what you want with it. I typically bring the PDF into Inkscape and make any adjustments needed before I save it out in a format suitable for the machine I’ll be sending it to.
Let me tell you about my history with snowblowers… Around 2000 I got a used snowblower from a rummage sale. It was corded, but I had extension cords, so I wasn’t too worried. The seller let me plug it in and test it. It worked! and it was like $15 so I got it.
The first time I tried to use it I went out to the garage, tried to fire it up, and it wouldn’t run. Dead. I took it in the house to work on it in the basement, and no luck. I let it sit in the basement, went outside and shoveled for hours, and tried it later in the day (still in the basement) and it worked fine! After much investigation I discovered it didn’t work well in cold weather. Yeah, a snowblower that didn’t like the cold. I kept it in the basement and used it occasionally but to be honest it was small and under-powered, and I got sick of extension cords.
Fast forward to 2013, new house, new places to blow snow away from, including the section between the garage and the alley, and part of the alley. My family has a way of saving old things, even when they get a new one, so someone got a new snowblower and gave me the old one, which was a monster of a blower that my grandfather used to own. This one too, sucked instead of blowed. It was gas powered, but had an electric start, and despite being a large metal beast, seemed to die a lot in heavy snowfall. It also didn’t like to start. And worst of all, I had to pull my car out of the garage just to get it out of the garage. I gave it away last year…
So instead of using a 20 or 30 year old snowblower that uses gas, and oil, and filters, and all the things I hate, I got an electric snowblower that uses a 40 volt Lithium battery. Battery technology has improved tremendously over the past decades and if I can avoid gas engines and extension cords, I’m all for it.
We now have a Greenworks G-MAX 40V 20-Inch Cordless Brushless Snow Thrower. I got to use it today and it worked. Cutting the first path took a bit of time, but with a 20 to 40 percent step-over, it did a good job with 15 centimeters of snow. The 4 amp-hour battery was enough to do the sidewalk and most of my two neighbor’s sidewalks, but it ran out of juice before I could do the alley, so I went in the house, charged it to about half-charge while I had breakfast, then did the alley.
I should note that I specifically wanted a “small” blower, and the 20″ model allows me to maneuver it around the cars in the garage with ease. This means I don’t have to move a car into the snow covered alley to clean the alley. It’s a win in my book. It’s also mostly plastic so it’s easy to lift if I do have to carry it, which came in handy getting down the steps to the sidewalk.
This is not a blower that will have you powering through deep snow at a fast walking pace, you’re going slow, or you’re knocking your step-over rate down quite a bit after the first path, but for the size of it, that’s understandable. I don’t have a 50 foot driveway or the space for a large monster blower, so I’m happy with what we’ve got now… it’s better than shoveling, because to be honest, I’m gettin’ too old for that shit.
I’ll probably get another 4 amp-hour battery, just so I don’t have to recharge mid-job, and with two spare 40 volt batteries in the summer, I may see if I can run my 36 volt Neuton lawn mower with them as well.
Update: I did get a second battery… and eventually a Greenworks Lawn Mower, and I am happy with both of them.
