Month: November 2013

Direct-to-PCB laser printing

“Also, contrary to popular belief, there’s no issue with laser printing on a conductive surface.” – from here.

I’ve seen this in operation at Worcester Polytechnic Institute. There, the flexible/soft robotics lab uses copper tape on plastic substrate to make PCBs, sticks them to a sheet of paper, and runs it through a totally-normal, unhacked laser printer. Copper tape is probably thinner than PCB copper, so it ends up not sinking too much heat away from the fuser. The resulting PCBs can be etched right out of the printer, with no ironing step in the middle.

I have to hit a hardware store at some point this week, perhaps I’ll be able to get copper tape there.

That's Not Helping, Python.

[ERROR] [WallTime: 1384556730.822164] bad callback: >
Traceback (most recent call last):
File "/opt/ros/groovy/lib/python2.7/dist-packages/rospy/", line 681, in _invoke_callback
File "./", line 81, in callback
File "./", line 68, in getBoard
newImg = cv2.warpPerspective(cvImg, perMat)
TypeError: Required argument 'dsize' (pos 3) not found

[ERROR] [WallTime: 1384556763.964408] bad callback: >
Traceback (most recent call last):
File "/opt/ros/groovy/lib/python2.7/dist-packages/rospy/", line 681, in _invoke_callback
File "./", line 81, in callback
File "./", line 68, in getBoard
newImg = cv2.warpPerspective(cvImg, perMat, newImg.shape)
TypeError: function takes exactly 2 arguments (3 given)

Well which is it? Exactly two arguments, or the third positional argument is required?

The real problem is that the shape of newImg is a 3-tuple, and warpPerspective expects a 2-tuple. This StackExchange post hipped me to the bug.

A New Contender!

As I mentioned back in this entry, I don’t think the further development of the ToyBrain controller is useful. The main use case is amply solved by the Pololu Baby Orangutan. However, there is a project that I want something similar for, where the Baby Orangutan won’t work.

The idea behind the project is to make cheap swarm robots out of small robot toys, using something like the ToyBrain or Baby Oranguntan, but with wireless. The Moteino has wireless, but no motor drivers. The Baby Orangutan has motor drivers, but no wireless. The solution, then, appears to be to make a motor driver shield for the Moteino or a wireless shield for the Baby Orangutan. Of the two, I’m more inclined to do the motor shield for the Moteino, but I haven’t done any really analysis.

A Framework for Flow-based Coding

Normally, I think visual presentations of programming languages, such as Labview, are more a problem than a solution, but there is one case where I don’t think that’s the case: when the program is operating on a stream of data, and the program should be able to be changed without stopping the stream. The canonical use case for this, in my opinion, is realtime operation on a video stream. In this case, you can watch the video output change in realtime as operations are added, removed, and modified.

What I was hoping to do, at some point, is to write a set of operations for video that are wrappers for e.g. GStreamer, and by putting them in a visual programming framework. That would give me a set of VJing operations that can be played with in realtime to do things like chromakeying a live video stream on human skin colors or dropping swirling masks on all the faces detected in the video stream.

Pyqtgraph has a lot of promise as a framework for this. My main desire for the framework is that I don’t have to deal with things like handling mouse clicks, and can just get a description of the pipeline and shove data through it. It may be someone already did this, but is dead, so maybe it doesn’t matter if they did.

Microcontroller fun

The Arduino has a huge hobbyist-level codebase and lots of libraries for talking to various devices.

The 8051 is a venerable old processor that still gets used in lots of stuff because it’s cheap, and has a low gate count.

It’s probably possible to port a lot of the Arduino stuff (everything that doesn’t use specific on-chip features) to the 8051, thus allowing people to use the software environment they are comfortable with on a new chip. The same is likely true of PICs, and other chips.

The general case, then, is to create a translation system that automates, as much as possible, the process of porting the Arduino libraries and environment from one chip to another. This is, at a high level, possible because anything a computer with a turing-complete instruction set can do, any other computer with a turing-complete instruction set can also do. The hang-up would be on limitations of real hardware (there’s a lot of cool stuff in there, but no infinite data/instruction tape).

Another silly game idea

Effectively, Sim City meets tower defense, where you build a city and defend it. These sort of exist in some forms, where you build a complex of buildings and have to defend it. However, I’ve never seen one of those that actually deals with buildings and roads as actual things. Vehicular units are stuck with using roads, and can get choked at bridges. Foot units can enter buildings and move through blocks.

The really fun part would be mapping the engine for this onto map data from a real city, so all the roads are real, and you get to run around blowing up someplace real. This part of the engine isn’t even hard, provided you can get the topology of the city and render the map on top of that.

Admittedly, the way this came up was that I was thinking about a browser game where you defend the city of Toronto against the suburbs, and so the attacking units are bankers and soccer moms in SUVs, enemy waves are called “Rush Hour”, a biker can one-shot-kill a cab (and vice versa), you can build the “Gay district” structure (gives you a once-per-year freeze-all-traffic event), or the “Hacklab” and “Site3” structures (which pump out infrastructure hackers and flamethrower troopers), etc.