recycle, re-use, re-purpose – part ii

Continuing with the work to re-purpose a computer mouse as a filament movement detection device, I designed and printed some parts for this. The bottom part is perhaps 5mm in height from the spool itself and is reasonably a good distance to see changes.

I’ve edited the earlier Python script which originally detected the scroll wheel button; it’s now detecting movements of Y as if the mouse were being moved on a mousepad. It will only do this if I take the white assembly and move it around on a patterned surface, however.

To help the mouse detect movement better, I’ve tried using both grid paper and a polar version of same. I don’t love the feedback loop that’s going now. I’m sure there’s a better way to get this movement detected all the time, though.

IMG_0115

IMG_0116

IMG_0118

recycle, re-use, re-purpose

This week’s project involves dealing with filament-delivery problems on my 3D printer. Out of the box, the filament runout detection never worked. Frankly, it was a terrible design to begin with from the manufacturer and I’m convinced that someone at the factory just turned off that behavior anyway.

As a result of this, I’ve lost a few print jobs over the last year. In only two cases, I simply ran out of filament for large parts. In all the remaining cases, a number of problems contributed to the loss of filament delivery to the printed part:

  1. simple end-of-roll loss of filament
  2. spool sticking to manufacturer’s poorly-designed spool holder
  3. cross-threading of the filament on the roll
  4. hot-spooling the filament at the factory which resulted in filament which sticks together
  5. filament like carbon fiber—infused which likes to stick to itself
  6. old filament which is now brittle and breaks as a result
  7. overall poor design of the spool (boxy) shape itself, resulting in cross-threading
  8. overall poor design of the filament delivery path itself, resulting in too much force needed to extrude
  9. filament thickness quality issues as combined with PTFE feed tubing, resulting in stuck filament in the tube
  10. too-flexible filament as combined with any of the conditions above, resulting in filament notching at the bowden gear
  11. z-offset too close to the bed, resulting in hotend jamming
  12. poor first-layer adhesion, leading to a build-up of filament and ultimate hotend jamming

Now granted, the bowden drive for this printer is one of the beefiest NEMA 17 style of stepper motors I’ve seen. And yet the number of filament delivery—related problems is just too high to continue to ignore. So I’ve decided to finally deal with the issue rather than working around it.

Ideas & inventions

Remove the stock holder, add bearings to its replacement

I designed, printed and assembled a very good dual-spool filament delivery system which worked much better than the stock filament holder. I sometimes still use it.

DSC_0062

Dual runout switches

Perhaps six months ago, I designed, printed, sourced parts for and assembled a very good dual-spool filament runout detection block to replace the stock part. I have yet to install it since I’m not in love with the idea of the filament path beginning at the table level. Time has taught me that the spools need to be higher than the printer for this to be optimal. As designed, though, it works in principle to detect loss of filament from both spools.

DSC_0211

And yet, this entire concept does not directly address the problems associated with cross-linked filament. It only addresses the loss of filament as seen in a switch.

Parabolic spool guides and re-purposed monitor stand

Additionally, I designed, printed and assembled parabolic spool guides to better deliver filament (especially for hot-spooled or otherwise sticky filaments like carbon fiber). This I combined with a designed/re-purposed dual-monitor stand to move the spools above the printer rather than below.

SpoolHolderOverhead

SpoolHolderWithBracket

Remove the temperature gradient

First-layer adhesion was aided by adding a foam enclosure/door and a temperature-monitoring Raspberry Pi 3B to the inside (opposite the internal webcam). The latter helps to heat up the print volume area, keeping things from 90-100 degrees Fahrenheit.

foam

Remove the PTFE tubing

Filament diameter inconsistencies resulted in filament getting stuck in the PTFE tubing. I now rarely route the filament through the tubing, having removed the awkward bottom-to-top filament delivery path from earlier.

And finally, a filament movement detection mechanism

This weeks work then revolves around fixing the underlying problem. The solution isn’t filament runout detection. The more accurate problem and better solution is actually loss of filament movement and its detection.

When I began to think of solutions, in my head I was adding black/white encoder rings to the sides of the spools themselves. I would need to add those to all spools of course. I’d also need to design something which reads those as ones and zeroes.

I decided that a roller/follower which is turned by the spool is also a solution. I then envisioned writing drivers and creating a small circuit board for all this so that it could talk to Raspbian, the operating system which OctoPrint runs on.

Mouse to the rescue

Finally, it hit me that a standard computer mouse does this naturally. The older style of ball mouse has a follower which detects when the ball is moving. Even the newer style of mice still have a scroll wheel which is covered in rubber and would do nicely. In my imagination, the first iteration of this had the filament trapped against that rubber wheel. In today’s version, the wheel merely comes in contact with the side of the spool itself for the win.

As a bonus, the computer mouse already has the serial communication and Linux driver built-in. It was trivial to write a small Python script to detect scrolling events.

no mice will be harmed … in the making of this gadget.

The mouse should fit nicely and without any modifications to a 3D-printed holder. The serial connection goes to the Raspberry Pi and is then detected in an OctoPrint plugin. During a print job the scrolling events will be monitored; any loss of scrolling over the sampling period will then pause the job and alert the operator with a sound event.

rat on computer mouse

rip, red hat

Say it isn’t so.

Since the end of October is all about scary stories… Just on the heals of Microsoft buying github for US$7.5B last year, IBM has now has purchased Red Hat Linux for a cool US$34B dollars.

Screen Shot 2018-10-30 at 12.34.56 PM

Granted, I haven’t used Red Hat in a few years mostly since it is one of the few paid UNIX-based operating systems out there. Ubuntu, backed by Canonical, is clearly the better choice for anyone who knows what’s going on.

IBM is the antithesis of open-source software, as is Microsoft. This is just sad. But good riddance. Now get in the hole, Red Hat.

this-is-capitalism

meetup tonight

I’ll be giving another lightning talk this evening downtown at the San Diego JS meetup. I get to talk about the Autonomous Tank project and the code behind that.

SDJS

Since I no longer have a corporate-sponsored license of Microsoft PowerPoint, I had to improvise for my overhead slideshow this time. So I did what most coders would do in this scenario: I coded something for the task.

Screen Shot 2018-10-02 at 2.45.50 PM

autonomous tank

I managed to snag some great track data today at the venue. It was necessary to write a service to take snapshots every second while I manually drove around the track a few times.

With data in hand now at home, I was able to do some data processing now with the images from my own webcam.

A New Perspective

I thought I’d compensate for the lines-of-perspective effect so that the trending portion of the software could have accurate data. Since Jimp didn’t have a skew function and since its convolute() method didn’t work as expected with the right matrix for this, I ended up writing my own prototype which now works as shown below.

Screen Shot 2018-09-22 at 9.34.22 PM

file management for 3d printers

I use the software OctoPrint to control my 3D printer. It’s an excellent web service with a rich collection of methods in its REST API. The software was designed, coded and is maintained by Gina Häußge.

I’ve just created my first plugin for OctoPrint. It should allow those who need version control to pull their sliced files from a github repository as selected. The interface and concepts are simple enough: identify the repository and press the button to pull the latest from that repository.

settings

 

buttonfiles

Update:

My new plugin is now listed and published on plugins.octoprint.org. Yay, me.

plugins.octoprint.org

tanks a lot

I decided to build a very cool-looking robotic tank kit which is made by OSEPP. They have a variety of grown-up toys like this in the geekspace.

I guess I’ve been inspired lately by some of the local meetups which involve races with autonomously-driven cars.

To build this, I find that a surprising amount of hardware is going into this project as well as several programming languages all at once. I’ve had to bounce back and forth between Python and C as I interface the Raspberry Pi Zero W computer with the Arduino Mega 2560 R3 Plus board. This Arduino doesn’t come with Bluetooth, wi-fi or even an Ethernet jack so I opted to add in the Pi since it’s inexpensive and comes with a full operative system. The Pi of course includes a webcam for initially allowing the remote control features to be easy. Later, that same camera will be used to generate images to be processed for autonomous driving.

DSC_0072

Repository

Update:

I decided to design some plastic parts for the tank. It’s now looking awesome, has some quick-release pins and I’ve purchased a 12-battery AA charger and batteries for the project since it seems to be hungry for power.

DSC_0073

DSC_0074

Screen Shot 2018-09-12 at 2.00.44 PM

The first three attempts at managing the tracks for steering didn’t seem accurate enough for my own driving-related expectations at least. I finally had to resort to trigonometry in the last set of calculations; this appears to be a more natural steerage interface.

It looks like the first two phases of the project are now complete and I’m well into the third (autonomous) phase now.

Autonomous (Self-Driving) Mode

Next up is the part where a service is taking snapshots from the camera and then using this to make steering decisions. The strategy here is to use data image processing to find the road, so to speak, our position relative to the path ahead as well as any competitors also on the track.

The first interesting piece of the data processing involves some linear algebra and a variety of matrices which perform distinct functions, if you will. You basically multiply a particular matrix for a 3×3 array of pixels to replace the center pixel’s color in each case. The first and most useful matrix is named findEdgesKernel and looks like this:

-1 -1 -1
-1  8 -1
-1 -1 -1

This will allow a new, simpler image which should highlight only the track (masking tape) for the path ahead. This part is working quite well so the next step is to process this resulting path image to determine how the tank should steer both now and in the near future.

Screen Shot 2018-09-12 at 2.03.10 PM

microsoft wants open source extinguished

On June 9th when Microsoft had just purchased github.com, I wrote about how I thought this was something tragic for the world of open source. This morning I awoke to several new security notifications from my repositories there (requiring about an hour of my time to adjust my code):

“We found a potential security vulnerability in a repository for which you have been granted security alert access. Known low severity security vulnerability detected in debug < 2.6.9 defined in package.json.”

On the surface, one might think that Microsoft is trying to make the world a better place. You might think this if you’re an optimist or a friend of them, perhaps. Maybe Microsoft cares about security so much that—having just purchased github—they now want to ratchet up the quality of the collection of software as stored there by most people who don’t like them…?

But if you’re a pessimist or if you’re someone who doesn’t like Microsoft, could there be another reason behind this new diligence they’re trying to bring to code security? It’s not like Microsoft has a great track record in writing bug-free or network-safe code themselves.

“It’s not like Microsoft has a great track record in writing bug-free or network-safe code themselves.”

Strategic sabotage

Richard Nixon was known to do something termed ratfucking in the political world. Wiki even has a page on the subject. It means “political sabotage or dirty tricks”. It would eventually result in his impeachment. In some college circles, a mean-spirited prank is part of the playing field. To me, it feels like many of the players inside Microsoft are the same type of people, those who have no qualms destroying the competition, tripping them up and generally exercising a “whatever it takes” attitude toward their so-called success.

Microsoft’s internal methods:

Steal their air

In a lawsuit, the U.S. Department of Justice turned up an internal tactic used inside Microsoft which describes what they do when they feel that a competitor needs to be removed: “embrace, extend and extinguish”. In other words, 1) embrace open source by buying the main storehouse for its code, 2) create products such as Visual Studio Code which replaces similar free editors and 3) gradually remove the competition by getting rid of it now that you’re in a controlling position.

Appeal to fear

Another tactic they use in the market space is to promote fear with respect to anything the competition could provide. We’re seeing this now in the pseudo-warnings being auto-generated by github.

What this is

What we’re seeing is a direct and strategic beginning to Microsoft’s move to embrace, extend and extinguish github and yet it’s open source itself who is their ultimate target.

The future of gihub and open source

Expect more of the same: dirty politics related to the leading repository site of what Microsoft views as their competition.

and one button to rule them all

The project from yesterday and today is something called a “dash button”, an IFTTT or an IoT button. Push the button and some activity gets invoked (usually, remotely). Amazon’s take on this is for you to be a consumer, press the button and something gets ordered.

dash

My own take on this is to add a big red button (BRB) as a remote panic switch for the 3D printer. Press it, magic happens and the print job is paused. It’s useful when something bad starts to happen and you need to make it stop quickly.

IMG_0034

There’s not a lot of room inside the printed plastic for this. Whatever electronics it uses, it will need to be small enough to be self-contained.

IMG_0049

I’m currently accomplishing this with a nifty Adafruit Huzzah ESP8266 board, a charging module and a 3.7V battery. I’m using the Arduino software to “flash” (upload) code to the tiny processor as well as a full directory of files to support the webserver which runs when it’s in configuration mode.

By strapping a pair of header pin connections and pushing the reset button, it now boots up in wi-fi hotspot mode and serves up a configuration website. Submitting to the form then re-configures the device and resets it again.

Booting up now in the standard mode, it then connects to the local wi-fi and attempts to then connect to the URL that you’ve given it. Once it does all this (perhaps ten seconds’  worth of activity), it promptly goes to sleep. Press the BRB again, it wakes up and goes through its routine again.

If you think about it, it’s now a reconfigurable dash button and much more useful than those one-trick-ponies as provided by Amazon.

Repository

glacier

Earlier today, I created a Raspberry Pi Trezor (cold wallet) for cryptocurrency using that cool Adafruit 1.3″ OLED bonnet.

PiTrezor

It seems to reasonably work from a fork of the original code. It presents itself to the Trezor Bridge software and to your workstation as a slave USB device. I suppose you could think of the entire thing as a smart USB thumb drive, if you will.

The code image is smaller than you’d normally expect (50MB). I’ll get in there and take it apart later from a software standpoint.

Notes:

  • The interface is beautiful on the small screen with attractive fonts and functional animations.
  • I don’t love websites which only work with a single browser. In this case, it’s Google Chrome of course and it was necessary to install that for Trezor to work at all.
  • The standard screen assumes that the buttons are positioned below it, not so for the Adafruit hat. So you just have to guess that the furthest button equals the right-most button and it all works out.
  • The GPIO pin layout of the OLED bonnet is different from the native Trezor device so of course, the bootloader upgrade routine doesn’t work as expected. It will be necessary to recompile and reload the image in order for this to work. I’ll have to review all that to see how it affects me to I don’t love anything in the cryptospace which can’t keep up to the current state of the art.
  • Having the micro USB cable sticking out of the side of the Pi just seems awkward so I’ll work up a serial connection to the GPIO pins with a USB plug tail and incorporate all this into a slick-looking case.
  • I don’t think I enjoy the website interface for selecting other cryptocurrencies. I think I like the KeepKey version of this better, to be honest.
  • Although Trezor suggests they’re compatible with other currencies, they seem to only be able to do Ethereum via a third-party. The hand-off to that third-party provider was about as ugly as it gets and I aborted. You shouldn’t have to create multiple accounts to simple store a wallet.
  • Unless I gain more confidence with all this, I won’t be putting any money in the wallet but it’s an interesting exercise.