Trade Study / Arm Sizing

A project log for Oberth Arm

Wall plotter

riskncrisknc 11/12/2018 at 19:072 Comments

I've got rough requirements in my head already (and listed in the project description).

So the first thing I'll do is a trade study to size various components of the arm. This will give me loads to properly select COTS components and then size structural members. It will also give me an idea of deflections.

To do that, I'll make a spreadsheet that calculates bending moment based on geometry and component mass.

First thing I'll do is create a diagram of the arm, so I'm using common language to describe the various loads and components. 

Then I'll make a mass estimate. Some components will have known mass as they are downselected, others will have an associated Modeling Uncertainty Factor (which captures how uncertain I am of the mass). At first the estimates will be WAGs (or wild ass guesses), and I'll refine them over time. 

From here I'll do basic statics calculations to determine the loads in X, Y and moments each motor will see. I'll then create a rotating model that can calculate the static load in every possible position of the arm. I'll make a macro that runs through all positions at some fine resolution and get an envelope of all of the load cases. 

From here I can tweak various geometric parameters (like the sub arm length, the main arm length, etc) and attempt to optimize towards design requirements. For now I'll move on to calculating static deflections of the arms. 

To calculate deflections, we need section properties of the arms, so I'll make a quick spreadsheet that lets us input various cross sections and get the section modulus, cross sectional area, and modulus of elasticity for the various sections

From here I can calculate stress and try to minimize the material to get the appropriate factor of saftey and margin for the design. In this case, we're likely stiffness driven (to minimize deflection) so, strength of materials isn't as much of a concern. I'll finish fleshing out this portion of the calculator later. The other thing I can do with the deflection data is create a lookup table so based on a given encoder position of the motors, you can account for error in static deflection of the arms, this is useful when trying to achieve high accuracy without a lot of processor overhead to compute the actual deflection in each position.

The last thing I'll do is a rough dynamic calc to see how much load we'll see in an emergency stop from the max velocity that's planned. This will give us a rough envelope on the loads into the wall / mounting surface. it also tells us the static loads will be well eclipsed by the dynamic loads, so velocity profiling is likely a good idea. 

Now that I have a good idea of torque necessary to actuate the arms, I can select components for the motors, gear reductions, and drivers. This trade will include cost, mass, power, rotation rate, and a lot of other things, for now I took a couple motors that were in the ballpark and picked the Turnigy Aerodrive based on cost, necessary reduction, max speed. It also fits well within the envelope of the Odrive for control.

Next I'll design the cycloid reduction to get from the base speed of the motor to the intended max speed of the arm. I grabbed a couple research papers that described how to create the gear profile, and added the calculations to the spreadsheet. I took a stab at how to keep the drive compact and manufacture-able, by having it consist of two 1:11 stages to achieve the 1:121 reduction I was shooting for. I think picked a package size that seemed reasonable and generated a profile, which I can carry over into CAD and create a fit spline for later (and then, much later, CAM toolpaths to cut out the parts). 

At this point I've got some components picked out and I think I'm in the ballpark. It's a good idea to start grounding the models and get out of tradespace. Instead of dropping into CAD then FEA (which is normally how you'd start grounding your models and sizing everything), I'm going to go to prototyping from CAD to test experimentally. This should reduce my design cycle time and also, I don't have a decent FEA package at home, so project cost too :D. 

I get components on order and start prepping by throwing a test stand together for the motor / controller / encoders. This will allow me to stand up the odrive / motors, test various encoders, tune control gains, and test velocity profiles and various control modes without having the whole arm built. (I've also put a ducted fan for cooling and have a few thermistors to measure the driver and motor temperatures after long duration testing). I spend a while figuring out how to get the odrive to talk to my computer (woo command line fu), and get the motor calibrated. Then I put a dummy payload on the motor and test the built in velocity control mode. Seems to work well. 

I print an example of the cycloid reduction (and laser cut the cycloid disk) to check to make sure I've done the calculations right. it rotates freely, which is nice. I realize here that the pins on the periphery are way too large, and I can make this whole thing much more compact. 

Now I've started work on a piece of code to create velocity profiles for driving the motors.

Next is incorporating the magnetic encoders, rather than the optical ones that I purchased from odrive to get started quickly. Then I'll create some code for tuning gains on the motors and reading off the various control parameters of import (rise time, steady state error, overshoot). 

After that, and a redesign of the cycloid drive, I'll design the motor enclosure, and build a prototype motor - gearbox stack, and start testing that. Once I'm fairly confident in that, I'll likely move on to building the first prototype arm, and the end effector, then get that driveable with gcode or print drivers. 


Allie Watson wrote 08/27/2020 at 06:19 point

Education should develop along with science and new methods of researching social problems. I know the 5 best resources that will help you get a qualitative growth in self-education. Ideas for coursework – this is one of the advantages of such coursework writing service. This site presents my list of useful resources. Students should know the main points of self-education.

  Are you sure? yes | no

agp.cooper wrote 11/16/2018 at 00:35 point

I did something like this many years ago, modelled a two arm SCARA in Excel (with graphics of the movement), intended to use a serial port from excel to control the motors. So I dig your trade-off study.
But the SCARA driver (nowadays its an Arduino rather than Excel), is not so straight  forward (there is a pun in there!), especially if you want to go fast.
Anyway, I am interested what you plan to do with regard to your software driver. That is the reverse kinematics algorithm. The mapping is non-linear so it is trickier than most appreciate.
I wrote some C code this year that seems to work okay. It decomposes the reverse kinematic "arc" until the segments are (within tolerance) straight lines, so it can interface with GRBL. Works okay but there is still the (speed and numerical stability) problems of the ArcCos()/arcSin() functions, and floating point to integer conversion.
Anyway, when you get to this point (or if you have already solved the problem), I would be happy to "swap notes".

Regards AlanX

  Are you sure? yes | no