Sunday, December 7, 2014

Looking at Strings with VMMap

As I was perusing the Windows Sysinternals Administrator's Reference, I learned about VMMap, a Sysinternals utility that inspects the memory allocations of a running process. One of its features is the Strings dialog, which presents a list of all the text strings (including Unicode) it could find in the loaded images (e.g. EXE, DLL). You can scroll through the list to discover all the things the program could say or think about, like error messages or parseable commands.

I used it on Abiathar and was very interested by the groupings of the texts. It seems the .NET compiler places string literals from the same methods and classes together for the most part. All the possible splash screen messages were together starting at 0x0037BAD8 in the executable file, 0x0086D6D8 in the process address space (but that might move around, I'm not sure). It also sees the strings compiled into the programs and files embedded in Abiathar, like the KeenGraph executable and the game maps files. The .NET compiler seems to write the names of all the methods, even if they're declared Private.
Some strings in Abiathar, from the Level Inspector subroutine
You can download the Sysinternals Suite from its Microsoft TechNet subsite.

Saturday, December 6, 2014

Setting up Network Policy and Access Services on Windows Server with One Network Interface

I had the pleasure of configuring the Network Policy and Access Services role on a Windows Server 2008 machine a while ago. I did run into a small problem: the machine has only one Ethernet port, and the configuration wizard for NPAS wants you to select two different interfaces, one Internet-facing and one internally-facing.

(It didn't help that the initial NPAS configuration wizard was really hard to find. You have to right-click the server icon under the NPAS role and choose "Configure and Set Up", not pick it from the Action menu.)

The solution is to choose the Custom role configuration in that first wizard page. All the other combinations of installed features will ask for two different interfaces. After choosing Custom, just tick the boxes for all the features you need. All your network interfaces (the single real one, any fake virtualized ones, the loopback one, and an "internal" one) will be automatically detected and added. All non-loopback and non-internal interfaces will support NPAS, so you might need to disable it on some if you don't want it messing with your virtual machines.

Friday, December 5, 2014

Robotics [MEET] - Competition Take II

Today was the second meet of the season, and we again didn't hold high hopes for our performance. Work continued on the cardboard ball routing tubes, but we didn't attach the servo to the box because we have no lift. We have no lift because the 3D printer that we left to run last night got jammed and failed to produce the linear bearings. What it did produce was a sheet of flat domino-like things that are entirely useless as any kind of bearing.

While tinkering and messing around, one engineer discovered that a crazy arrangement of screws, nuts, C braces, and a washer performs passably as a linear bearing when a similarly crazy assembly is stuck onto the end of the channels. He worked on putting that together over the course of the meet, but it was never attached.

Our first match (which was also the first match of the night) was a total disaster. Our NXT battery was critically low because the other team needed the full battery (that we had been using) to pass software inspection. They never gave it back to us. Somehow, the simple autonomous program (that just drives forward from the ramp) vanished from the NXT, so we ran the complicated IR-involved one despite starting on the ramp. Since one of the drive motors' wires had gotten loose, the robot turned at the start, falling sideways off the ramp rather than driving down it. It did fully leave the ramp, so we got the points! Unfortunately, that fall knocked out the other motor's cable, rendering us inoperable. Our alliance partner was trying to move the tubes, but without much success. When they tried to climb the ramp, they fell off the side, but since the side of their robot that went off the ramp fell onto our disabled robot, they were fully off the floor and got the points.

It was about this time when we noticed that the real field layout was reversed from our practice field. This inconvenient fact rendered our IR-smart autonomous program entirely useless.

Despite that, we tried using the program in our second match. By sheer luck, it got really close to the kickstand, but missed it. We helped our alliance partner push tubes up the ramp, but our acrylic number plate got jostled loose. One corner fell to the floor and got jammed in the squishy mat, rendering us unable to move forward and only allowing very slow backward movement. We managed to park in the parking zone.

We used that same autonomous routine again to get down from the ramp, and it worked since we had repaired the motor connections. We tried to move the tubes to the ramp, but jammed them all into the corner and also got a big penalty for pushing one through the opposing parking zone. We did extract one tube and started to push it up the ramp. Our robot just barely got up off the floor with a push from the alliance team.

In the fourth round, we just used the stationary musical autonomous program. We pushed several tubes up the ramp and ended the game teetering on the brink with one tube and our robot partially off the flat part of the ramp. The allied team very carefully parked in the parking zone.

Our fifth and final match was a huge jam. The allied team instructed us to play defense, so we did our best to block the opposing alliance from accessing their tubes. A flood of balls and the kicked-down kickstand tripped up our robot, and we got stuck near the opposing tubes. An opposing robot tried to drive through the mess and got stuck on top of one of our front wheels. Neither of us were able to move for the rest of the match.

Our performance here was not great. I think we won only one of our five matches (the second one). We did make some progress on the linear slide system, but our capabilities were largely unchanged from the first meet.

Thursday, December 4, 2014

Robotics - Material of Champions

The robot was being tinkered with the entire three hours of this meeting, so I didn't get a chance to improve the autonomous program. Most of my time this meeting was spent watching the tinkering (trying to understand what was going on) and watching/tinkering with the 3D printer in the other room. A team member with experience operating 3D printers did some good work repairing the printer. After removing the extrusion head from the acetone bath, it was much cleaner and could actually extrude.

We then entered a period of trial-and-error with the printer bed height that took at least an hour. We had to tighten and loosen some hex screws at the corners of the glass bed to tune the height and angle, then wait for the bed and extruder to heat up again. Along the way, we also discovered a kink in the filament routing area that was stopping much of the plastic from entering the extrusion head. After all the adjustments, the printer can print our sheet of linear bearings, which should be finished in the morning. (It takes a while.)

The major feature that our robot needs before it can be useful is a lift to elevate the balls we take to the tubes. We also need a place to store the balls, so we had to put into production the cardboard box of prototypeness. It works, but looked really out of place in all the metal machinery. The aesthetics were soon repaired: a ramp from the ball intake belt to the storage box was built out of cardboard and attached with zip ties. That's some quality engineering right there.

To control the outflow of balls, we added a servo flap to that box. This is our first servo, so we had to find and mount a servo controller. The mounting was easy enough, but powering it was a challenge; the only viable mounting place was far away from the battery and on the opposite side of the robot as the Samantha module (which has to be the last device in the power chain). Since we didn't want to send cables all around and redo our existing ball of wires, we ended up jamming two wires into one socket to create parallel circuits.

There is a meet tomorrow! We'll test the servo flap controls and do some general polishing then.

Wednesday, December 3, 2014

Robotics - 3D Debugging

At this extra-long robotics meeting, we spend most of the time tinkering with that 3D printer. With some clever use of Allen wrenches and screwdrivers, we disassembled the printing head and attempted to clean it. In doing so, we extracted a large chunk of failed extrusion stuck inside it. Several components require an acetone bath to become functional again, so we should have the printer online tomorrow!

The actual robot did receive some adjustments. Its wheel that fell off yesterday was reattached, as was the ball intake belt which fell apart. The divot-producing metal channel has been filed down so as to not damage the field.

I continued work on the autonomous, but the IR beacon's battery died and we didn't have a 9V battery laying around. We did eventually go down to the local hardware store and get one, but by then there was very little time left. I did some more testing of the routines we do have, and there is really no nice way to differentiate the center assembly positions from the current testing position.

Tuesday, December 2, 2014

Robotics - Continued Autonomous

At the previous meeting, we discovered that one small metal channel on the robot sticks down too far and causes problems when going down the ramp. (It actually made a divot in the floor mat!) We worked on filing it down, for lack of a better tool.

While others worked on that and tinkered with the partially-functioning 3D printer the AEA let us borrow, I continued working on the autonomous routine. It now does an excellent job of knocking down the kickstand in Position 3 thanks to better tuning of the turn time. I also started using the nicer HiTechnic IR Seeker 1200 drivers, so I can gain even deeper insight into the IR topology and make positional decisions based on that.

The program now checks whether the IR is in place for Position 3 before blindly going ahead and ramming a pole that might be there or might be a wall. I also added pathing and detection for Position 2. Unfortunately, the IR sensor occasionally produces the same value for Positions 3 and 2 from where I'm testing, so I may need to locate another testing spot. Both paths have been tested and work excellently. All that's left is to add pathing and detection for Position 1 and maybe rework the IR checking.

On Thursday, the good builders will both be there, so we can actually add hardware to the robot.

Monday, December 1, 2014

Robotics - Autonomous Time

No builders came to this robotics meeting, which made the extra length of it somewhat pointless. We started by trying to decide what to do for our linear bearings. The original idea was to 3D-print them, and we printed one, a prototype. It works perfectly, but no 3D printer owner in the area is willing to let us mass-produce them (we need at least 35 more) for free and soonish.

One option - which we started using as an experiment - is to use Sculpy, an interesting plastic-clay substance that is squishable until it's baked in an oven, at which point it becomes hard like plastic. The problems with this are that [1] we don't have enough Sculpy to make 35 more of these bearings and [2] we aren't nearly as accurate as a 3D printer, and accuracy is important (on the mm scale).

I started looking for online 3D print shops and discovered Shapeways. We determined that the cheapest material they'll use - sandstone (yes, you read that right, we can make robot parts out of sandstone) - will cost us $150 to print all the parts we need. If we use a decent material like plastic or metal, the price rapidly increases from $210.

We still haven't decided on our plan for that. While everybody else worked on Sculpy and our display board, I started working on our autonomous routine. At the first meet, all we could do was drive down from the ramp and play music. My current goal is to get it detecting the position of the kickstand and kicking it down.

After much testing, tweaking, and robotic destruction of the field, I got a routine starting in the parking zone, moving up to test for Position 3, spinning around, and utterly destroying that kickstand if it is in fact in Position 3. The infrared isn't hooked up to this program yet, but I did modify the tele-op program to play a tone indicating the value returned from the sensor (the angle of the emitter) at the press of a certain button. We did a bunch of driving around to verify that it is in fact working and help me figure out which infrared angles to use in the checks.