Configuring postfix is well-known to be the hardest, least intellectually stimulating task any IT person will ever pass off to a hapless subordinate. I, unfortunately, would seem to be that hapless subordinate. Eric recommended (and, in fact, convinced me) that I write a perl script to act as a delivery agent for postfix. This would offer grate flexibility, customizability, blah, blah, blah. Not to drag out the story, I got to a point where I realized I had a 200 line mess that didn’t work half of the time, wasn’t properly interacting with postfix, and needed another 1000 or so lines to do what was really required of it. So I dropped the project, and fell back to using mysql aliases, which looked to me like the easiest option when I need relatively dynamic mailing lists integrating with custom software that uses mysql.
Read the rest of this entry »FIRSTSearch Released
Oct 16
After various delays of the server-is-down sort, I’ve finally finished fixing the indexing software, and FIRSTSearch is ready for (beta) release. It’s by no means an incredible piece of software – it has some bugs, it wants some features, the display of results is less than perfect, and I have my doubts that it’s really finding the most relevant results. But it’s working, and it’s ready forr other people to start to use.
I expect to have a non-beta release within a few weeks.
Demonstrations Day
Oct 1
From an initial glance, it appears more new members came today than last week. Though that does help the team, the room’s limited space fits only so many people. Mechanics demonstrations such as tapping and sawing took place in the main room while Eric instructed inventor to veterans in the computer room. Scott and his tech crew were in the backroom as usual. But, the Labview introduction transpired in the hallways with Winifred resting on top of a recycle bin (Well, it IS getting old and slow). Since Daniel was out sick, Jacob had to improvise on the tutorial. It seemed the flu got to him though as he was more calm than usual. Maybe he should have gotten a cookie.
In the third after-school robotics meeting of the year, I ventured into that frightening and mysterious land of operating system development. It’s the hardest thing you’ll ever fail to do – and I started it while listening suggestions for the name of this OS. I think Freddy ultimately decided on “Sloth”. Great day. Interestingly enough, the only hard-core programmer who I told about this project who did not inform me that it would be an utter failure was also the only person I know who has ever worked on writing his own OS (although it wasn’t very successfull). So I’m hopeful – probably more so than I have a right to be.
Briefly, I can now start up the computer and print an ‘A’ to the screen. That means that I can claim to be 3 months ahead of schedule, since I wasn’t planning on starting this project until early January (I got bored). Of course, when I tried to print an ‘A’ to the second line, I got a blue rectangle instead. But hey, that’s pretty cool too!
Now for the long story. Walking in today, I had made progress: I had acquired several computers to be used for this project and some other (all the meantime fighting back the greed of my bosses, who actually wanted to use them for things that were – god forbid – practical *shudder*), I had acquired a floppy disk on which to write the OS, and… well yeah, that’s about it. I also knew nothing about how to write an OS.
First, I set up grub. It turned out to be pretty simple. Next, I started figuring out how to write the OS to the disk (no, I didn’t have an OS yet – did I mention that I’ve never done this before?). At this point, Freddy pointed out that I could just store the file on the hard drive, and have grub read it. Oh. Right. Thanks. And I spent 45 minutes acquiring that floppy disk why?
Next I went to my favorite wiki, and looked up the boilerplate OS code. Pretty simple, so I copied it onto qweffor and ran it. Well, actually, I told qweffor to reboot, but I was logged on via SSH, so I had to walk over to the room with qweffor in order to watch what was happening. Freddy had already started up the right OS. So, yeah, it had printed out an ‘A’. Grub had also printed out some stuff. I specified that grub should be ‘quiet’, and retried, but that didn’t fix it. So I got a message like:
Aooting from (hd0,0)...
I decided to let that message appear, and print out the rest of the stuff to the following lines. So instead of just setting the first character to be ‘A’, I set it to be a newline, and set the second character to be ‘A’. Result: a blue square with a white circle in the middle. Then I had to catch my bus.
Result: its time to actually read the documentation. And for those of you who were planning to look on, you didn’t miss much.
Oh, and today was the first day of training for freshmen. Not that that’s unimportant, but it was somewhat less than exciting…
I recently completed a manual migration of my data for CTDA (an analysis system for team data collected from thebluealliance.net and other sources) to PostgreSQL from MySQL (see my comparison for why). By ‘manual’, I do not mean that I typed the data in by hand – I mean that for each table, I wrote a separate script to transfer the data, instead of writing (or finding online) a single script to copy a whole database. My advice to you, if you are planning to migrate data to PostgreSQL from MySQL, is this: don’t do it by hand.
Let’s assume I would have been unable to find a workable script online to transfer the database for me. This is unlikely at best, but if I couldn’t, I could probably have written one that would cover all the cases needed for my database in about 3 or 4 hours (I’m rather new to postgres). So I sit down one day, write the script, test it a bit, and set it to run overnight, and I’m done.
But that’s not what I did. I decided that it would be ‘easier’ to write a script for each table. Perhaps it saved me some thinking – but the process ended up taking me two weeks, and much more than 4 hours. I would estimate that, because of this delay, CTDA will be released 3 weeks later than it would have been if I had written a good script to do this for me.
Oh, and in case you can’t guess. My advice to those who are planning to migrate from PostgreSQL to MySQL: don’t.
With the internal controversy surrounding 449’s attendance at the Battle o’ Baltimore, I’m glad to say that we did in fact attend. Summer events are always hard, with most people on vacation or simply not motivated enough to make the 45 minute drive from DC to Baltimore.
The goal of this offseason event was to give the younger members of our team—the rising juniors and sophomores—a jump start into running the robot without us old farts. The power’s been in our hands too long, and we’ve gotten too comfortable being in control. The drive chain is loose? Not my problem. Here, have a wrench. It might not be the right size. Engineers have got to fend for themselves in the wild world of robotics.
After looking into migrating to PostgreSQL, which seems to be a popular pastime among database people (migrating, not looking into), I decided to do my own benchmarks. Here are the results of the simple ones (I have yet to code the complex ones). I wrote all the code in perl, and ran it on quentin. I use InnoDB for mysql, with defaults, and everything default on postgres.
Read the rest of this entry »I’ve been touring colleges in the North East for a few days now, and, amazingly, FIRST and related things seem to pop up at the most unexpected times!
At Rochester Institute of Technology, I was looking through the list of merit scholarships when one in particular caught my eye. The FIRST Robotics scholarship at RIT awards $6,000 a year simply for being on a FIRST team in high school. I.e., you could come in with a 2.0 GPA (unlikely) to study English (also unlikely), but so long as you were on a FIRST team in high school, you are eligible for this scholarship.
I want to give a shout-out to team 424, whose captain I met today at Cornell. He guessed I was on a FIRST team by my team T-shirt (I somehow accumulated 3 of them this year, so I’m wearing them to most of the bigger name colleges I’m visiting).
In an engineering building at Cornell, there was a display of mechanical devices. One of which was a model of a gyroscope, which had a caption that puts to rest once and for all whether a reaction wheel is more effective than a gyroscope: “…reaction wheels, apply torque simply by changing the rotor spin speed, but CMG (fancy acronym for gyropscope) are far more power efficient. For a few hundred Watts and about 100 kg of mass, llarge CMGs have produced thousands of Nm of torque, enough to flip over an SUV. A reaction wheel of similar capability would require megawatts of power.
Finally, in a nearby hall, I spotted more or less our cart design, except actually fabricated! That’s right, a group at Cornell built a crab drive cart that carries land mine detection equipment. Needless to say, I took plenty of pictures for later review.
I’ll be back sometime after Battle o’ Baltimore. Who knows how many more times I’ll see FIRST related things before then!
“If this explodes, we’re going to have video of your epic demise.”
So commented one team member on my attempt to run a CIM motor off an 18v drill battery using 22 guage wire.
Such was the atmosphere at our third summer meeting, hosted at my house, in preparation for the Battle o’ Baltimore. Our main goal was to replace the robot’s sub-par shooter with a simple hopper and roller with which to “dump” orbit balls.
The dumper design was considered during competition season and mostly built (as our witholding allowance) but was scrapped in favor of a catapult. We thought it would be a good idea to give it try at the Battle. After negotiating our way into the backroom at school, we collected the dumper scraps so the dumper could have a second chance at life. Disassembling the shooter was done quickly, and resurrecting the dumper was not difficult. 80% of the work was completed the first day.
The four people who decided they didn’t want to go home for the night slept with the robot in the basement. We were back at work 10 AM Sunday morning. A few bent pieces of flat stock and more than a few zipties later, the dumper was in working condition. For the rest of the day, the hum of tools and robot work was accompanied by the clatter of pool balls and sharp pings of air hockey pucks. A few mechanical bugs were worked out, which entailed a new gearbox and mounting plate. Some minor adjustments ensured that our rear wheel chain would stop ejecting itself.
Most students floated between game-playing and robot-building, but some chose to work on other projects. The fate of the programming subteam was discussed at length, and design work was done on the rumored “arm” that will be the pinnacle of our training program. Some people even found time to cut the pieces for a second modular battery charger.
While the bulk of the work is over, we will be meeting here again this Saturday. This time, the focus will be on the robotic arm and offseason projects, as well as some administrative work for the upcoming school year.
And just so you stop wondering, my ad-hoc wiring job didn’t explode.
Ferocious Zip Ties
Aug 4
WARNING: Never hold a zip tie by its tail (the long, flat end) and use it like a whip to hit someone with the head (the square end that you can feed the tail through).
This happened to me on Sunday where, upon arriving, I was attacked by a bored freshman sophomore. It kind of stung, but I didn’t think anything of it… until I started trying to work on planning pre-season lessons. That’s when I noticed my hand was bleeding in several places (5, to be precise). I had to go upstairs to have Eric’s mom put some antiseptic on my hand (I don’t trust sophomore boys to keep their hands clean. Heck, I don’t trust me to keep my hands clean).
Needless to say, I was kind of pissed.
On the plus side, I managed to work with Daniel to get most of the training schedule for next year set. We have 12 days this year, up from 9 last year (just how school scheduling works out) (hooray!).
Training this year is going to be a LOT more hands on than last year. Half the sessions are reserved for hands on practice, including wiring and programming a robotic arm and building a set of drive trains. Hopefully everyone will come out of training ready to head straight into Build Season (or at the very least, know the difference between a bolt and a nut).
