Part 74: Assignment #AC4: Target Practice

Target Practice

It turns out my 'robot arm' was even more useful than I could have predicted. As I write this, I just finished troubleshooting a variant of the design to be used in a pair of giant-size cargo cranes at Avalon City's port!! It's worth noting that the cranes were produced 'in-house', so to speak - about half of Avalon City's projected industrial areas are at least complete-adjacent, and the rest is under construction. The city is a lot bigger than I imagined when I saw that diagram. I don't know what sort of population Mr Haotian's planned for exactly, but I bet the numbers are big...

Unfortunately, the latest job that came into my inbox pretty much killed my excited mood.









I'm really not sure how I feel about this. On one hand:

• I really don't feel happy about defense-related projects, I'm sorry. Just, on principle. (I didn't even know Avalon City had security teams until this email...)
Especially after making the badges before moving here.

At the same time:

• If you have a city of X thousand people, speaking purely pragmatically, you probably will eventually need some sort of people-to-provide-security role, simply because of how human nature is.

In addition:

• The police-force-types will be armed with theoretically nonlethal weapons (I'll have to look into this - humankind has historically been really bad at making 'weapons' to stop someone without hurting them).
• It's not like my accepting or rejecting the project will change things - according to the spec, literally all I'm making is a fancy dartboard.

I'll do it... with some light reservations.


So, looking at the spec again, one very large thing jumps out at me: the display outputs are XBus... and unlike the LuX Industry 7-segment displays I used for the timer and scale, the score displays on this dartboard need a value to be output to them every time unit. This pretty much guarantees that I'll need to have the central parts device in an active loop while 'on', not just an input-driven one. Fortunately, detect is a simple input, so I can check it at any point during the time unit without any trouble.

The other thing I noticed is the requirement to use the Pythagorean theorem to calculate the straight-line distance from the center of the target. The Pythagorean theorem is: X² + Y² = Z² - here, X and Y are the horizontal and vertical components of the distance from the center, and Z is the straight-line distance I need to find.
Squaring the X and Y distance is as easy as multiplying each value by itself (after subtracting the distance from 50 - if the result is a negative number, squaring will make it positive). But 诚尚Micro MCs don't have a 'square root' instruction; thankfully, though, I don't need one. Distances of 10, 20, and 30 from the center translate as Z²s of...

Z < 10 == Z² < 100
Z < 20 == Z² < 400
Z < 30 == Z² < 900

It's even better than it looked at first glance. I can just use dgt 2 to get the hundreds digit of the calculated result, then output the addition to the user's score based just on that!

So, based on what I've said so far, here's what this design will probably need:
• One or more MCs to perform the distance calculation
• A MC to coordinate everything and respond to input.
• A MC for storing and displaying the score - possibly two, one for each display. We'll need this in part to handle the flashing effect, which doesn't seem a good place to put elsewhere.

Let's get to work.

[ ~ ]

By now, if you've been reading this blog for a while, you'll know that "but it almost works" is a refrain that comes up now and again.

And, well— I have a prototype. And it almost works.





   
   

The design's a lot like I predicted. The two MC6000s on the left calculate the incoming shot's distance from the bullseye - the first MC (far left) performs the actual squaring and gets the hundreds digit of the resulting number. Then, the second MC (not as far left) takes that number and turns that into a score value.

The MC6000 just right of center coordinates everything. If a shot's detected, it'll get a score value from the calculator MCs on the left, then send that score to the small MC4000 just above it (which sends it on to the correct display MC, or it's supposed to. We'll cover this MC next). The central MC also keeps track of the number of shots fired; if it's the middle of a set, it'll send a '0' to each display to keep them lit up while the device waits for the next shot. If a full set of 8 are fired, it sends the special value '-900' to each display; this will trigger the flash sequence.

The MC4000 just above the central MC is there because of a problem I didn't foresee during the original design. When the central MC sends a score value out to boost a display MC, it needs to send '0' to the other display MC - or the display MC that isn't being updated will go blank. The small MC - effectively a distributor - makes sure the score updates get to the right display MC, with 0s sent to the other one.

Finally, the display MCs (which both have the same code) are the two big MC6000s on the far right. Each MC tracks the value for one display. Whenever the display MC gets a ping, it'll update its value by adding the incoming value, then display the result. (This does mean that the display MC needs to be pinged every turn when the board is on - that's the central MC's job.)
If a display MC receives the value '-900', it'll flash the display three times, then clear its value and turn off.


Now for why it almost works: I'd mistakenly assumed that the users took turns, and this design reflects that - note that the distributor MC4000 just sends incoming score updates first to one display MC, then the other next time it receives input. This is actually wrong. The first user takes four shots in succession, then passes things over to the other user.

I'll just have to make a few slight adjustments, then I'll have a working design.

[ ~ ~ ]





   
   

Adjusted version ahoy! This design only has a few changes from the first version:

• The distributor MC now keeps its own count of how many shots have been fired. It sends the results to the correct display MC accordingly - the first four to the score-1 MC, and the next four to the score-2 MC.
• The display MCs and the central MC have all had their code slightly streamlined to save power. It still runs the same.

The calculator MCs haven't changed at all. And more importantly... this version works! It's ¥28, and 1100 average power per run.
It's done; it's serviceable; let's get it out the door.



Now that that's done, I can get back to my usual work, which at the moment seems to be installing variants on those robot arms all over the place. It's actually pretty nice - I get to see a lot of the city, and I'm doing something both meaningful, and guaranteed to be unequivocally useful.

One last thing: I looked into what the 'nonlethal weapons' consisted of. They are NOT tasers, which is something I was worried about - I was previously aware that tasers can cause serious harm even if they don't necessarily kill you.
The 'weapons' Enzo had me build a dartboard for are net guns! They're larger than traditional guns, use some sort of spring mechanism, and fire a capsule containing a compressed net covered in some sort of glue. On impact, the capsule breaks open, and entangles/glues whatever it hit. Dummy capsules for training are the same weight, but don't contain glue.
(It's not a perfect solution by any stretch of the imagination - the impact could knock someone over on a bad hit and maybe give them a concussion from falling over, or do some damage if aimed at someone's head - but it's still better than actual firearms. I'll choose to be cautiously optimistic.)