Robotics - Attach It

The robotics team continues to be short on attendance and supplies. We're still waiting to 3D-print some important piece, but we did our best to attach the ball input belt to the robot base. Since it's diagonal, we found some L brackets and bent them to produce the appropriate angle. It turned out that [1] it's hard to bend things with pliers and stop them from just arcing and [2] we didn't actually need to destroy those L brackets. 

I suggested that we take advantage of the metal channels with 8 holes around each attachment point and simply rotate one by 45 degrees and screw it in. That would have worked, but the corner of the channel hit the channel below it. running parallel to the floor. We then discovered some short flat pieces (that were bent up for some reason), which I hammered into straightness. The attachment was then a success. It was a challenge aligning the other side, but we (down to 2 people at this point in the meeting) got it standing up and stable enough.

Robotics - Have Design

On Saturday, some members of the robotics team - not including me - went to the Putnam (local museum) machine shop to work on the robot's mission-critical parts. From what I hear, they designed and 3D-printed some things, but the printer (or possibly the CAD operator) experienced some issues and produced unusable parts. They did, however, successfully produce a design sketch for our robot.

We're still waiting on some parts, but we did do some tinkering with the robot base. The battery and motor controllers have been mounted to the new design's base and wired up. I'm waiting for the builders to mount the NXT so I can start programming the basic autonomous routine.

I tested the software-geared drive program on the other team's robot, and it worked pretty OK, but they ran out of battery. While I waited for things to happen, I continued to show the new programming assistant (who is very good with CAD) Robot-C programming concepts, using the complicated geared drive program as a real-world example.

Windows App Paths

Some people might know about this already, but it's a cool detail of Windows that I found fascinating. Pretty much everybody knows you can type program file names into the Run dialog and have them appear, and you can add directories to the PATH environment variable to make the Run dialog search those places if you don't supply a path.

But, some applications can launch even if their executable is not on the PATH. This is through a feature called App Paths. It is a registry key that maps executable file names (non-qualified) to full paths and provides their initial directory.

There are two instances of it, one under HKLM and another under HKCU, for everyone and the current user, respectively. You can find it at HK??\Software\Microsoft\Windows\CurrentVersion\AppPaths. Each subkey is the name of a program you can type at the Run dialog.

The default value of each key is the full path to the executable. (It doesn't even have to have the same file name as the unqualified name!) The Path value provides the initial directory. There seem to be some other properties that can be set, like UseURL and BlockOnTSNonInstallMode, but I'm not entirely sure what they do.

FMod - All the Sound

It has come to my attention that there is actually a demand for the ability to import and export all the Keen:Galaxy sounds, not just the music. In fact, the final episode of the unofficial TUIT trilogy has all-new AdLib sounds.

So, I made a good effort today to add that functionality to Abiathar. Now, Abiathar isn't intended (at this stage) to be an amazing sound editor; just dumping the sound files out and sucking them back is all I need to do. The UI is, therefore, simple. The Audio Files menu item is now a submenu with items of its own: Resources, Export, and Import. (Resources produces the Audio Files dialog.) Those new entries simply create the save-file and open-file dialogs, respectively. Those dialogs set the list file, which binds all the sound files together (holds references to their filenames and chunk IDs). The individual sound files are spewed out in the directory of the sound list file, which can be placed anywhere.

It works well: I successfully round-tripped the Keen 4 audio resources. All the metadata of the sounds (e.g. priority, OPL instrument settings) are stored in the list file on the line representing the appropriate sound. It turns out that this is not how KeenWave did it - KeenWave just takes the chunks and dumps them out without any processing, header and all. I will add a config option to produce this behavior, probably making it the default.

Since Abiathar's patch generator is becoming increasingly important, serious modders might start using it. Therefore, there should be a convenient way to add user-defined patches that Abiathar doesn't have to understand. For that, I created the Patches dialog, which presents a text box bound to a string array in the project file, integrated by the patch generator into the outputted patch file. There is a notice above the field informing the user the Abiathar handles the header/footer, map header, tileinfo, graphics files, audio files, and music mappings.

Robotics - Ball Input

We were reminded at today's robotics meeting that there are less than two weeks left before the first qualifying match we want to attend - and we don't even have a driving robot yet. Today, we continued our efforts to remedy that.

After the pep talk, I opened up the RobotC IDE and started teaching a new member of the team (previously on a different, non-school team) robot programming. She has never done any CS or development work, but she seems to be getting it. I think the idea of having her on the team is for her to be my assistant, but I don't really need any assistance. I'll try to continue teaching her things throughout the season.

Since having a Samantha module is very important to making the robot move, I dug out the one that wasn't working and tried again. For some reason, it worked today with the same flash drive I had tried before. Whatever the problem was, it's fixed, and we have remote communication with the robot. I wrote a tiny test program (while teaching the new recruit) that runs the first motor.

That was used to test the engineering team's almost-production-ready prototype for the ball input chute. It consists of a belt with rotating spokes in a tube. They were tinkering with it for most of the practice, and it seems to work very well now. Setting up the drive motors will be trivial; the remaining challenges are to get a good autonomous program and to actually put the balls in the high tubes.

Crushers - v2.5

Crushers 2.5 is here! I made all the changes I discussed in a post a few days ago and a few more. Essentially all bugs have been fixed. I think the most distinguishing feature of this update is the adaptation to widescreen - this is the first game of mine to have that update.

Download Crushers 2.5 (EXE: 4.3 MB)

Robotics - Cleaned Up

Though I wasn't at the robotics meeting on Saturday, it seems the teams were fairly productive. When I arrived, I found that the parts room had been cleared of all the miscellaneous junk everywhere; everything is now actually in a place that makes sense, near similar things. A robot frame had been constructed with a motor or two. More interestingly, though, there was an almost-production-grade prototype for ball input device.

Today, people worked on the battery mount. (At least, that was what happened in the short time I could be at the meeting. I had to go do another thing for a good deal of the time.) This is important because we have historically had issues with the battery getting jostled and disconnected. I made some adjustments to the software gearing code, but did not get a chance to test them.