View source for RR/Mechanical through joint motion threading

<small> page originally created 2018-10-28 Sunday @reprec <br>

= MechanicalThroughJointThreading =

Design goals for [[RR/RepRec]] systems include: <br>
– No mobile motors, all motors as static as possible. <br>
– No electric transmission across mobile joints. <br>
– Chains rather than belts A goal is [[./FactoringOutActuators.md|:FactoringOutActuators]]. <br>

Thus there is a need for threading motion mechanically across mobile interfaces. This can be quite challenging.

Since in RepRecs all motors are supposed to be mounted statically (with some cheavats — see [[./NoMovingMotors.md|:NoMovingMotors]] ) And no electrical threading through joints to moving parts is allowed (including chaincableguides and spiralcableguides) All mechanical motion must be threaded through joints. This strongly influencing the [[./BaseGeometry.md|:BaseGeometry]]

– This makes 1DOF revolute joints preferrable (simple hinges) instead of 2DOF joints (ball joints &amp; co)

<span id="three-options"></span>
= Three options: =

== Put all motors at the base of the Crawlers (Yes?) ==

-This is likely the best compromise choice and thus this- <br>
-will be the approach pursued first in eventual prototyping.- <br>

Put all the motors in the limitedly mobile [[./MotorBackpack.md|:MotorBackpack]] / [[./VitaminBackpack.md|:VitaminBackpack]] <br>
Threading in all the action mechanically through the [[./Poser.md|:Poser]] ( [[./Positioner.md|:Positioner]] and [[./Orienter.md|:Orienter]] )<br>
'''Small CONs''' <br>
– sill a large mass and volume to move but only in one axis (for 1D mobille crawlers) <br>
– no longer in the topological center =&gt; more parallel mechanical through joint threading '''PRO''' <br>
– 🤩 the crawler should provide ==sufficient space for a large volume of motors== (given they can be configured in a linear fashion)

== Put all motors at the BaseTruss (No?) ==

Factoring the motors out of all the way. <br>
So motions must be mechanically threaded through <br>
the [[./BaseTruss.md|:BaseTruss]] and the [[./Crawler.md|:Crawler]] [[./Interface.md|:Interface]] first.

'''PROs''' <br>
– all moving mass and volume from motors is completely factored out <br>
– plenty of space for big motors <br>
'''CONs''' <br>
– this requires the maximal amount of parallel through joint threading <br>
– threading from [[RR/BaseTruss]] into the [[RR/Crawler]] may be especially challenging (linear slideinterface) <br>
– this choice may undermines modularity a bit <br>

'''Here’s a crazy / likely silly idea:''' <br>
Is the [[RR/Stowage]] is based on [[RR/BaseTruss]] mounted attachment chains, then <br>
these attachment chains could perhaps be double used to thread in mechanical motion from motors <br>
that are fully static mounted on the [[RR/BaseTruss]] rather than in the [[RR/MotorBackpack]]. <br>
Many reasons not to do so though. <br>
– conflation of concerns, Inertial mass (macroscale), … <br>

== Put all motors between positioner and orienter (No!) ==

'''Big CONs''' <br>
– Macroscale: Way too heavy a load gravitationallly and inertially <br>
– Nanoscale: Way too much voluminous load – [[GMT/PowersupplyForMotors]]?? <br> 
'''PRO''' <br>
– Minimal parallel motion threading paths since it’s situated in the topological center <br>

= Influence on choice of robotics geometry =

'''Parallel robotic mechanisms can:''' <br>
– 🤩 reduce the amount of necessary mechanical through joint threading (the mechanism itself carries that info on) <br>
– 🤩 distribute through joint motion threading across multiple pathways <br>
– 🙂 As a boon they are also typically often stiffer than serial mechanisms. <br> 
– 🙁 As a downside some parallel mechanisms come with a much reduced range of motion, especially in rotation  <br>
(like e.g. the steward platform or delta-bots) <br>

It’s easier to mechanically thread motion across <br>
– 1DOF hinge type revolute joints rather than across <br>
– 2DOF+ ball joints (like e.g. the steward platform or delta-bots) <br>

'''Given all that here’s the result:'''  <br>
Parallel mechanisms with 1DOF hinge type revolute joints (that are not steward platforms or dela-bots) <br>
essentially leaves parallel SCARA robotics as the natural self suggesting choice. <br>
This can only serve as the [[RR/Positioner]] though. Not as the [[RR/Orienter]]. <br>
Additionally for a [[RR/Orienter]] needed is a robot wrist with <br>
a high range of reachable space angle (2pi or more). <br>
Preferably in parallel robotics. <br>

= Examples: =

'''Parallel SCARA robot:''' <br>
When the (two) arms move the the rotations transmitted through the arms <br>
(for end effector rotation and gripping) change due to the hinge angles changing. <br>
This need to be accounted for by subtraction of this motion.

'''Cartesian Robot:''' <br>
Use the difference of the main drive chain to a second parallel drive chain <br>
two drive the motion on the gantry bridge (via bevel gears — to sketch). <br>
Same from the gantry to the [[./PoserToToolFlange.md|:PoserToToolFlange]]

Differential drive approach: <br>
– H-Bot … may be interesting  <br>
– Core X-Y … the oddly bent drivechains may be an issue especially in assembly

There are '''two issues with cartesian robot mechanisms''' though: <br>
– the build-space is always smaller than the bot ~ this makes self-replication more complicated (not impossible) <br>
– [[RR/PrismaticJoints]] can be more challenging than revolute bearings

= Rolling rather than sliding =

Slide bearing solutions preferred to roller bearing solutions (See: [[RR/PrismaticJoints]]) <br>
due to these being possible in a much more compact fashion. <br>
Particular examples: 
* the [[RR/SprocketStacks]] in the [[RR/Poser]] of a [[RR/ParallelSCARA]] 
* the [[RR/NestedAxles]] in the [[RR/Orienter]] of a [[RR/ParallelSCARA]]

But there may be reason to worry about wear for a macroscale implementation. <br>
See: [[RR/MassOverhead]] section ''Macroscale''.

= Related =

== What redirects to here ==

* [[ElectricalThroughJointThreading]]