Rob Stoddard's Technical Web Log

---

Programming pattern professionals, today is a great day. I have invented a new programming pattern, to solve certain problems that have arisen in my workplace. There are two heads on a video card nowadays, but one GPU. The previous program which decoded our video streams had handled the video for each screen independently, there were two programs running to decode video. This wasn't entirely effecacious since there was a lot of GPU context switching going on, switching out much of the same information. The renderer was created with a singleton pattern, making it impossible to create more than one object of that type. Unfortunately, the program now should take on the second screen with a second renderer, render loop, and all that, which led me to the discovery of a new programming paradigm, the "doubleton pattern." Remember guys, you saw it here first.

Be wary of style sticklers. Today I have revisited some code that I had written which was changed by a C++ style-stickler in my company. This individual, who would be a good programmer but for his over-education in good OO design, has made my code, which was easily modifiable about as resistant to change as I could ever imagine. Good OO design supposedly makes code easy to change, but in this case it has proliferated classes; there are 9 classes where there used to be 6, currently 2 base classes and 7 implementation classes where previously there were 2 base classes and 4 implementation classes. I am typically one for putting implementation into a base class if it belongs there, those who are strict about keeping implementation out of a base class are merely adding extra cruft to their design. The real question is, where is that cruft? A purveyor of "good design" would create a base implementation class somewhere and would somehow factor that base implementation into the mix, a "less than perfect" designer that keeps to that rule would put that base implementation into each derived class. What I am trying to get to here is the fact that "good OO design" goes about so far, at some point reality has to be factored in, and good sense should be butressing that design. If good sense were used to butress any design, be it a good or bad according to the "OO design expert," it would be a good design, and will not resist change in the future. If one is a style-stickler, that programmer will go into the designing arena with one hand tied behind his back. So called "good OO design" is a set of guidlines that needs to be used with sense and reason, otherwise the designs produced from it may be a bad design.

I started looking for a serializer recently. After all my nightmares with Boost, I certainly wasn't going to use it... But it seemed like the only one out there. I bit the bullet and tried to emerge Boost on my development linux machine... It was the first ebuild in 5 years of Gentoo usage to fail. I decided to look around some more, and I came upon S11n. S11n has a hefty 121 page manual attached to it, as well as numerous code examples that are free for your viewing. I was starting to think that the OO crowd was hopeless, but S11n offers a good deal more than a shred of hope.

Whomever wrote the standard C++ string class needs to be shot. This class has given me an endless supply of grief because rather than copying the string across when it is copy-constructed, it copies the pointer. Copying the pointer obviously makes the data appear in both instances, but when the pointer is deleted or the string is modified, then the contents of the freshly copied string become garbage.

I have started my thesis classes for my Master's CS degree. I have a fair idea of what I want to do for my thesis, although I don't know what I will be able to get away with. Most of the other people in the class have no clue, I think they were hoping the teacher would hand them the project on a platter. Right now we're watching a presentation by Dr. Larry Smarr of the San Diego Superccomputing Center. He was discussing the "National Lambda Rail" which is a lot like a new backbone for the internet. He's described a few modifications to the networking protocols that are to be made. For one, he suggests that TCP will not be used. "TCP is for congested networks, which this will not be." When the Internet was first created, it was not a congested network. It really wasn't going to be, but the designers had the foresight to at least employ congestion control in TCP... I guess foresight is just not fashionable anymore.

I am dealing with a neat little code generation technique for wrapping Gtk+ code with Gtkmm code. It isn't as easy as the documentation makes it sound in the introduction. I have learned a lot about what not to do in documentation from this simple little exercise.

First thing, never base your documentation upon the internals of a project that is outside the bounds of your documentation or control. The authors of the gtkmm documentation that detail this little thing have based their documentation upon the Gdamm library, which has diverged very far from the description offered in the documentation. Also, the Gdamm library has nothing to do with what is being documented here. What is supposed to be documented here is using gmmproc to convert a Gtk+ library to Gtkmm. Most of the tutorial describes how to modify Gdamm to suit your library install. No consideration is given to those of us who just wish to simply use a Gtk+ widget in our Gtkmm code without going through a complete library rewrite.

Second thing I have learned is to document what you're here to document, and not diverge from the subject. In the end of the whole documentation chapter dealing with gtkmmproc, I never once see the program actually invoked. So much time an energy go into the modification of Gdamm that I wonder if the chapter is misnamed.

Really, in truth, I didn't learn these things, I've known both of them all along. It saddens me that there are numerous people out there that cannot fathom the concept of documenting something that they intend to document and not diverge into la-la land. It goes to show yet again that in free software, you get what you pay for.

Yesterday, my server's raid array lost a disk. I went out and bought a new disk, put it in, and ran raidhotadd. Shortly after running raidhotadd, a second disk gave up the ghost. I lost everything that I have done in the past three months, luckily that mostly consisted of a bunch of class materials for classes that are already done and over with. The only true losses were my MRTG logs and my blog. I also lost some reconfiguration on my web pages, but that's easy to recreate. I think I am going to try sticking the other raid array that I have onto this machine and mirroring them so that if I lose a raid array like this ever again, I'll at least have a second array with the same data.

Yet again, it's been a long time since I wrote. This is the effect of the job and schooling combined, I don't have time for much else. Today, I have been dealing with a company I promised myself I would never deal with again. In the past, I had bought a Matrox video card. After reading all of the wonderful specs on this card, buying it, installing it, I was sorely disappointed.

This time, I am dealing with their imaging department. My company has acquired one of their new HD video capture cards. It worked twice. I have been dealing with their support division, and have gotten "special care" since we're an integrator. If the service I got was "special care" I would hate to see what the common citizen gets... Because this sucks. I have been told by their service department that I'd get called back or emailed, but every time I have had to prompt them with a call or email asking if I am going to get what was promised me. I eventually was told to send the card back to their RMA department, but they didn't give me an RMA number or shipping address. I had to ask who to contact for an RMA number, which took almost a day to get a response. After getting that information, I had to email somebody from the RMA department, and have yet to get a response. I have been at this for nearly a week, and I can easily see this extending past a week... Considering how much these capture cards cost, I would hope they'd be fast to support it, but I guess I am wrong. If anybody from my company bothers to ask me, I am sure to give Matrox a bad rap.

It's been a long time since I wrote, so I figured I would type something in. I have been doing a lot of research on the various standards with relation to my work. There are two things that have recently gotten my goat, the first is that troll forum poster that loves to say "Your post does not belong on this forum." It is understandable if you have a forum about cars and I decide I'd discuss my cats, that's off-topic. If I decide, however, to discuss gagues or transmissions, then that may be on-topic, however that troll will come along and say it's about transmissions, not cars, so therefore it's off topic. Hate those trolls. The second thing I hate are those people that request or send emails as answers to mailing list / forum posts. The information that is being divulged may help hundreds of people searching for the answer to your question, but when your answer comes in email, people who come upon your question will never know because you selfishly had the answer emailed to you.

This time around, I have a big beef with ACM. I went and spent what is to the standard person, a rediculous amount of money on a patent, then I spent another rediculous amount of money getting a poster designed for SIGGRAPH's IP Marketplace. Finally, I spent a third rediculous amount of money on getting my submission to that IP Marketplace. So, on the day of the big show, I go to SIGGRAPH and find that the IP Marketplace is absolutely barren. No posters, no buyers, in fact, they didn't even put carpet on the floor. There was a fellow there to help people, but he didn't know anything about what's going on. There was a two hour talk about intellectual property that I was invited to attend. The two hour talk was nearly exclusively about the fact that yes, you can get patents for movie scripts.

I have a beef with X.org. It's this whole XVideo interface, and the definition of a "Drawable." Those whom have written Xv have confused the definition of Drawable and Window. In the XVideo spec, XvPutImage supposedly can draw to any Drawable. Deep within the Xserver, however, there is a comment that details that the Drawable is a Window. Just as not all animals are cats, not all Drawables are Windows in X. Take for example, Pixmaps and back buffers. I want to be able to draw to a back buffer with XvPutImage, but no dice... It causes the program to crash. I submitted a bug report on the Xorg bugzilla, but nothing - it hasn't even been considered.

Xorg seems to dislike having specification bugs, and is working hard on eliminating all specifications. If you look at their site for documentation, you'll find very little. I have yet to find any documentation on function calls on the Xorg website... However, there are some manual pages floating around elsewhere on the net that'll help. Xorg, keep up the good work. With a few more years of good programming practice, XWindows will be completely unusable.

Do we need namespaces in C++? I have asked myself that question many times. There are plenty of people out there that establish naming conventions such that their classes and structs won't collide with other classes and structs, and then they wrap everything up in a namespace. The question is, is all that necessary? I often name my classes simply, and then use header file including to hide classes that are wrapped up. The wrapper class is visible to the main application, the wrapped up class is tucked away in a header that is only visible to the implementation of the wrapper. In the end, I don't need namespaces nor funky naming conventions to make my application... Or do I? Just today, I ran into an issue with compiling my 3d engine project, (employer: this was at 6:45 AM, before I went to work) where I have a bunch of linker issues. I found that there were two matrix.o files ending up in the object file directory. Perhaps file namespaces would be appropriate? Or maybe I should port some of those funky naming conventions to use in the file names? Regardless of what I do with the file names, I am sure that namespaces in C++ are not at all necessary.

Perhaps this doesn't belong here, but I have to rant on this. I am very mad at my school for allowing this to happen.

On Monday, I took a midterm exam in my first Software Engineering course in my master's degree. It was a rather tough test, but the fact that it was open book was a saving grace. I don't think I mentioned this, but out of the 42 students in the class, 36 of them are from India. About half of the class had books, so the teacher allowed sharing of books. My brother and I shared a book and were careful not to pass any information, not even the page we were using. However, these students were passing notes inside their books, and the teacher noticed. The teacher said there was rampant cheating going on in the test. I have some questions for him... Why didn't he do anything about it? Why didn't he kick some of these students out of the class / program / school? Is the academic honesty policy a paper tiger? Is it because these students have a form of diplomatic immunity? Is it because the head of the Computer Science department is from India himself? I don't know, but lemme tell you, I am infuriated. If you've had to work hard for your degree, you ought to be too.

I forgot to mention a while ago that I had forsaken the toaster oven. I found that it doesn't have any real temperature control, it tends to cook at maximum temperature. I have also ditched the solder paste for most of my soldering ventures. That solder paste had a tendancy to spread when heated, get underneath chips and short them out. So now I use the old fashioned soldering iron and very thin spooled solder. I am hand soldering components down to 0402, which is quite a feat.

I wanted to take a bit of time to illustrate one current failing of the educational system or, more to the point, lack of failing. The team project is touted by teachers as a wonderful method for teaching students, since these students will some day be working in a team in the professional world. I disagree. In the professional world, people that do not become a worthwhile part of the team end up in the unemployment line. People that don't prove their worth in the educational system team often ride out the course with their team, and milk a good grade off of those team members that they've selected for their team, and eventually earn a degree off of them. If the adept people catch on to this scheme, the teacher very quickly diffuses their attempts to shirk all riders, and will forcibly allot these people to the teams that need a workhorse.

In my day, I have earned three bachelor's degrees. Yes, three. Unfortunately, two of them were stolen. I suppose this happens to a lot of people that have worked hard in their universities. I am looking at my Master's classes, and it appears to me that I will be earning up to five Master's degrees, only to have four stolen yet again. The problem I have with this is quite simple. When those people that learned to latch on and ride the wave of success enter into the marketplace, they will have few skills to offer in the real world. They will have a master's degree that shines just as brightly as mine, and the fact that they know so little about their chosen profession will only bring down the averages and take up valuable job-slots. Their lack of knowledge reflects directly upon me, making my Master's degree worth little more than the paper it is written on.

Apparently the strategy worked. Now I have a "real job" at a company called Telanetix. This company has a rather large system of computers that they sell or rent as their product. This system is hooked up to four huge monitors with cameras hidden inside. It allows the user to communicate with the person on the other side in clear video with very good (HDTV?) quality. It seems like the company is rather small, but well funded. Since it is small, I have been told that I will have to multitask well. I multitask very well... I can program many things, most preferably all at the same time.

Unemployed? Are the recruiters just not calling? Some have accused the resume as being the culprit. I think different. I think you're just not taking naps in the middle of the day. That's right! Recruiters only call while you're trying to catch some sleep, and only during their working hours. So if you need a job, make sure to be catching an extra forty winks during the day. It's the only time I ever get called from recruiters, and my mid day naps are paying off.

I am sorry that I have not been writing as often as I should. I kinda hit a dead point in my coding, with so much to do around the house, and a brother that wants meto help him make stuff for his medival group, I have had very little time or energy to code. I have decided to warm up my old 3d engine and add some form of skeleton based model loading ability, and to do this with the least amount of blood, sweat or tears, I decided to use the Cal3d library. So far, it seems to be a rather good library, albeit written largely in Hungarian Notation. What I think of Hungarian Notation can be easily shown by viewing the Super Secret:Secret Squirrel episode "Agent Penny" and carefully analyzing Morocco Mole's actions. If you haven't seen this episode, I'll be so kind as to describe it.

In this episode, Secret Squirrel meets with the short end of the "downsizing" stick, and Chief's new "top agent" is Penny, his secretary. Morocco Mole, Secret Squirrel's ex-sidekick is now filling in Penny's spot as secretary. Morocco Mole takes to reorganizing the file cabinets in Chief's office, which have people's records in alphabetical order by name. Morocco, however, has a better idea, he's going to organize them by classification, or more exactly, he's going to file the criminals under 'C' for Criminal. By the end of the episode, he's sucessfully placed every person's file (since they're all criminals) under 'C' for Criminal.

Anyways, in the Cally demo, there is a good chunk of source code that I must say typifies small minded programming practices. This code is "well commented," just like what a first semester C++ student would earn an 'A' for on his "Hello World" exercise. You can read all about this wonderful code here.

It has been two months since I posted anything here, largely because I have been doing a lot of around the house work, a little electronics work and almost no programming at all. I have been busy with mundane things. Anyways, recently I started working on the filter again, and have some good food for you.

Coordinate Systems and Inertial Navigation

First thing I would like to state... To maintain some sort of cohesion with standard math, it is usually suggested that one should stick to right hand navigation systems. The three plainly obvious coordinate systems to use would be:
Latitude, Longitude and Altitude
East North Up, or ENU
North East Down, NED
These are alright, except for the fact that they stick you to systems that make modelling equations a real pain. There are a few systems that make modelling equations much easier, and I am going to illustrate them.
Earth Centered, Earth Fixed or ECEF
Earth Centered, Inertial
I chose ECEF as a good basis for working through coarse align, doing some debugging and whatnot, but the system that I am using for the actual inertial navigation system is ECI, and I'll tell you why. ECI has a bad habit of making modelling equations go POOF. Going POOF in a lot of cases is generally classed as a GOOD THING. That means there are fewer equations to have to troubleshoot. Unfortunately, the coarse align equations that I am going to give you (the only ones I could find on the net) written in INS and GPS Integration by Casper Ebbesen Schultz do not work quite well in ECI, but they work splendidly in ECEF. Shortly I will post a solution to the ECI coarse align equations, but first, for understanding of coarse align, I will post the ECEF equations.
Since ECEF coordinates are earth centered, the up vector is equal to the normalized position vector. This makes finding and extracting gravity a real cinch. What I did was calculate an upward vector and extract the gravity almost like a bias, save for the fact that it is affected by the orientation of the INS. With gravity resolved in such a way, it should not affect the acceleration sensed by the filter unless of course, there is an attitude error. When there is an attitude error, gravity will show up in your X and Y accelerations (assuming Z is up). That acceleration error, when divided by the gravity, gives the sine of the error-angle. I find it's easier for me to compensate for this error angle by nudging the rotational velocity a small amount.

Roll error = asin( xacc_error / Gravity)
Pitch error = asin( yacc_error / Gravity)

Now, what Schultz did, he summed up the error over a period of time, and then divided by that time. I suppose that's an alright method, however, I like to be able to see things working. I don't want to all of a sudden see my INS flip to a certain angle, so I did things a tad differently. For one, I put in a state variable for the amount of gravity sensed... There is good reason for this, since when I was a WSN-5 tech in the Navy, I used maps of gravitational fields on the earth's surface. That's right, GRAVITY IS NOT CONSTANT across the surface of the Earth. It ranges from 9.78 to 9.84 or so meters per second squared. Anyway, I use a state variable that allows me to use a standard gravity equation in a filter that is not affected by gravity, like the GPS filter, and I affect that gravity in my IMU filter. So, I found that when there's an attitude error, it will force the sensed gravity in that state variable to go down, damping excessive error in attitude by causing the roll and pitch to be corrected faster. Unfortunately, that works for ECEF coordinates, but since ECI makes the accelerations due to earth's rotation obvious, it has a tendancy to really screw up these coarse align equations, but all is not lost. It turns out that these rotational accelerations can be dealt with, allowing for an elegant first hack at gyrocompassing, without the gyros. I will be happy to give you these details on another day, when I have worked them out for myself.

Here is a list of the PDF files about Kalman Filters that I have collected so far. I have added notes for those that I have found to be of exceptional utility.

• GAST_kalman.pdf
• GibbsKalman.pdf
• INSforanAUV.pdf
• KalmanMarkley.pdf
• SLAM_INSkalman.pdf
• StrapdownAlignment.pdf A description and bibliography, no technical discourse
• anotherKalman.pdf
• attitudeKalmanMil.pdf
• basicnav.pdf
• doubleKalman.pdf
• dual_kalman_vision.pdf
• gpsins.pdf An excellent source for alignment equations and more
• gpsinsandcameras.pdf
• kalmanAttitudeGyro.pdf
• kalman_kelly.pdf A fantastic resource, I highly suggest
• kalman_quat.pdf A fantastic resource for quaternion based attitude filtering
• kalman_quat2001.pdf
• lowcostINS.pdf
• ras99Quats.pdf
• robotkalman.pdf
• unscentedKalmanQuat2003.pdf
• wahbaKalman.pdf

Yesterday and today I worked up a few MRTG graphs, got RRDtool working with MRTG and figured out how to get graphs to print out. Most of the graphing tools out there for RRDtool suck, it's just better to use the grapher that's built in, pipe the output thru stdout and passthru() in PHP. It's quite simple, actually. If you would like to see the results, view them at My Status Page.

Yesterday I went and splurged on a few air tools for the air compressor that my brother bequeathed unto me because he's consolidating two households, and doesn't need it anymore. It's a nice little 220 air compressor. One thing I didn't get, and wish I had, is a blower attachment. No matter. I am almost done with the prototype CNC controller, all I need to do is put in a power switch and test it out.

Today the family is coming over for my housewarming. This house has absorbed many of my hours, and hopefully I can consider it presentable now. The CNC controller prototype card arrived yesterday. I will see if I can slip away for a while and solder on it a bit, but considering current events, I prolly won't get any time at all. I found a really good article on the net about prototyping boards in the garage using the photoprocess that I was trying before... However, I was getting worthless results, and this article discusses many of the problems I was having, and what to do to keep those problems from happening. Here's the link to the article. Have fun.

Recently I have been digging ditches in the back yard and installing drainage. It's not fun work, but at least I don't have to deal with having a few swimming pools for two to three weeks every time it rains. Im also working on getting my CNC controller finished up, since it may bring in some revenue. I am considering setting up servers for businesses on the side as well.

I haven't posted anything on my blog in a while because I am working on a "secret project" which should sell like hotcakes. This device is a "novelty set-top box" which will bridge the gap between yesterday's NTSC and tomorrow's ATSC television formats. The novelty of this box is what's secret, there are a hundred companies making set-top boxes, but none are making anything like what I am making. Anyways, I have made a few strategic partnerships with corporations that make certain components, but one corporation has me befuddled.

Zoran Corporation seems to not be interested in selling their product. Why would a corporation not be interested in selling their product? I am stumped. I discussed this topic with a sales representative over the phone, and she said she'll get somebody else to call me and tell me... She states "certain reasons" for not wanting to sell chips or divulge data about these chips. I doubt I'll hear from them again. I wonder, however, where a multinational corporation gets money to design chips if they're uninterested in selling them. Perhaps they have not successfully designed these chips, and are generating market hype in an attempt to bring sales when they actually do have something to sell. Perhaps there are reasons that they do not wish to disclose. Regardless, I do not need their chip to create my product, and if they decide they do not wish to sell to me, then I'll be perfectly happy to tell their board of directors once I've sold my millionth unit about how their sales department is uninterested in making sales. I am sure I can get the necessary parts from any other chip manufacturer, like Texas Instruments or National Semiconductor, both of which offer datasheets on the Internet and samples are readily available. In fact, National will send you free samples, you don't even have to pay shipping. Zoran, you need to learn from the pros.

I decided to take some pictures of the IMU now that all the hardware is complete. The controller is not programmed yet, but I am sure you can't tell by looking at it. Anyways, here's a few pictures of the IMU.

Yesterday I finished all of the hardware for my IMU. Still need to put together the programmer, since I lagged for so long in ordering the card for that, I am now waiting on the card for an inordinate amount of time. I am really kicking myself for it, because I wanted to see the IMU working. On another note, I have been working on getting the IMU's firmware more or less USB compliant. I am still using the Vendor ID of a gentleman who was so kind as to purchase an ID and turn it into a "public experimentation ID." Considering the USB-IF charges for USB Vendor IDs, I cannot possibly imagine that organization being a "non profit" organization. To use the USB symbol, you have to pay two thousand US dollars per year!

Anyways, now I am spending more time on the Kalman filter, working out the matricies to rotate the gyro and accelerometer inputs. The internal representation for rotation that I decided to use is the quaternion. This is largely because it is easy to interpolate and doesn't have the sticky gimbal locking potential of Euler angles. Axis angle representation is very similar to quaternions, but I chose not to use axis angle mainly because I am much, much more familiar with quaternions.

I have been lagging on ordering a few cards. Primarily I want to make sure that those cards are 100% ready to be made, and have all the appropriate mounting holes, connections routed, and so forth. I am nearly done machining the case for the IMU, and it's coming out rather nicely. I'll have to do some sanding and polishing, but right now, it's looking quite nice. I'm going to have to break away at some point and get some screws for mounting the main board and lids. I also have to machine the lids for the card compartments.

Yesterday I took my mill down to parade rest, oiled it, applied Locktite in the appropriate places and replaced a backlash nut that decided to drop its threads. I also got a bunch of stock plastic from Ridout Plastics for IMU cases. I went to Fry's and picked up the last two male DB-25 right angle PC mount plugs... I was hoping to stock up.

Anyway, I figured I should set up a forum for this tech blog, and see if anybody out there is communicating. I'll post the link to the forum once I get all the little configuration settings worked out.

On another note, I've been warming up the old 68k Core Wars project. In this project, I am setting up a hardware implementation of a computer "core" which will be contested by two 68k processors. The name of the game is to make the other processor run an illegal instruction or somehow trap. There is a rather popular game Core Wars which uses a virtual system with rather unrealistic architecture to stage your program's fight. Since playing that game for the first time, I have always wanted to play it on a real-life hardware implementation.

Well, I had a job interview yesterday. Can't say it went so well; the second person that I talked to asked me why I wanted to stop working contracts. This was well after she asked me why I wanted to work for her company. I think she was fishing for an answer that would disqualify me. She seemed like she was more interested in hiring somebody more qualified to be her date than underling. Anyways, the sentiment she wanted me to emote was one of "I would be happy to work for you guys for free." I honestly wonder what kind of jackanapes would look for a job with an express disinterest in getting paid. This little lady told me, "being able to pay your rent is a luxury." Well, having Rob work for you is also a luxury. If I don't get the luxury of paying my bills, then you don't get the luxury of me working for you, and that's that. I am a "workaholic" and enjoy what I do. I will put in those long hours that other people won't, but not when bills are stacking up and paychecks are a long departed memory.

Today I drilled some holes for mounting a new vice like device on my mill. This will hopefully allow me to square off the ends of this block of plastic I have, thus allowing me to finish my IMU case. In other news, I have been lazy ordering parts for the programmer mainly because all of my psych-energy has been focused upon a potential job opportunity. What's really nice about this job op, it doesn't threaten my robotics, and even better, I will probably be able to see my GameTorrent project through. On a completely different note, my pictures from Peru are sitting in a directory, waiting to be put on a web page. In a few short moments, they should be here.

Over the course of the week, I discovered that my programmer that I constructed was not well equipped to do the mode of entry into ICC that the 72F62 needs. My IMU programming isn't going to happen until I get a different programmer put together. I could buy one from ST, but what fun is that? ... and they're bloody expensive to boot. So I spent the week drawing up a new programmer.

Well, what do you know, when I finally go to load the pictures from the cards to the computer, something decided to stop working, and now I have to go get a card reader or new USB cable to be able to upload my cards to all you wonderful viewers. No big deal. Anyways, I've programmed a lid maker to make lids for the wonderful circuit card cavities that my mill can produce. I have already made lids for both the gyro cavities, but I'm having trouble milling the mainboad's lid- the plastic keeps coming unglued from the mounting block while I'm milling it. I am also looking for a quick and easy way of squaring up a block of plastic. I would do it on my mill, but the mill isn't big enough to fit the block and the vice necessary to clamp it straight.

I am back from Peru, and with loads of pictures, mosquito bites, yellow fever and alpaca skins and knits. Well, maybe not yellow fever, but the trip was fun. I've been lazy in posting these pictures, since I wouldn't mind putting some story behind some of these pictures, especially since this was an experience for me and merely a stack of pictures to show for it.

Anyways, I have hopefully completed the ST7 ICC programmer card, and will test it as soon as I get the courage. I hate it when an expensive circuit card doesn't work, but it seems to happen less often with more experience.

I haven't written here in a little while, mainly because I have been busy with brewing a mead, finishing the programmer design and whatnot. I have also been balancing the needs of gathering goods for the upcoming Peru trip, which begins tomorrow. I will be computerless until the 25th or so. When I return, I may not be feeling like logging right on... depends. I will have the programmer ready to solder up, and plenty of other stuff that needs doing. I have hogged out the mainboard cavity and a gyro cavity on a piece of acyrlic, but it's a little out of square on one end and really out of square on the other, so I'm working on some way of squaring up this block. It's a little too long to fit in the vice and be able to get over it with the tool. I'll figure something out.

Well, I am done soldering up the IMU. I have yet to complete the programmer, so I will not know if everything is functioning properly for a while. I have been slacking off for a number of reasons, however, because Real Life has interrupted my daily function. For one, my car battery decided it would eat my clutch hydraulic line for lunch. Also, I have been hot on the job hunt mainly since I got this fancy new resume and wanted to test it out.

Right now I am waiting on a few parts that I ran out of when I was assembling the IMU. I dunno why I'd ordered so few 10k resistor, I also don't know why I didn't order 1.5k resistors, or 1k resistors. I decided since these were rather popular resistors, to order a good number of them. I am slacking on making the programmer. I was hoping I could buy one, but apparently the only programmers that are available on the cheap are not friendly to my specific chip. Anyways, I will have to get cracking on that schematic today, perhaps I'll have a board designed by the end of the week, and can solder it by the end of next week.

That same friend of mine asked me where I learned all this neato stuff. I studied Computer Science in the University, and got my degree. That does not explain, however, my technical expertise, since I was pretty much more knowledgeable than the profs. I have always been a programmer. I was born with a Motorola 68k in my mouth. But I learned electronics through the Navy. The Navy has a wonderful set of books that anybody can read called NEETS, or the Navy Electrical and Electronic Training Series. I found a site that posts these as PDF files for free download. There was another site that offers these PDF files for well over fifty bucks each, but that site is not worth mention, considering the fact that one would have to invest well over a thousand bucks to get the whole series. Bill O'Really, there's your most rediculous item of my day.

Today, I decided to take a few pictures of my shop for you. Click on these to see them in full size.

These are the tools of the trade for assembling small boards in your garage. The microscope, tweezers, solder syringe and a toaster oven.

This is my workbench, including the aforementioned tools, as well as my O-scopes, milling computer, and my mill which I keep inside a cardboard box to keep the chips out of my bedroom carpet.

This is a closeup of my IMU mainboard. It isn't completely soldered together, I still have some components on order and I also haven't soldered on the ADCs and processor.

I have been working hard at getting my home ready for a party with a number of distinguished guests, and also have been dealing with such things like getting my resume rewritten by a person more qualified for the task than I. Along with all that, my new IMU mainboard came in. So I also spent a great deal of time soldering the parts together. I use a toaster oven reflow technique on boards with small components, like this IMU mainboard, since a hot air gun will blow these components all over the place. I also would like to draw your attention to this little PDF file I found on the net, which came from the makers of the gyros that I am using. This document discusses a lot of interesting information regarding the composition of passive components, and what that means to the accuracy of your circuit designs. I also would like to draw attention to Mouser Electronics, the vendor that I use for all of my electronics needs. They have a wonderful variety of surface mount devices, including literally hundreds of thousands of different types of passive components. Their site also cross refrences obsolete parts so you don't have to do too much homework.

I found out why my gyro card didn't work. I forgot to wire up the ground connection to the charge pump. DOH! What gets me is that the gyro card is a verbatim copy of what's on the gyro datasheet, so I really don't know how in the world I missed it. I made the same error on my IMU main board. Since I ordered breakout boards for the gyro cards, I already have the gyro cards coming in with error fixed, but I'll have to get a new main board made. Such is the prototyping process... Unfortunately, it'll cost me a few days. I still have to make the programmer for the microcontroller on the main board, so I think the time will be well spent.

On another note, I have sent an email off to Blizzard regarding my innovative technique for making connections through a firewall. Blizzard does all of the updates for their games via a torrent type download, but seeing that most people on the Internet are protected by firewalls, their downloader tends to be incredibly slow, just like any torrent downloader when firewalls are used. The problem is the double firewall issue... If two computers wish to connect to each other, and they are both protected by firewalls, it is supposedly impossible for the two of them to connect. So to establish connections in the torrent, these two computers have to seek non firewalled connections, which are quite often dialup connections.

In our Computer Science final project, my partner, Juan Delgado, and I worked out a technique for breaking through firewalls when doing a torrent download. This technique does require the complicity of both of the computers, so therefore it does not break the security of the firewall. We discovered this technique first for UDP, then worked out the details for making it work in TCP. It's a rather novel technique, but out of fear of having it pulled from under me, I will not relinquish any details.

Yesterday, I tried to solder a gyro onto a dinky little gyro card... And had some pads lift when I tried to remove the gyro. It didn't work, perhaps because something shorted out. The gyro that I chose was an Analog Devices ADXRS401 and I didn't use enough flux to solder it. Being that it's a BGA chip, I can't tell what I did wrong. But, in the process I found some wonderful little breakout boards which are a good deal smaller than the gyro cards which I had made at Advanced Circuits. They have a lower limit on card size, so I was restricted to 1.25" square cards, minimum. So anyways, I need to see if I can solder, properly, one gyro now... And that's on my IMU's main board. I have to redesign how my IMU's axes are going to be aligned, since these new gyro breakout boards do not have any holes for mounting, so I'll probably have to somehow clamp these gyro cards, or carefully drill holes.

I have been helping my wife's office liquidate by wiping all of the computers that they are going to be disposing of. I've been slacking on soldering up my IMU's circuit boards, and was hoping I'd be able to do that this week... Probably not going to happen.

Today I decided to start a technical web log because of a few reasons. First, I need some outlet for all this wonderful information that I sift through every day. In any case where I may need this information in the future, I can sift through my blog... hopefully I'll be able to find what I'm looking for. The second reason I have is the fact that there's so much theoretical information on the Kalman filter, my current field of study, yet there is so little implementation detail... Sometimes I wonder if those people who write about Kalman filters do so because they can't seem to get it together enough to implement one. About the best Kalman Filter example implementations that I have seen lack some of the most basic error filtering, I have yet to see an example that handles bias or scale error.

Today, I am going to start things off with a few excellent sources, and finish things off with a quick and dirty description of how to implement bias and scale adjustment in the Kalman filter. Further derivatives are left as an exercise for the reader, however, they should be very obvious once bias and scale are understood.

1) My first go-to book is by Grewal, Weill and Andrews, called Global Positioning Systems, Inertial Navigation, and Integration ISBN 0471-35032-X. This book is quite excellent, although, just like everything else out there, it's fat on theory and quite thin on implementation details.

2) My second go-to book is a PDF file by Alonzo Kelly called A 3D State Space Formulation of a Navigation Kalman Filter for Autonomous Vehicles which is Carnegie Mellon University publication CMU-RI-TR-94-19 and can be found HERE.

3) A paper worthy of note, which contains a good example of a basic Kalman filter implementation is by Greg Welch and Gary Bishop called An Introduction to the Kalman Filter and can be found HERE.

While digging through my papers, I found documentation for the SourceForge implementation of the Kalman filter library. I highly suggest you look at the documentation for implementation ideas, but leave the code on SourceForge. It may be a free software implementation, but you really do get what you pay for in this case. This implementation does a lot of funky stuff with the matricies you input, but even worse, the matrix classes have absolutely no linear algebra functions! That's right, all of the matrix operations are written out "by hand" each time they are needed, making the code overbearingly lengthy. I say again, do not use the SourceForge implementation.

Ok, I hope you have taken the time to read the publications about the Kalman filter, because I'm not here to rewrite them. I did promise, however, to tell you how to make bias and scale adjustments. In the measurement update matrix, usually called "H" there are elements which transform state variables into simulated sensor inputs. In the aforementioned publications [1] and [2], there's a little said about "state vector augmentation" which is cryptic and not terribly enlightening. This is how it is used. You create a state vector entry for each sensor's bias and scale values. To affect a bias adjustment, the H matrix should have a 1 inserted in the field which equates the sensor to the bias entry in the state vector. To affect a scale adjustment, the H matrix should have the value which depends upon the sensor put in the place which equates the sensor to the scale entry in the state vector. How it works is simple. Suppose this is an accelerometer which we can assume is on a stable platform or is somehow fixed so it doesn't need to be rotated or transformed in the filter. Other sensors, GPS for example, are "clamping" the actual acceleration state, so strangely enough the bias value will bleed into this bias state. The scale adjustment is somewhat more contrived. Recall that the Kalman filter actually takes the state variables, transforms them by H to get the supposed sensor reading, then compares it with the actual sensor reading. The state variable for scale, when multiplied by the actual output value, should give you the sensor's reading. Now, in an inertial navigations setting, the scale value should be a 3x3 matrix which accounts not only for scale, but input axis misalignment as well. Adjusting for input axis misalignment may be described at a later date... I'm not sure.