Direct InkJet PCB Resist Printing

So, over on the Home Brew PCB Yahoo group, this fellow, Volkan Sahin, announces one day that he has modified his inkjet to print straight on to copper PCB and gotten it to resist Ferric Chloride long enough to etch. And etch quite fine lines at that. I watched the thread that ensued with considerable interest. Then a little while later another fellow, Stefan Trethan, announces he's repeated Volkan's results. What's more he posts a very detailed description of the printer modification and printing procedure that James Newton captures with fidelity on his Wiki.

At this point I am salivating. I have to have a mod'ed printer like this.

So in this blog, among other things, I will chronicle my efforts to reproduce Volkan's and Stephan's fabulous results.

To begin, I got my C84 off eBay. Less than $30 shipped! The ink kit I got from MIS for $88 shipped. Heh. Still the ink should last a while. I only bought yellow, the stuff reported to resist the best and also a little black. I took a few CCs of the black and put it in the yellow as others had reported they'd done to improve the yellow's visibility on the PCB. Two or three CCs was all it took to turn the entire 4oz bottle of yellow to a dark nasty sort of grey. I loaded all four refillable carts for my Epson with this stuff.

I'm not going to chronicle the assembly and installation of the refillable carts for the Epson as this is a reasonably easy and time-tested procedure that is engineered to succeed. I got it right on the first try and lots more than two people have done it.

Anyway, before I began I wanted to test fire the intact printer on regular paper to make sure it sort of worked. I hadn't gone after the vacuum tube assembly that Stephan assured me I'd have to clean so I wasn't uber hopeful. On the first try, nothing came out. However, I took out the black cart, pulled and pushed the syringe while plugging into the bottom with the priming nozzle, and then reinserted and ran a nozzle clean from the maintance screen.

On the second run I got this:

That would be death for a PCB of course. So a day and another nozzle clean later the printer shaped up:
The black portion of the nozzle test (left slashing lines) is perfect even thought the color pattern is broken. (The color is loaded with the same stuff the black is, so who cares?) And the test squiggle drawn in Paint is un-broken except at the top and left where it was broken in the original Paint file.

Good results seeing as I haven't even touched the vacuum system!

So that is where I stand as of tonight. I have a well-enough functioning C84 loaded with an easy-to-refill ink system. Now I need to embark on the printer mod's described in the Wiki. As ever, real-life intrudes on my hobby. I don't think I shall have chance to do anything tonight as this blog entry has consumed all of my free time. But I shall press on! I can smell ultra accurate etching in my future!

Another Session!

Woot! Two nights in a row! Still not a lot of progress though. This SPI bus sharing is a little dicier than I thought. Of course I'm making it hard on my self, as usual. I want the bus to multiplex. I want the bus the be able to read data in from one device after I've commanded a second device to gather data and am waiting for it to get the result and pop its READY line. Its a bit tricky keeping track of when the bus is available and when its not. I know that my logic right now is pretty busted. It so busted that I got disgusted and put off fixing it for another night.

I'll come back at it soon and straighten it out.

RoboMagellan Progress (Inchworm style)

Well I spent a few hours working on the RoboMagellan bot tonight. I didn't get much accomplished really. Much of it was setting up a work environment here in my computer room.. one of two air conditioned rooms in the house. Man it was hot today.

I modified my SPI bus. I put 180 resistors in series with the 3-axis compass. To my delight I found that the circuit still worked AND I didn't have to remove the MCU to drop a new program in. Flushed with success I went to add the accelerometer MCU to the SPI bus as well. Of course there was a problem: all my remaining Mega32's were non-responsive. I had messed up the fuse bits some way or another.

I got KJohn's STK500 up and running and recovered two previously toasted chips via high-voltage parallel programming. This was my second try at this and I was most pleased to succeed.

I added the new MCU behind another set of resistors and tried to program it live. Initially I couldn't. So I raised my resistors up to a few thousand and live programming worked. Then I realized that the other MCU was powered down. Trying again with both MCUs powered up I found the programming cycle got stuck real early in the cycle: during the initial read. Usually I get some error msg form AVR Studio, but in this configuration it just hangs.

I don't have a solution but its not a huge deal since I am using Eddy's Mega32 board and each has an independent power supply. Its a snap to just yank the battery cable on one of them. Still it would be really nice to figure out a circuit that would let me program with both live and both on the SPI bus. I'll just live with for now.

Next session I want to see if I can get some data out of the Accelerometer MCU. Should be interesting going back and forth between two bodies of code to try to get them to talk to one another!

Tilt Compensated Compass

So, as I posted earlier that the magnetic field here in Wisconsin is mostly straight down into the ground. Normal procedure with a 3-axis magnetometer seems to be: use a multi-axis accelerometer to get the pitch and roll angles of the compass, correct the detected 3D vector, then toss out the Z-component and compute the angle difference between the projected sensed vector and the front of the sensor. However, since most of the field is down, the projection seems to me like it tosses out a bunch of resolution. I'm going to try to write down what I think might be an alternative technique that won't trash the resolution by avoiding a projection operation. (Or at least waiting to project until most of the magnitude is not in the direction of projection).

I first want to define the heading plane in 3D space. This plane is normal to gravity and due north is right along its axis. (X or Y. Doesn't matter.) When the robot/compass is heading due north the sensed magnetic vector points sharply down from the plane, northwards and just a touch west. I'll call this magnetic north. Magnetic North's direction is related to due north's by a pitch angle and yaw angle. If you remove the pitch and then the yaw from magnetic north you then have a vector that is in the direction of due north in the heading plane. Let's remember these rotation operations as unpitch magnetic north and unyaw magnetic north.

In general, when the robot is out and about it is pitched and rolled verses the gravity vector and it is yawed versus the magnetic north vector. The idea here is to rotate the sensed magnetic vector into the heading plane where a meaningful angle calculation can occur between the rotated vector and the due north vector. So if we take our sensed vector and unroll the roll detected by the accelerometer, unpitch the pitch detected by the accelerometer, then unpitch magnetic north and finally unyaw magnetic north the resulting vector ought to be in the heading plane and a simple trig operation can be performed to get the robot heading.

In practice it the result won't be in the plane, but it will be close enough to not worry about the Z-component. One reason it won't be quite in the is that getting the exact value of magnetic north is not all that easy. For the time being I will probably use the USGS predicted magnetic north.

Anyway, this was my effort to type up my thinking on this whole 3-axis tilt compensated digital compass thing. Hopefully it makes sense. Hopefully I can make it work in code.

RoboGames 2006

Readers 'n' stuff. Weird. I didn't want to post about RoboGames a couple of posts ago simply because I wanted to talk about the magnetometer. I forgot to come back and post about the games. I'll try to make up for it now:

So in June I went to San Francisco to play in the RoboGames. I brought Felix, my new RoboNova and Uno, the vernerable old mini-sumo. As you can see above Felix won 2nd place in the Robo-One Demonstration contest! (Uno got his ass kicked.. he is now retired.) Matt Bauer was kind enough to make a video of Felix's performance. Thanks Matt!

Anyway, RoboGames was quite interesting. Boy howdy its a big event. I'll bet there were 200 or 300 people in the building at once at some points. Anyway, I had never seen combat robots (RC) in person. They are actually quite something to watch. They make one hell of a racket and the noise really pulls on your rubber necker strings. You feel what the spectators in Rome must have felt at the coliseum.

Nonetheless, the most fascinating contests, the ones that I still think about after the contest is over, were the autonomous navigation contests: RoboMagellan and Trinity FireFighting. The whole magnetometer thing below is all about RoboMagellan. I had never actually seen a Fire Fighting Contest. I had heard about them, but they didn't register as being very cool to me. Once I actually saw one and saw that it was really all about indoor robot localization, I became pretty interested. It would be a great opportunity to implement the 2-D-webcam-laser-range-finder concept that I saw at the SRS website and have been itching to do ever since.

The other majorly cool thing about RoboGames were the winner awards. Rather than give prizes as we have done in ChiBots, RoboGames gives electronic medals like the one you see pictured above. I LOVE MY MEDAL! I like it better than any prize I have ever won. At this month's ChiBots meeting I asked the members if they would like to drop prizes and switch over to something like the RoboGames medals. They heartily agreed! So, now we are in the process of designing an electronic medal that is specific to ChiBots. Compared to the Combots logo, our logo is pretty expensive to make so we'll just have to wait and see what it finally looks like, but I'm excited about it!

Anyway, overall I had a blast at RoboGames 2006! There is a pretty good chance I will return next year.

High Latitude Fun

So I looked some more at the data the magnetometer was giving me. For a while I thought that the X, Y and Z axis might not be aligned the way I thought they were or in the most logical way. The reason I thought that was that the Z-axis was registering some 4 times higher than X or Y. I knew it wasn't a calibration issue because I could re-orient the device that the large reading would move. I figured the large reading HAD to be due north. NOPE! The larger reading on Z was exactly what it said it was: a big magnetic field straight DOWN. WTF, I thought? Localized field? I took the device outside and there was no change.

Finally, after some looking I happened upon the USGS National geomagnetic Program website. They actually have models of the Earth's magnetic field. There is this applet that lets you select a model (they update every five years) a latitude and longitude and the current time. It then dumps out the predicted X, Y, and Z field strengths. Sure enough, the predicted value in Z was 52000 nT down and only 18ooo nT north. I had no idea the Earth's magnetic field tilted so early.

Its good to have confirmation of my readings. It was kind of a eureka moment when I ran that modeling applet. However, after that died down I realized that it kinda sucks a little in that much of the field strength is in a direction I can't use for navigation. Wait. Or is it? Hmmm. Thinking in a post is probably not good. However, just this moment it occurs to me that on the basis of the model I know which direction the Earth magnetic vector is suppose to point. That vector has a simple relationship (two rotation operations) with the "North" direction. That should fact should be usable and allow me to maintain my measurement resolution. I'm having trouble coughing up a sentence that expresses my thinking so I'll stop trying and post it later.

One Day I'll Be a Real hobbyist

Did some more work at long last. (Oh yeah, went to RoboGames 2006, got 2nd place in Robo-One demonstration but I'm not gonna talk about it). Anyway, I can now talk to my stupid 3-axis magnetometer over the SPI bus. The AVRLib doesn't seem to work so great. I keep dropping back to the examples in the Atmel docs, which work great. The data itself is a bit confusing, but I think that is because the axes may not be align the way I think they should be. I think the x-axis is vertical on the PCB board. Its hard to be sure by using a magnet because the field is so misshapen that it could actually be going a different direction from one sensor to the next. I'll have to figure out how to do a good job testing that.

RoboMagellan

So last night was a good night. My gf had a girl's night out so I got the whole evening to work on my bot. I added a 2nd story to the frame of the bot a hung the inverted joystick from it. There is plenty of clearance for it with the extra height. Boy it was harder than I expected. I only have a hand drill right now so I ended up using a 1/4 inch bit for #8 screws. Even then, I was all too often misaligned from one aluminum piece to the next. That MircoMark mill that David Cook talks about in his Intermediate Robot Building book is starting to look good. I hate to blow the $900+ or so after shipping and accessories, but I suck so bad at mechanical stuff that I need all the help I can get.

I also put a sentra bottom on the bot. Boy that stuff is hard to cut with a razor knife. Its doable, but I wish I had a better way. A band saw would probably make for a shredded edge. A water knife would probably do great work. I'll check the sofa cushions for some spare change to buy that. *snort*

Anyway, the gf has class though much of the evening so I may get some more work in. I might make some more sentra panels or I might put the wheels back on and wire up the joystick. I's like to see the data output from that thing as the bot drives.

Serial Protocol Driver

Well I've slogged my way though the skeleton logic of a serial protocol driver for the Linux CPU. I had to learn about Linux semaphores, mutexs, threads and IDEs. The IDE I ultimately chose was Anjuta as I am able to get a limited sort of prototype hint box functionality with it. Its no MSVC but the prototype hints do help once the function has been setup. (I have to put the prototypes for system calls in manually.)

Now I need to make a fake loopback protocol and test the features of the protocol driver. It should never blockup. It should enqueue several requests and return the responses in the order it received them.

It will be nice if it works. This part has been very psychologically hard for me to do because its practically difficult and conceptually simple. Those always pose serious roadblocks for me.

Kalman Filtering

Been a while since my last post. I've been tinking away on some new C++ code. The old code that ran the GPS experiment is pretty primitive and very specfic. So in preperation for switching over to dead-reckoning I am trying to make some nice clean and fresh code. So far progress has been a bit slow because of the holidyas and a new role at work. However, I have made some nice data types that encapsulate the concept of a robot pose and a kalman float that encapsulates the concept of an associated sigma value and the kalman filtering process itself.

Once I get some fo these basic types I can turn my attention to the basic code flow of the robot: absorb data, compute plan, execute plan.

GPS

I'm in Atlanta this weekend and happen to be riding in a rental with a GPS. I've been watching the GPS an notice that is occasionally screws up the heading really really bad. It can get completely turned around. Of course, we are amongst sky scraper and the bot is in a park, but the signal strength is still not good according to the GPS. I have my two-axis accelerometer+gyroscope IMU board and I've been studying up on dead-reckoning via encoder. I have even layer out a basic data flow model for a kalman filtering algorithm that incorporates GPS, IMU and encoder. Still, I might yet try to elevate my GPS antenna one more time as I think it may be a while before my current software plans become drivable. Also there is the Builder's Day Out this weekend and I like to have something that is closer to working that what I currently have. :)

First Place Loser!

The Chibots semi-annual competition was this past weekend. I just brought the ancient Uno in. I really need to finish my other sumo. Anyway, I went up against Black Cheddar in the first round and was knocked out. The bot is so black that my IR sensor can only see if its within 5 or 6 cm. Since there were some many Sumo's they went for single elimination. I thought I was done. Then later they felt bad and had a losers bracket for all the first round knock-outs. Uno won that bracket! So as a grand finale to the Sumo they put the first place winner up against the first place loser! (Me!) Who was first place winner??? Black Cheddar, of course. *sigh* It was a quick death.

GPS Follies

Bah. I tried the GPS code again. I was pretty sure the turn rate was just too high for what I was trying to do. So I lowered the turn rate and took it out again. Once again I was beset with technical difficulties. The bot ran twice and just sort kinda went in the right direction, but I still wasn't happy with it. To make matters worse, the program would not run everytime. There was some issue with getting blocked on the serial port. I guess either the motors or gps were not responding. Dunno. Anyway, the upshot is that the two times I did run I didn't get log files because I didn't pipe the output to a file. So I don't really know what was going on. I could be that the math is just not precise enough or the heading updates were still too slow or whatever. I don't know and I am ticked that I don't have a way to look back and find out. I should alter the code to directly write to a file. I should also abandon this GPS thing and get on with dead reckoning. I only did the GPS again because it was such a simple change to the code to slow down the turn rate.

Sigh.

Oh well. Back to the drawing board.

The GPS log files

Well the GPS log files confirm that the data coming from the GPS serial port changes no more often than 1 per a second. Looking back though the newly discovered PDF version of the GPS programming manual I see that it expressly states that the GPS computes a position solution only once a second in its performance spec section.

The turn rate and short (90ft) distance I had the bot going won't do with that kind of update rate. If I want the test program to really work I will need to slow the turn rate way down and probably the the overall speed as well.

I'm not sure if I'll bother since I think I understand the issue pretty well and the time might could be better spent coming up with a new dead-reckoning+GPS based program. The motor controllers are all wired to do closed loop control on the motor velocity. I just have to set the jumper and write a program to set a new heading based on a timed difference in left/right wheel velocity. I could even double check the new expected heading with the GPS.

GPS Navigation

Well it was a fine day for bottin'! I took the bot out with its new correctly GPS goal and let it rip. It even sorta drove vaguely in the correct direction. However, it did a lot of loop'd'loops and meandering too. I tried speeding up the rate at which I request data from the GPS and the rate at which I controlled the motors but it didn't really seem to help. I haven't been through the logs thoroughly but I suspect that what I'm going to find is the actual content of the GPS messages are not changing very quickly at all. Maybe once every 5 seconds. That is to slow to directly control the robot. I think I will now have to add in a dead reckoning component. I should start thinking about the general mechanism to navigate before I do however. I'd like to avoid writing a big program that has to be trashed because its not architected well enough.

All in all however, I am very pleased to have seen the robot drive around and at least attempt to reach its goal. The fact that the GPS is likely too slow to directly control the robot is a decent experimental result for today. Its is not some technical failing of mine.

Distance Calcs

Dammit! Just got a chance to review the logs from the last outdoor run. At the time I was mystified as to why the distance to goal function was returning hundreds of thousands of meters. The answer: when you put in your longitude you're supposed to put in negative numbers for western longitudes. Duhhhh. My goal was on the other side of the frickin' world, literally. Jeez. To be thwarted by something so asinine!!! Its dark now, but I really want to take the bot out anyway. I won't but I can't wait for my next chance to do so. It should really work!

Rained Out

Well I was making good progress until it started to rain. The GPS serial code needed some tweaks. But then when it ran I started getting huge distances to my target way point. So something is clearly wrong with the distance computation code. I'll have to go over it again.

Maze Bot Update

I guess I should mention that I am not working on the Maze bot until I finish the RoboMagellan bot. Id on't have enought time for even the RoboMagllean let alone both RoboMagellan and Maze. So, the RoboMagellan is the way cooler contest. So that is what I'm going to work on.

Rise from the dead!

Since its near Halloween I guess it is appropriate to resurrect this blog. Its has been totally dead because all I have been working on is my RoboMagellen robot and its supposed to be a secret. But as the guy who most wants it to be secret is not really adding much to the robot. In fact only Paul, Tom and I have really done anything directly towards the bot, I feel I can go ahead and post here while I wait for my battery to re-charge.

My time is soooo limited its sick. My progress has be horrifyingly slow. I literally steal time to work on the bot.

Anyway, I have some code now that should drive my bot toward a GPS way point. I think I have finally mastered the Linux serial port scheme. It took a while to get it right though. Once the battery re-charges I'm going to take the bot outside and give it a go.

Right now I'm seem to have a custom carrier PCB for my GPS that works despite the need to cut it up all to hell and back because I got the connector backwards. The motor serial code is finally seems to stably command the motor controller. The worst problem is the the very first command after power up always seems to error out. Easy enough to send an initial stop command. I also have Paul's 933Mhz SBC running Puppy Linux and interfaced to the custom PCB that level shifts for the GPS and motor controllers. The code compiles. It has undergone some testing. It really should work.

Wish me luck!

I forgot to post that my new robot shop is up and running. Its in the basement! I'm hopeful it will mean less clutter since it is not in the computer room any more. Also, as I live on the first floor I shouldn't feel bad running the scroll saw to cut my chassiss. Also I'm making an effort to keep the place neater so that I am not looking at a thirty minute clean up operation before I begin a new project. Lord knows that can stop me in my tracks! Of course, being out 2 1/2 weeks out of the first month I've been in the new place has not really helped. But still I have high hopes.