Part 78: Assignment #AC6: Sushi Robot!

Sushi Robot!

Barring potential further expansion, the last plate was bolted into place today! Avalon city is now at its target physical size.
Up until recently, Avalon City has been a city, but it's been missing a lot of things that people might except to find in one. Creature comforts, basically.

Now that the pressure's off on feeding the place and making it bigger, though, there's a bunch of people who've self-assigned to more 'quality of life' sorts of projects. This, as it happens, includes Derrick from the Ocean's Bounty team. He's come up with... well, take a look at this.












I was never much of one for sushi, but I can sink my teeth into this! This sounds like a fun project, and a good palate cleanser (ha) after that kelp harvesting robot. The actual design looks to be pretty simple - the 'sushi type' input value is passed directly to the 'fish' output, and the 'rice' output always takes the same output pattern. Add a RAM chip to queue orders, and this design should be in the bag. (On the plate, perhaps?)

One possibly tricky part: there is a time delay between generating the order and triggering the gate outputs - but it still doesn't seem like it'll make things that hard.

Time to get rolling 🍣 on the design!

[ ~ ]



   

 

This would have been a working design, but I made a mistake in reading the requirements - if you look at the screenshot, you'll see that all the 'gate' pulses for an order are being sent on the same time unit, 5 time units after the start of the associated 'rice' pulse. What's supposed to happen is that the 'gate-a' pulse is supposed to be sent then... and the 'gate-b' pulse is supposed to be sent 3 time units later, and the 'gate-c' pulse 3 time units after that. I'll have to redo the parts of the design that send the 'gate' pulses - but I'll explain what everything in this design does, first.

The main logic is actually performed by the center MC6000. It uses its p0 line to tell the MC6000 on the left (the input-handling MC) that it's ready to receive a new order. Once the input-handling MC responds with an order, the central MC sends the fish type to the fish-and-rice MC in the upper right. It then waits, sends the destination table number to the gate MCs in the lower right, and resets its p0 to tell the input MC it's ready for the next order.
The central MC also precalculates the output pulse for gate-a, which it sends to the gate MCs as part of the destination info.

The input-handling MC on the left (attached to the radio and the RAM chip) checks every time unit for incoming orders, recording them in the RAM chip. It uses its acc to keep track of the number of unfulfilled orders. If the simple input line from the central MC is on (indicating, readiness for the next order), and there's an order to send, the input MC will send the values from the RAM chip to the central MC, so that it can make the order.
The input MC uses one memory pointer to write orders, and the other to read orders out, so orders will always be processed in the correct sequence.

The fish-and-rice MC4000 on the top right has one job: when triggered, it saves the input value it got, then outputs it one time later to the fish output. It also pulses the rice output in the correct sequence.

Finally, the lower right MC6000 and the bottom center MC4000 are the gate MCs, which send the values to the gate outputs.
The bigger of the two MCs is the primary gate MC; it takes the pre-calculated gate-a pulse value from the central MC, and uses the table number to figure out the value of the gate-b pulse. It then sends the table number along to the secondary gate MC (the smaller one), which figures out the gate-c pulse values. Then, the MCs make the appropriate pulses all at once - which turned out to be the wrong behavior.

_{(For anyone wondering about the details of the gate pulse calculation, it's sort of like a cut-rate division by two. If the starting table number is over 4, the MC subtracts 4 from it and sets the gate-a pulse to 0; otherwise, it doesn't subtract and sets gate-a to 100. The modified table number will be a number between 1 and 4; if it's over 2, the MC subtracts 2 from it and sets gate-b to 0 - otherwise, no subtraction and gate-b is set to 100. This will yield an even-more-modified table number, which will be either 1 or 2. If it's 1, gate-c gets set to 100, and if it's 2, gate-c gets set to 0.)}


Redoing the design will be fairly simple - in order to keep the delays properly lined up, I think I'll need to split the gate logic into smaller MCs. However, this does come with a bonus. I won't have to have the 'precalulate gate-a' code in the central MC any more, cluttering it up.
The next design should be a bit cleaner. Here goes...

[ ~ ~ ]

Ta-da! First working version! My stomach's already growling with anticipation.



   

   

The gate outputs are now pulsed with the proper timing, and the design works - and there isn't that much that changed about it. The input-handling MC and the fish-and-rice MC are exactly the same, and the only change to the central MC is the removal of the gate-a precalculation code I mentioned above.

The gate MCs are different, though. In order to maintain the timing, each gate now has its own MC. When a gate MC gets a table number, it'll check it against its threshold, and pulse its gate output after a delay. If the table number is higher than the threshold, it'll subtract the threshold number and output a 0; otherwise, it outputs a 100. It then passes the modified table number to the next gate MC, if there is one.

The first gate MC has a threshold of 4; tables 1-4 yield a 100, and tables 5-8 yield a 0. If the table number is 5 or more, the gate MC will subtract 4 from it; this makes things easier for the next gate MC.

The second gate MC has a threshold of 2; tables 1-2 yield a 100, and tables 3-4 yield a 0. Notably, if the table number was 5 or more, it will now be in the 1-4 range: so, tables 5-6 become 1-2, which yields a 100, and tables 7-8 become 3-4, which yields a 0. This gate MC also subtracts 2 if the modified table number is greater.

The third gate MC is the end of the line. Because of the subtractions of the other MCs, it will always receive a 1 (tables 1, 3, 5, or 7) or a 2 (tables 2, 4, 6, or 8). If it receives a '1', it outputs a 100. If it receives a '2', it outputs a 0. That's it!

This design is ¥24, and uses 1127 average power per run.

[ ~ ~ ~ ]

I had a flash of inspiration while I was giving the design the once-over I do so I can write it up later. Quite simply: do we really need the fish-and-rice MC at all?
Turns out, the answer is 'no'.



 

   

This version moves the fish-and-rice MC's functions into the central MC, which connects to the fish and rice outputs directly. The central MC handles the timing for the rice pulses, outputs the value it receives from the input MC to fish when the time comes, and cues the gate MCs.

There are a few slight other optimizations: I removed some unneeded jmp instructions in the input MC, as well as making it so that the central MC sends '100' on its simple line to the input-handling MC when it's busy, not when it's free. These changes allowed me to save some power, and several lines of code - as well as cut down on the cost of the board.

The new version of the design is ¥21, using 1005 average power per run - but given that we only need one Omakase 9000, the big benefit is the decreased power usage. Before I send it off, well... I looked up 'Omakase'. It means, "I'll leave it up to you", and in the context of a sushi restaurant, can be read as ordering the "chef's special".

Here you go, Derrick. Omakase.



Awww.

Not much else to say, except - I've tried it too, and it actually was really good.