So, A. and I completed the Wigl dancing robot, but the results were not that exciting. It appears to move, and the LEDs are lighting in a somewhat appropriate manner. I should report that A. successfully soldered the motors to the motor wires, and only once found out that you shouldn’t hold the iron like a pencil, near the hot end. (Don’t worry: no one was seriously harmed.) But, after some experimentation with various instruments, it appears it is about a half-step off from the expected.
The idea is that certain notes with cause the robot to turn, move forward, etc. And certain combination of notes will cause mode changes. However, after some head-scratching it looked like it was sampling such that a B♭ would turn left, instead of a natural B. Not only that, but the movements seemed, well, really jerky and weird. Almost like the sample rate was a little too fast. It wouldn’t respond at all, and then it would take off in some random manner. Something was not right.
This was, of course, a little disappointing.
Anyway, since we have some of the tools to figure this out, the first step was to confirm through the Crowd Supply page that the code published in the GitHub project repository is actually on the ATmega328P shipped with the kit. I also made sure the pin header pads on the board were typical sizes so I could order a 90-degree 6-pin header so I can start poking at the chip via a serial port.
One of the Crowd Supply projects I backed finally delivered, which means I am the proud owner of a Wigl dancing robot. We’ve been looking forward to giving this to A., and each birthday or gifty holiday that passes we were wondering if it would arrive on time.
Well, it finally arrived a little after Christmas (or, it arrived right on time for Orthodox Christmas, if we are keeping score) so we went ahead and surprised her with it.
There was a little bit of organizing to do in the computer shack necessary to get things to a state where we could make solder smoke, not to mention a fair amount of moving “treasures” onto her new workbench. But once we got that out of the way, things related to the electronics assembly progressed relatively smoothly.
I guess we ought to start with the unboxing, of a sort:
Here’s all the parts, inexpertly knolled:
And here’s the completed board:
Here’s a close-up. My soldering skills are a bit weak, and I really need thinner solder. So I’m not going to show the reverse side.
I made a few mistakes but managed to resolve them without damaging anything. And when we hook up a 9V battery to the board and turn it on the RGB LED displays a variety of colours depending on the presence and pitch of sounds captured on the microphone. So that’s a win.
A. helped a little, but I wasn’t sure we were ready to dive right into soldering yet; at least with the gear I have. I tried to enage her with selecting parts and holding some tricky bits while I made the smoke.
The project has not published the full assembly directions yet, so we stopped here. It looks pretty straightforward, but I think I want to wait until I see the hints around putting the wheels on and figuring out motor direction and whatnot. It’s also unclear how to reprogram the AVR chip without a proper header, but I haven’t really looked closely at that yet. It does appear to have some working program already on it, so that’ll do for now.
So, a qualified win. I was a little too timid about enagaging A. with the actual assembly and soldering. I’ll do better when we assemble the hardware. The fiddly puzzle-like pieces and actual nuts and bolts are something she is probably looking forward to messing around with.
As discussed earlier, I have indeed purchased a Windows 10 based ultrabook and I’m not immediately installing Linux on it. I cannot tell a lie: I have kept Windows 10 on it, along with the Windows Subsystem for Linux (WSL) to scratch that Ubuntu itch.
And it’s just fine.
Even though WSL is in beta (and I’m compounding that by installing bleeding edge “Windows Insider” builds) it’s actually pretty solid. I might be losing all my hipster geek street-cred by saying it, but Windows 10 is just as good for me as OS X. Since I’m no avid fan of any X.org environment, this means I think it’s better than any Linux UI. So that’s a win.
WSL seems to be a pretty complete command-line Ubuntu install, with all the trappings of a Debian-flavoured console. I haven’t really pushed it hard, of course, but as a sort of acid-test I moved my Ruby-Jekyll-GitHub blog stuff over to the new lappy and made the right
apt-get incantations until I was able to successfully run
bundle exec jekyll serve. I also updated Ubuntu to Xenial last night with little trouble.
I didn’t think I’d care that much about the mechanisms by which Microsoft has done all of this, but I’ve been skimming the technical notes with some interest. They’ve really done a decent job of implementing the user and kernel spaces.
Well, I finally bought a new laptop. The T460s seems to be the hacker weapon of choice these days, so after a little research I decided to go for it. So, I’m going to eventually be the owner of an “ultrabook”, and the first laptop that I’ve ever purchased with my own money that isn’t an Apple product.
According to UPS it’s on its way from China, so I don’t have it in my grubby paws yet. I suspect I’ll miss the giant screen on the old Macbook Pro I’m currently using. I won’t miss the tiny battery life or the way it acts like a little space heater.
I probably won’t miss OS X, at least too much.
It seems to me that we might be in the middle of a little art/tech Renaissance right now. Perhaps it is selection bias at work, but I keep running across references to folks putting together cool tech-based art projects that explore art in really interesting ways.
I may be slightly sensitive to this as a Canadian of a Certain Age, of course. A friend once told me about a class he took at university that suggested that Canadian visual arts heavily reinterpreted visual popular media, and even reincorporated image data in other works in a specifically Canadian manner. I’m hand-waving here because this was from a long time ago, and was probably the sort of discussion we would have over many beers. But I recall it really brought into sharp relief some of the things I’d been thinking about, say, Cronenburg films and Canadian body-horror cinema.
Embedded Android development continues apace, and I’m currently head’s down on an App Widget that needs an XML parser and some sort of datastore, which is a pretty good learning experience. We also ended up swtiching to a full-on Android Studio, Gradle, and jCenter environment, which has side-stepped a fair amount of Eclipse cruft. It has also introduced some infrastructure churn which I’m hoping settles down shortly. So, I am most definitely an Android developer now.
This has given me the excuse I need to think about using Groovy at work, though, which is a bit if a win. We need a fair number of custom Gradle tasks, and I think the best way to do this is direct functional Groovy. If this morphs into a full-on Spock unit-test environment I will call the whole thing a gigantic, play-off, Premier League level win.
The challenge is that I sort of promised a working demo of the app this coming week. So, I have my work cut out for me, I think. I was sure of this schedule on Friday, but then all weekend I’ve been remembering little things that need to be sorted before we really ship, so now I’m hoping I haven’t over-promised.
So, the Groovy Spock will have to wait until I bang out a few hundred lines of Android Java, including a semaphore controlled background executor.
Good thing I’m a senior developer. It says so right on my job description!
For a few months I’ve been doing a little research to decide if I’m going to replace the aging Macbook Pro that is my main development tool at home with a more modern lappy. The idea is to get something that runs a bit cooler, lighter, and longer on battery that I can use for general purpose hackery. As I’ve mentioned before, I think I’ve gotten about as much life out of this Macbook as I can reasonably expect, so I should probably replace it.
I have no particular interest in staying with a Mac, though it is a decent development box. But I can get all that with Linux these days. Sure, I’ll have to resort to tinkering to get stuff to work, but this already happens with the Macbook regularly, so this is really shifting the problem around to a different flavour of tinkering. So, after learning what some of the new acronyms for computer equipment mean these days, I narrowed things down to a Lenovo Carbon X1, running some sort of Linux.
So, I’m home sick from work today and, as one does, I’m idly playing around with some emulation stuff. Earlier I was researching my KIM-1 emulation project (which is turning out to be a bit harder than I thought).
Then, for some reason, I decided to get IBM PC-DOS 7.x/2000 working on VirtualBox. This is not for any particular reason, though I’ve occasionally needed a real DOS environment to mess about with abandonware. So, this image may be put to good use one day.
But for now, an almost-complete PC-DOS system. I haven’t figured out the networking stuff yet, but it has CD-ROM support, loads DOSidle so it doesn’t burn up my Mac, the usual assortment of high/upper/confusing/WTF memory settings that DOS requires, and so on. I don’t think networking will be that hard, but my Google-Fu is not finding the PCNet ethernet drivers that VirtualBox is emulating. So, for now I’m using sneaker-net.
Yeah. So, that’s a Rexx script being called via the command interpreter via a pseudo hash-bang mechanism (think of
/* ... */ as the shebang line). There’s a reason I liked to run PC-DOS instead of that other one.
What’s going to bend your noodle is that I actually paid for a copy of PC-DOS, lo, those many years ago. So, I’m technically not pirating anything, matey.
Well, that was easy. Started the PCNet packet driver and ran
DHCP from the mTCP project. I was even able to annoy some people on IRC.
Well, the Retrocomputing StackExchange site I talked about earlier is now in open beta. So far, lots of chatter about old Apple and Commodore equipment, but nothing (yet) about truly old-school things like Altairs or KIM-1s.
I hope to remedy this in the near future.
Anyway, like many beta SE sites we are sorting out the scope of the subject we are going on about, which should be hours of popcorn fun.
It’s interesting to see how people define “retro”. There has been discussion about whether emulators, gaming consoles, or even coding (at all!) is on-topic. I’ve been surprised by some assumptions, because I cannot imagine retro-computing without emulators, coding emulators, and coding on actual retro systems.
Ironically, because of this sort of thing, it may turn out that my questions around emulating a KIM-1 with full RRIOT support may be deemed off-topic there. Which highlights both the great strengths and the great weaknesses of SE sites, in general.
There is a good chance that the Cubetto Kickstarter I backed will also mature sometime around the kid’s 6th birthday this year.
As ecogrrl says, who cares if this is the right thing to do vis–à–vis female STEM and engineering and all that. The girl loves robots with exposed parts that she can command. I mean, the other day she called me up after bedtime to tell me she wants to design a digging robot for the backyard. She already had an idea of the actions such a robot would require, and how to go about telling a robot how to do these actions. (And, of course, my brain went right to how I could retro-fit a Tonka digger with servos and motors to solve this problem. I swear, if I had a budget I could make the best toys.)
Again, this is likely to go over well. Or we are raising an evil genius.
The Cubetto stuff has less hacking potential for me, but is definitely more kid accessible, and game and story oriented. It will be interesting to see if any of this stuff actually scratches the itch she has expressed.
Because, as we all know, scratching itches is what drives the hacker ethos.
So, I got my daughter a dancing robot for her birthday.
I think this is going to go over well.
Over on Martin Fowler’s site, Birgitta Böckeler provides a nice introduction into the gendered nature of early computing, and the historical fall-out we live with today, that is a very compelling read.
The stereotype of the socially-awkward, white, male programmer has been around for a long time. Although “diversity in tech” is a much discussed topic, the numbers have not been getting any better. On the contrary, a lot of people inside and outside of the IT industry still take it for granted that this stereotype is the natural norm, and this perception is one of the things that is standing in our way to make the profession more inclusive and inviting. So where does this image come from? Did the demographics of the world’s programmer population really evolve naturally, because “boys just like computers more”? What shaped our perception of programmers? This text is about some possible explanations I found when reading about the history of computing.
This is a very interesting synopsis and overview of scholarly looks at the history of computer programming from a gender perspective.
Stop reading this right now and go throw money at the Circuit Classics crowd-funding effort. Throw all your money at them.
Still reading? Ok. Let’s try again:
Someone had the awesome idea of creating a set of electronic kits that perfectly capture the design and aesthetic of “Getting Started in Electronics” by Forrest M. Mims III, down to the beautiful hand-written notes that accompanied each circuit design.
They are a joy to behold.
The only constant is change.
So, the wheels have turned ever so slowly, and now it looks like I am to be an Android application developer, at least for the next few months.
This new position I took recently has, so far, been the usual tour through Java and C++ with the expected diversions into Ant and Jenkins. However, I’ve found out this week that I’ll have to get up to speed fast on Android on a set of embedded devices (i.e., not strictly a phone of some type). So, not only will I have to sort out Android app development using the Android APIs, but also how that fits into a highly custom runtime we’re targeting.
The Internet of Things. It is all around you. It is there when you pay your taxes. It is there when you take out your neighbour’s trash. It is made up of cloud-based web apps and Node.js powered interfaces.
But for weekend warriors and hobbyists, setting up various toolchains for cross-compiling can be a real problem. To be fair, it’s a problem that’s often measured in hours as you sort out all the steps and read blog postings (yay for the internet, because in the old days you had to figure this stuff out seriously out-of-band) as long as you are reasonably good at hacking away on computers and figuring problems out in a step-wise manner.
The problem I have is keeping these toolchains up-to-date and working over time. I’ll get things working so I can, for example, hack on my EZ430 Chronos, and then put that down for a few months. When I come back to it often some unrelated system change has broken some key step, or I need to update part of the toolchain which causes a ripple effect of connected failures. So, we are back to a few hours of busy work putting things back together, which often burns up the time I’ve blocked out for the project, or my interest (or both.)