(eg, their lack of omnidirectional motion, which they had to solve by transitioning to a psudoquadraped both with the Akito of Exile's 4-leg mode using its arms as walking limbs and the Queen Asura, which is not the same thing as a psudotetrapod because a quadraped has a abdomin structure closer to a jumping spider with the legs arranged inwardly for the front and outwardly for the back, and a tetrapod is radial pushing legs out at square or diamond angles relative to the abdominal centroid)

...and of Artos/Armored Trooperoids of Votoms [...]

(which had problems of a small tarus or hoof style foot with zero longitudinal arch which results in a lack of clearly defined calcaneus and thus no formal heel which would allow terrain gripping via the relative motion of the arch and phalangal body of the toes the heel like a beak -- all to encorporate the wheel in the arch-space -- which the design partially compensates through the use of a talon mechanism, and an optional structure fitted to the ankle which folds down to form an extended front foot -- which Armored Core's 5th generation later references in the folding falanges of the UCR series -- and late,r the Blue Knight variant directly addresses by extending the foot by 50% to improve the contact leverage with ground surfaces)

This is accomplished by using the stair-climber mechanism as a heel, but encorporating a scissor mechanism. Right now I'm not happy with where it is and I'm still figuring out where the hinge would go to keep it omnidirectional, which again is the common failure of leg-design in these platforms.

This is a MASSIVE amount of information to take in even in this light summary without diagrams to explain what's happening and I'd need help to really express what I actually want to accomplish.

I'm right now deeply conflicted as to how deep I should actually go because we can get very lost in the weeds and I'm not very skilled at diagramming the points I want to make and I have an entire taxonomic and anatomical language for mecha that I remove from my work when I present it to the public most of the time.

Like do I go into the development path, do I go into the evaluation of evolutionary paths I see like throughlines connecting things like how we got from knightly designs in Panzer World Galient or Dunbine (the first isekai) informs Tekkaman Blade informs Xi Gundam informs Escaflowne informs White Glint informs Unicorn Gundam and Banshee informs NWGIX/V, etc, etc?

Like there's an entire lineage and family line there being Albidimiles -- albidimiles being a portmanteau of albido (white) and miles (knight) -- not to be confused with the line Samonaut, which are essentially samurai-astronauts commonly belonging to Gundam.

Since we're dealing with design memetics, common concepts of conventional phylogenetic development don't apply since through a genetic lens, mecha is incredibly dependant on horizontal transfer -- eg, passing of information via contact, so adaptions happen not always convergently but frequently in direct parallel, as an arms-race does.

So that's an example of what this is like when I don't filter any of it for an audience, and it very quickly goes off into the weeds.

What I really need to go to the next level is an editor who understands the concepts I'm dealing with; for example, do I talk about the inherent transness of the L-Gaim Mark II and Nagano's own history with gender expression as a mechanical designer and how he expresses those feelings of femininity in his work, or do I go full schizo and present the world with my wild "Nagano-Egg Fashion-Sapphoid-Mantis" theory which is in itself a total fever dream born of conjecture gleaned entirely from his work and photographs of him leering at Tomino instead of his wife at his own marriage?

I need someone to reign me in, but also be able to support me in this capacity -- ie, a research partner who's happy to let me toil in the weeds and then is happy to help me represent these ideas and understand what you as an audience can actually make sense of.

What has happened is I accidently over-studied the design part of mecha and understudied the illustration part which I'm actually very poor at.

I can go so much deeper than I do regularly, but making sure I don't lose people is a challenge I've never managed to solve so I mostly just write for myself and then only turn it into a post if someone has a question.

Holding another button will then go into one of the remaining sub-folders until the system runs out of folders.

If we associate the buttons with different properties at different times. One moment they might be (grapple/strike/parry/block). If we hold strike (option 2), it becomes FAST, with the full list now being STRONG/FAST/HIGH/LOW. If we hit the bumper without holding any other buttons down, we'd get our fastest strike, something ideal for creating openings to string a combination of hits together.

If we then held STRONG next, we've told the system that our priority is attack strength over precision. Hitting it now would result in a mix of fast and strong, where some of fast is sacrificed to make strong at a ratio of 50/50.

STARTING WITH GENERALIZED ACTIONS: MOVING TOWARD SPECIALIZED ACTIONS:

These menus are using loaded language which gradually become more and more specific as we go, culling options which don't match the context of our scenario.

For example, if you're in ballistic combat and you're holding a rifle, reloading the rifle's epack is probably more important than switching to another weapon right now but if you lock onto an opponent who's in close range (say you have a dedicated button which just auto-faces you toward and locks up the nearest opponent) you're probably want to use the context specific weapon in this scenario -- the beam sabre. If you're already holding someone in a block or parry, this will be taken into account by the solver.

WHY THIS, AND NOT A COMBO SYSTEM?

By drilling down into these menus, we get 256 different options, and they can be input faster than any conventional combo, they can be navigated carefully in special situations and they don't immediately demand you act instantly meaning you can have the action ready and choose the timing of when you trigger the action (which is an important strategic option missing from fighting-games which place emphasis on frame data memory tests over having different actions ready to trigger at the right moment which is closer to sword-fighting).

Likewise, in some situations, you might also want to hold the order of buttons and then adjust the input precisely with a control-cross or D-pad. Say for example, you want to launch a signal flare to a carrier. Here, an applette window is generated, showing the options the D-pad modifies above the history path, and the appropriate input can be chosen and then the bumper pressed to trigger it.

The applette probably remembers the last one you had selected so if you have to move back out to general combat, you don't have to start putting a new combo in again: You can just do another instant hold-order and trigger it, then while that action is performing, also then run the flare order.

WHAT DO WE GIVE UP, AGAINST A COMBO SYSTEM BY DOING THIS?

Clearly, its far more versatile, transparent, and visible to a user because the command-tree is visible, so the input tree itself can be searched using language that's plain English. While its higher maximum number of inputs possible is lower than a combo system, 256 is likely in excess of what's generally needed for pure hands on stick operation, especially when applettes are considered.

Its a system about sending commands into the system as fast as possible, and as easy to navigate as possible, forgoing blind memorization whenever possible, but also rewarding it by making sure the list itself is as consistent as possible. We also gain unlimited input windows, where a user can spend as long or as short as they want performing a combo, without having to "type faster or slower" or otherwise risk losing their string, and that search is non-committal, so a user can search, explore and memorize what they choose to since the command system IS the move-list by design.

If it helps, think of this as like a videogame camera in third person where the character (in our case, the robot) can face any direction it wants.

Now what happens is this acts as a goal input.

An example might be that you want the yaw information of operational space, but you don't want the pitch or roll data, so you discard it for some elements of the body.

Legs & Pelvis: Pitch & Roll come from surface, yaw comes from operational space within limits of joints

Torso upper half: All three values come from Operational Space within limits of joints

Congratulations, the robot is with zero button overrides peeking around a corner, tilting its body slightly over the gap while the lower half remains aligned to the surface.

GOP: GOAL ORIENTATION PROCESSOR & BASE ALIGNMENT VECTOR We do this by combining Operational Space as a GOAL INPUT, through a GOAL GENERATOR, and we get the GOAL OUTPUT.

Other GOAL INPUTS include…

A vector pointing at a target object (very helpful if you want to semi-automatically always face a locked target in close comat while you do fine movemen with your arms)

Surface Vectors (generated from a floor, or arbitrary surface)

Force vectors (eg, gravity or wind)

By combining these semi-procedurally based on specific situations, we generate not only appropriate orientations for the pelvis and upper torso, but relative to a supplied input we also generate the axis of our boosters in totally arbitrary 3D space for 3D maneuvering -- including 3D booster and 3D breaking

That's pretty crazy, isn't it? By selecting a specific target or being stood vs falling (and other system state changes) the action of the aligner and booster systems will modify themselves automatically to suit the situation in ways which are especially adapted and minimize the room for error.

ALIGNER BIAS MODES

We can mix and match these values based on our state machine (are we on a surface, are we upright, are we airborne, are we controlled, are we spinning or falling, etc, etc) but also based on some ALIGNER request values (eg, the ALIGNER being on STRICT ALIGNMENT means it wants a horizon to work with and will make corrections to OPERATIONAL SPACE with these vector axis, SOFT ALIGNMENT will let you yaw arbitrarily but it will automatically roll if you're not looking nearly up or down and pitch 360, and OFF/NO ALIGNMENT lets you entirely manage this manually yourself. FORCED ALIGNMENT is of course, if the mobilesuit's feet detect a ground-plane, and it wants to stand upright upon it.

So the value we just generated is called our ALIGNENT VECTORS. Like the modal earlier, we probably want to override this, so we modify it using a BALANCE VECTOR.

GOP: GOAL ORIENTATION PROCESSOR & FINAL BALANCING VECTOR

A BALANCE VECTOR comes from a second input, and using axis supplied by the GOAL GENERATOR, we can independently rotate the upper torso and pelvis/legs independently.

In the case of the legs, we can roll them, and we can pitch them. This is ideal for sitting, laying, crouching and going prone. Likewise, offsets for walking and bodily movements like skidding to a halt when maneuvering (ground-breaking) are also taken into account here, and the system will resist our attempts to collapse the robot to the ground, unless we deliberately make an input requesting this (eg, double pulling a stick at its maximum or decoupling the limit to let us go beyond tilting ranges into new postures using a thumb toggle switch which requests this action)

FINAL BALANCING VECTOR & BOOSTER CONTROL

So booster control by default always boosts "up". Moving say, a thumbstick will tilt the booster 90 degrees, producing directions like forward, or sidewards -- with some automatic accounting that steps in and provides some lift so our sinkrate is controlled.

Where this factors into balancing is if that "up" direction belongs to the pelvis orientation (which we command say using left joystick) we can rotate the booster command direction more than 90 degrees so we can do things like boost directly downward. Similarly, we can say, put the legs behind the torso, and reduce our aerodynamic drag, while the boosters themselves will boost forward instead of up by default.

Depending on our mobilesuit design this may also generate some aerodynamic lift by deflecting incoming air down, as a lifting body sometimes does. Suddenly our mobilesuit can dash and move a little bit like an aircraft, and by changing the big joystick, we change the direction of travel by moving the legs, or by using the thumbstick to retain our posture (helpful if say, we'd like to kick something or land with our legs forward onto a wall).

Our opposing thumbstick may control the orientation of our operational space (like a head or lockbox) while our joystick on the same side will yaw and pitch the upper torso. This is helpful if say, you want to make a smooth movement with a blade, or move a shield into place, or face an opponent side on.

It might seem like a lot to pay attention to, but in practice, its surprisingly simple.

HOW THIS COMBINES WITH OKAWARA/WHAT THIS MEANS FOR HAND CONTROLS:

As for the OKAWARA mechanism, I'd say put a small thumbstick on the end of an analogue trigger, with a bumper above it. The bumper sends a direct input command (eg, a weapon), but the analogue trigger and stick for your index finger let you make more precise inputs as a point along a curved plane with the trigger depth deciding the size of the plane, and the index stick position choosing where the arm sits.

Combined together, you have a wholistic body control concept.

WHAT ABOUT SIMPLER DESIGNS/COST SAVING MEASURES?

If you're looking to simplify, just have a targetting mode change, where the modals loaded just don't give you such independent control: You want to only drive the body (and the weapons as an automatic firing control solution) OR the arms as a close combat solution more directly based on context? Switch modes with a button or a pedal.

AND THE PEDALS?/WHAT ABOUT SEMI-AUTOMATIC MANEUVERING?

As for pedals, don't think I'd forgotten these:

They're obviously used for firing different sets of boosters: One which is for gradual thrust directionaly, and the other for sharp corrective bursts.

Orientation thrusters command automatically from the solver, though I do also see situations where the system steps in and instead of providing a boosting goal direction, you're instead requesting a position relative to another object, taking into account its velocity. This would be REALLY helpful for say, landing on a moving object, or in close combat or when docking with an object or station-keeping with a moving object.

This would be our Goal Velocity Processor (GVP).

Some final thoughts:

This is a lot to take in! Won't pilots be overwhelmed?: Not really. In 90% of situations it feels a lot like a 1st or 3rd person game and you can let a lot of the machine's automatic systems do things for you (fire-control, and some immediate macro inputs) or you can use these systems to take a richer deeper finer level of control (ie, play ace).

Why do speak with such confidence on the specifics?: Because I'm building it and through trial and error, I'm functionally seeing what works and what doesn't, and where different control contradictions arise. I have been on and off since 2016. The videos listed are just testing different subsystems and seeing what works. Right now I've completed TOMINOS, and as soon as I fab some specialty joysticks with the help of /r/diyHOTAS I'm going to start work on OKAWARA.

If anybody is interested, I'll do macro automation next, which is also accounted for in this design which is a sort of clever graphically navigable combo system designed for faster inputs than fighting-games generally let you do by combining held inputs, rather than tapped inputs.

--

So these modals get broken down into what you can think of as lego-bricks as part of a chain of inputs, which users can swap out or the system can automatically infer which ones to use circumstantially. They're all very generalized so even if the match isn't perfect, you'd probably be able to compensate it out with some basic human intelligence as a hybrid solver matrix (eg, it solves fancy math).

AI cherrypicks the math with a human's biases but the math itself is doing the work here. AI can't do all the work in situations like these, because AI often has real problems with dealing with edge-cases so what you want is AI dealing with assisting the rapid construction of then a more dependable system with simpler mathematical principles.

Block 0: Base value

Base value specifies that a thing is either pointed at, or positioned and how the rule works for transitioning between the two. You can think of this as pointing a laser-pen at a curved piece of paper at a distance from a joint (say your torso or your shoulder). If the endpoint of the laser-pen was closer than the distance of the paper some how, you'd get a point in 3D space which doesn't adhere to the paper. Likewise, you can have a second sheet of paper here which acts as a minimum distance -- where if the length of the line from the emitter is too short, it will stop here. This means you end with a sort of segment of a donut of valid vs invalid locations.

Think of inverse kinematics for say the movement of a hand in VR. You don't actually control all the goal points of the hand. Likewise, here, you technically only really need 2.5D axis for pure hand movement, as you're moving a position along a curved flat plane that the goal slides along, and then you move the plane itself.

This is pretty similar to the task changing between grasping (close range) vs pointing (long range). Pointing anticipates grasping by positioning your arm correctly to catch an object which is stationary. For a moving object however, we have to change about how we think of a moving object!

--

Block 1: Goal position Modifiers

A goal position is where we decide to point or place our robot hand. Logically if we make this the derivative of its position if its moving, we can put the hand ready to catch the object automatically for us and we could say pipe that information in from the fire-control system's understanding of moving objects around itself. Likewise, if we're factoring in torque values, we can act as a suspension system to resist a surface or other object so we have some play at work. Helpful if you're hanging from a surface, or if you're grappling, or resisting a surface you are moving along.

--

Block 2: Body object kinematic

So far we've assumed we're always moving a hand. We might actually be moving a long stick or a shield or other object to intercept with the point assigned. These are external bodies, or bodies which are held by multiple hands such as a polearm. In this way, we are moving that external body and then the inverse kinematics driving arm positions update automatically for us to put the external object body into the goal position that we want. This actually gets really helpful if say, we're picking up an entire enemy mobilesuit.

The physical material class of the object is also accounted for: Say for example you're not going to grip a beam saber or weapon handle or a human being in the same ways. These all have VERY different rules, and each can be told apart from the others fairly easily in this way.

--

Block 3: Bias steering/driving

So now we need to think about how we're either assigning targets, or modifying the goal position. In this case, we have all these fancy controls. If something like wrist orientation and hand pose is managed automatically for us, we can then position the hand or modify that position ourselves. Say for example minovsky interference is making it hard to aim so the lock is taking a while. We obviously want the arm to be as slewed to the target as we think we can get it so when the lock confidence is high enough the arm will take over and slew for us, to minimize its travel time.

That's something we get control of. Similarly, by skipping the long chain of target identifying behaviours done by selecting targets on a radar screen, this steering behaviour can send a preference directly to the fire-control selector and therefor we can change targets instantaneously. How? The system looks for the target with the least rotational difference from our cursor and tries selecting that object, and we can padlock the cursor to make the selection persistent. This kind of "algorithm heavy selection" is often how games like Armored Core handle things and by cutting down the time to manually select and manually aim, you can speed up combat enormously for everybody involved.

Likewise, if you're aiming some sort of stick shaped object, or the endpoint of a shield, you're going to want to control the direction an object slides across it, and in these cases the system is probably not also going to be letting you make those orientation adjustments (like our block 0 modal component) but its also likely going to draw the endpoint for you so you can see where you'd be putting things as a path along the object as a sort of helper so you can see what the result of a push or slide from you would result in.

--

Block 4: End effector automatic tasks

So this is going to be the orientation of the hand itself, and what the fingers are doing. This is going to be performed automatically by the IK manager, or a context clue is going to be inferred by the system (eg, this is a person and you probably don't want to crush them but you also don't want to drop them)

Rotating the wrist or picking hand movements is all inferred contextually by the mobilesuit using classifiers and context cues, or specific override for biases by selecting a different modal, and I imagine most modals are things which are very easy to build procedurally for pilots in a matter of seconds based on certain commonalities: eg, keeping an object balanced or positioned on a palm without using the fingers to close around it is probably a goaling type and would be used to hold a person or object.

--

Simple example:

Say for example you're doing a fire-control task. No sweat:

0: Base value is relative to shoulder, and this is primarily a pointing task

1: Goal position is the derivative of an object based on the ballistics velocity of our weapon

2: Body object is the rifle's pointing task, or a blocking task if it gets too close

3: Steering automatically is coming from fire-control, and steering manual is a steering/selection modifier with a padlock option

4: End effector is holding an object, and keeping its up vector roughly aligned with the torso, allowng for an offset provided by the euler tilt of the aim vector relative to the torso

And from these kinds of building-blocks, you can pretty much create almost any imaginable arm movement for mobilesuit operation, including operation which uses both hands, and even includes a cascading full body posture (where the system's balance steps in and accounts automatically based on expecting breaking and balancing forces, and the nature of how "full body" the IK cascades is likely on a sliding knob somewhere or something akin to a mousewheel where the IK can gracefully hand control between different regimes).

Summary 2 will becoming shortly, and will be written on full body movement -- Torso Orientation & Motion In Operational Space (TOMINOS) which explains operation of the torso and legs.

If that goes down well, I might write up some specific detailing of how the hand controls themselves are likely to be designed functionally speaking and what the bare minimum of input vs the maximum of input is, and why hand-controls tend to differ mobilesuit from mobilesuit and what their specific purposes are.