MechanicalThroughJointThreading

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

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 & co)

Three options:

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

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

Put all the motors in the limitedly mobile [[./MotorBackpack.md|:MotorBackpack]] / [[./VitaminBackpack.md|:VitaminBackpack]]
Threading in all the action mechanically through the [[./Poser.md|:Poser]] ( [[./Positioner.md|:Positioner]] and [[./Orienter.md|:Orienter]] )
Small CONs
– sill a large mass and volume to move but only in one axis (for 1D mobille crawlers)
– no longer in the topological center => more parallel mechanical through joint threading PRO
– 🤩 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.
So motions must be mechanically threaded through
the [[./BaseTruss.md|:BaseTruss]] and the [[./Crawler.md|:Crawler]] [[./Interface.md|:Interface]] first.

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

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

Put all motors between positioner and orienter (No!)

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

Influence on choice of robotics geometry

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

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

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

Examples:

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

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

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

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

Rolling rather than sliding

Slide bearing solutions preferred to roller bearing solutions (See: RR/PrismaticJoints)
due to these being possible in a much more compact fashion.
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.
See: RR/MassOverhead section Macroscale.

Related

What redirects to here