Robot Odyssey: Minefields

 

I've been saving the hardest challenge on this floor for last - not just because it's intimidating, but also because I'm counting on being able to retrieve the minesweeper bot from the MCC once this last puzzle is solved, and not risk having it wander back into the minefield and get blown up while solving another one.

The task - get a robot through the minefield and into the MCC, where it will press the final switch and shut down the master computer. You can't enter the minefield yourself; it must be controlled remotely, and blindly.

The minefield map, which you can enter, marks the location of the mines. A controller bot could be programmed to navigate it and transmit directions to the minesweeper bot, so that both move through their respective mazes in sync, but there are two major problems.

First, the only means of transmitting anything from one bot to another is by wireless antennae signal, which can only be turned on or off. Instructions can only be binary, and we need at least three (right, down, and up). This is, of course, a real-world engineering problem; non-binary information is encoded and transmitted into serial bits all the time. There are some ways this could be solved, none of them easy.

Second, these circuits lag, and the more logic gates I add to a critical path, the more it lags. If the controller bot and minesweeper bot are both moving to the right in perfect harmony, and the controller bumps into a wall and transmits a signal, the minesweeper bot will keep going right and blow itself up before it can receive the signal and understand it to mean "stop." This problem seems the thornier one.

Diagram by Notre Dame University

 

In the real world, the problem of sending non-binary data over a single-bit channel is typically solved with a serial protocol, which at the minimum requires a start bit followed by N data bits and M stop bits. A transcoder for octal packets may begin with a brief pulse to signal the start, then over the next 3T milliseconds send up to three more pulses for the binary representation of the octal input, and then no pulses for the next 2T milliseconds. The receiver is woken up from idle state by the pulse and as soon as the pulse ends, listens for pulses over the next 5T milliseconds to read five bits. If the two stop bits match the protocol's stop value, then the three data bits are read in as an octal number. If they don't, then something went wrong and the packet can't be trusted.

I'm sure that this is doable in Robot Odyssey with the tools given, and perhaps the stop bits aren't  necessary. But I quickly gave up the notion of trying to solve the minefield problem this way. In the real world, even with 1980's technology, an 8-bit packet is transmitted in milliseconds. In Robot Odyssey's world, everything operates in 125ms ticks. Each wire added, each gate traversed, each time interval awaited is another eight of a second or more. The whole mechanism, under the most perfectly optimized circumstances, would probably take more than a second to encode, transmit, decode, and act on a 2-bit trinary packet. And that's just no good for this task - the robots would desync badly.

But I had another thought. The control robot doesn't have to solve the maze with logic. I can be there in the maproom with it and guide it with a manual control, such as placing/removing a crystal in proximity of its sensors. A manual binary input can be transmitted to the sweeper bot with minimal lag, and as long as both robots are wired the same, they should move through their respective zones in close synchronicity.

A binary input can be translated into motion directions by cycling through states, which can be accomplished with the "count-to-N" chip. Wiring the sixth pin to its own reset input makes it cyclical, and I decided on the following states:

• Stop
• Right
• Up
• Stop
• Right
• Down

 

I wire up Sparky accordingly:

 

A test run to see if I can guide Sparky through the map room quickly reveals a problem. Even with this simple wiring scheme, Sparky lags! This isn't necessarily a showstopping problem - I can expect both Sparky and Scanner to lag together, but it does mean I have to time the input to trigger state advancement all the more carefully. Finessing the actual keyboard inputs to manage Sparky's state, even as the Apple II itself chugs along at 4-5 frames per second (and polls the keyboard as often) is no picnic, especially when I need to move the crystal from one room to another and quickly drop it to change Sparky's state.

I try a different state cycle:

• Stop
• Right
• Stop
• Up
• Stop
• Down

 

 

This navigates the maze less efficiently, but it's a bit easier to work with, as Sparky stops moving with every other state change, giving me a chance to rest and calculate my next move. Nevertheless, it takes me several tries to get through a successful test run that doesn't do worse than lightly brush the walls.

Time for the real test. I wire up Scanner with another count-to-n chip, driven by Sparky's antennae to switch states, and place him right by the minefield entrance. I return to Sparky and begin guiding him through exceedingly carefully, as I had before. The absence of any kaboom sound as I do this gives me some confidence.

Sparky's halfway through.

Checking on Scanner via computer room monitor

Made it through!

Scanner didn't quite hit the button, but no big deal - just have to use the crystal-sensor remote one last time.

And the level is all but solved. Checkers and Scanner are free, a fourth robot is released - I'll name her Iris, and the master computer is deactivated. Way to go!

Iris's batteries are super dead, so I recharge them with a crystal, and recharge the crystal from the charging station in the high voltage room below. Scanner's running low too, but I just let all of the robots run until they drain completely so I can recharge them. It takes a good 25 minutes for them all to run dry, but you can't recharge a battery until it's empty.

In the level's exit, the elevator room, the doors no longer close, and the magnet in the corner doesn't react to mine, so now I'm not even sure what the point of the magnet is. For now, I save and take the one-way teleporter to the final area of Robotropolis - the skyways.