Fighting with computers

Computers are not always friendly.

Thursday, April 19, 2012

Mending my mistakes

While I am not a king (inside joke for Spaniards only) I do make mistakes quite often. One of them was not to disconnect my RAMPS-controlled 3D printer from the computer and mains supply for a quick solder job (just one pin of heating resistor was loose just before starting a print ...). Unfortunately, my trustry JBC solder of the last twenty years was not properly isolated anymore and I had a big flash and all the house lights went down.

When I restored the power the computer was booting up happily, the printer power supply light was on but the printer was dead and the computer was unable to detect the printer anymore. All the lights on the board and on the Arduino Mega were off too and my system shown a warning message that USB port was disconnected for excessive power consumption: no good news at all, but at least I learned the USB port was not completely dead.

I removed the RAMPS board from the Arduino Mega, connected it to the USB cable and then the lights come back on, surprisingly RX and TX leds too. But my computer did not detect any connection or disconnection on the USB. Of course Arduino IDE was incapable of doing anything else. The board seemed dead. But I had lying on my desk an Sparkfun FTDI Basic board, and when I connected the RX and TX and GND pins to my USB powered Arduino Mega I was able to upload the Blink test program and it worked. That proved the ATMega  microcontroller was not dead. So I decided to replace the FTDI chip, something I have never done before. The process was quite straightforward:

Fist I took an old Arduino board from my junk box:
Next I used a heat gun to heat up the FTDI chip area and when I thought it was warm enough I turned the board upside down and gravity did the rest:
I could not do the same with my Mega board as many other SMD components were close to the damaged FTDI chip, so I use some tweezers to pull from the chip while I heated it up with the heat gun (this is likely a better way):
Being careful of not confusing the damaged and the savaged FTDI chip I took the latter and I let it rest on the Mega board while heating it gently till I could see the chip seating in its place while the solder became liquid again (unfortunately I damaged some of the pins of the digital inputs header):
The Arduino Mega board is now back to life and after diagnosing a couple of damaged Pololu drivers in the RAMPS board I hope everything would be back to square one soon.

What is no longer with us and it is gone for good is my good old soldering iron. 

Note to self: Remember to power down everything you plan to solder, even if it is just tiny bit.

Tuesday, April 17, 2012

Of polygon offsetting

Last week I have been researching about a task I initially did not even know the name: Polygon offsetting. A polygon offset (in case you ignored it too) is a computer graphics primitive (though it can be done by hand too) that given a polygon will trace a inner or outer version of it that it is either totally contained inside the polygon or that it will contain it entirely (if you want an outer offset) whose perimeter will be at a constant distance from the perimeter of the initial polygon. And given that I seriously doubt that my explanation is good enough, here you have an image (of an inner offset, gray-line perimeter):

I was looking for an available implementation of this process, as I wanted to be able to use it for an ongoing project. This time Google did not helped much and though I was able to find the question I borrowed the picture above from and that CGAL library did have polygon offset as one of the functions or that there was Clipper library or a Python implementation, none of them really filled the bill.

I was looking for a free implementation given that I am lazy and I did not want to do more work than needed. However, CGAL library license does require a fee for commercial use and it is based in C++ while I wanted to keep the cost low and prototyping using Processing (Java).  Clipper library would have been perfect but Java implementation was not available (C# implementation is available so a Java port may not be a huge endeavor, but 3.500 lines of code is not something I was planning to translate over a weekend).

I ended up doing my crappy implementation based on a very simple idea, that turned out not to be that brilliant:

  1. For each perimeter segment, create a parallel segment of equal length with a given inner offset. 
  2. Compute the crossings of the above segments to obtain the polygon offset.
What did not work was that polygon offset sometimes will give more than one output polygon, so if that is the case my approach is terribly flawed. If not it can be quite simple to implement, unfortunately I will have to refine my code to handle this problem.