I recently wanted to do some computer vision stuff using OpenFace, which is a collection of face-processing computer vision algorithms and tools to use them. It uses OpenCV 3.0.something, which uses, among other things, vtk6, and friends libvtk6-dev and python-vtk6.
Normally, this wouldn’t be a problem, but I use ROS Indigo, as does the lab I work in. ROS Indigo uses some previous version of vtk, and so attempting to install OpenCV 3.0 blows away my ROS install, and makes apt freak out when I try to install it again. The actual error was something like “you have broken held packages”, only I didn’t actually have held packages OR broken packages.
Apt just gives up at this point. Aptitude, on the other hand, proposes removing the offending VTK packages and proceeding with the ROS install. Only time will tell if I’ve trashed my OpenCV install, but if I have, I can just go back to an older OpenCV version.
My PhD work (TinyRobo) uses a USB-Serial converter to talk to the ESP-8266 modules in the tiny robots. Normal FTDI cables have a cable that ends in a 0.1″ 6-pin header with this pinout:
- Black – Ground
- Brown – CTS
- Red – VCC
- Orange – TX
- Yellow – RX
- Green – RTS
It turns out that esptool can manipulate the DTR and RTS lines to reset the chip in bootloader mode, which is great for uploading code to it. It also means I can get away with not having any parts on the TinyRobo boards to handle the reset, which is great because it lets me keep the board small. Unfortunately, the FTDI cable I have doesn’t expose the RTS line, so I got a converter module for cheap off Amazon. The particular module I got is this one:
I added that red wire and cut a trace so that the pins would be:
So far, so good, but I can’t upload with it. I threw a scope on the lines, and it looks like instead of swinging from VCC to ground like well-behaved TTL serial lines, they swing from VCC to VCC minus some tiny voltage, less than a volt. Adding pull-downs on the lines doesn’t seem to have helped. It could be that the timing is of, but I suspect that somewhere, some cheapskate saved some fraction of a cent on this board, at the expense of it doing the one thing it was supposed to do (YOU HAD ONE JOB).
Six months ago, I designed a schematic and circuit board in KiCad. Yesterday, I tried to open it and got a list of errors so long that it didn’t fit on my screen from top to bottom. The reason is that KiCad loads the footprints of the parts you use from Github, so when (not if) the KiCad devs change how they store footprints, your install of KiCad breaks. In other words, installing KiCad gives the KiCad devs permission to break your workflow for no reason.
I fixed my KiCad package list by writing a little python script that goes through the KiCad github repo and generates a new footprint list based on however they happen to be organized and whatever they happen to be called today. Copy that over my previously working footprint list, and the error message went away.
However, since the last time I used it, my install of KiCad has stopped rendering in CVPCB. No error message or anything, just doesn’t render the copper layers, parts, etc. I got part of the ratsnest, and that’s it.
Clearly, the thing to do is to install the newest version of KiCad from the developer’s PPA.
Nope, that returns a 404.
Clearly, the thing to do is to install using the script the devs wrote to install and build KiCad.
Nope, the script fails because they use a version of WXWidgets that like no one else on earth uses.
So let’s recap: No method of installing KiCad works, and just LEAVING YOUR WORKING INSTALL ALONE is not sufficient to ensure that it continues to work.
Since I’m designing a small PCB, CadSoft’s Eagle is looking more and more tempting. Limited PCB sizes aren’t a problem if you’re making something small.