Vex Note: Motor power required to launch balls

April 23, 2015

The new vex game , Nothing but Net, could utilize a design similar to a two wheel tennis ball launcher.

Question: how many motors are required on the launcher?

The after a launch, the energy lost from the spinning wheels is transformed into ball kinetic energy and heat due to friction and ball compression.

After each shot the wheels are brought back to initial spin speed by the power of the motors.   The maximum time allowed for respinning is the cycle time of the firing sequence.    Lets take a look at the Vex game derived requirements:

Ball mass, m = 60 grams

Ball launch Speed, v =  6 m/s

Ball kinetic energy:K =  1/2*mass*v^2 = .5*.06*6^2 = 1.08 joules

Energy loss due to compression : E_c

Energy loss due to friction :  E_f

Time between shots: 1 sec

Average power required  p_avg = ( K + E_c + E_f)/ t

Force on ball during acceleration:

F =  d(m*v)/dt    or the change in momentum of the ball over the time of acceleration., dt.

dt can be approximated as the contact distance / tangential speed of the wheel , v.

The contact distance is about 3 cm so

dt= .03/6= .005 s

d(m*v) = .06*6 = .36 kg*m/s

hence F = .36/.005 =   72 newtons

Normal force on ball F_n = F/u_friction .    The normal (compression)  force on the ball is then

F_n = 72 newtons  assuming a u_friction = 1 which is possible with a sticky wheel.

The assumed  compression distance is about 1 in or 2.54 cm.  (To be verified later)

Hence Ec = F_n*d/2 = 72*.0254/2 = .91 joules. 

With good design, the friction loss in the drive train can be small (maybe .1 joules) so lets assume that E_c + E_f  are about equal to the K= 1.06 j so

p_avg = 2*K/t = 1.06*2= 2.12 watts   or 1.06 watts per motor.

We know the vex 393 motors have a max power = max_speed*max_torque/4 or about 4.5 watts  but they will overheat if run continuously at this power.   The PTC fuses will stop the motors if they run continuously with currents equivalent to more than  25% maximum torque (speeds less than 75% max speed).    At this operating point, the motors only deliver  3/4 max power or 3.4 watts.

There are also friction losses from the teeth of the spur gears.   I usually assume about 5% per 5:1 ratio.    A shooter wheel with a 25:1 gearing would lose 10% torque or energy at a given speed.

So the net power to the shooter wheel will be  .9*3.4 =  3.0 watts which is more than the 1 watt that we require.         

Extra friction?    

If the gear train has pressure on the axles from bearing blocks and possibly the collars are too tight so the wheels slow down quickly when coasting with motors disconnected, then over heating can easily occur.   e.g.  if friction uses up just 15% of the available torque, the motors will have to provide about 1 watt extra. which cuts our margin considerably.

Faster shot rate?

We assumed 1 shot per second…what happens with 2 shots per second….   Well, the power requirements almost double since we are using twice as much energy per unit time.    We would likely have to add extra motors.

Advertisements

60 in double reverse 4 bar linear linkage example

June 8, 2014

Here are some pictures of how a double reverse 4 bar using Vex 35 hole link arms. The main challenge is constructing a stable geometry. The lift has a middle link gear train to move the upper 4 bar in sync with the lower 4 bar.

Torque

Approx torque (inlb) required = 2*l_arm*(W_payload_lbs + W_lift_lbs + W_manipulator_lbs)*cos(angle)

height_delta = 2*l_arm*( sin(angle_finish) –  sin(angle_start))

where l_arm is the distance between pivots of the arms in inches, W_payload_lbs is game piece weight, W_lift_lbs  is the weight of the 3 arms used in the lift , W_manipulator_lbs  is the weight of the gripper attached to the upper arm and angle is defined relative to the horizontal.  The max torque occurs when the arms are horizontal or angle • 0 .

If you want to lift 4 1 lb Skyrise cubes with a 3lb lift weight , a 1 lb  gripper and a l_arm of 16 in you would need about 256 in lbs of torque.

As a rule of thumb I use 6 inlb of torque per motor for sizing  the number of motors.  This assumes 2  inlbs of elastic support , 1 inlb of friction and 3 inlbs from active current (about .9 amps) hold per motor used.   With these assumptions a 10:1 gearing and 4 393 motors might do the job.    The lift would take about 5 seconds to go full travel.  I’ll show a more exact torque derivation later.

Height change

With an  angle_finish = 75 deg and the angle_start= -60 deg  a 16 in arm reaches 59 in.  A 16.5 in arm reaches 61 in.   With a chain bar you could  clear an in or two more.20140608-214047.jpgSo 20140608-214101.jpg 20140608-214114.jpg


Note: Using a Line Sensor to Update Gyro Heading

February 28, 2013

Using Line Sensor to Update Gyro Heading

The programming challenge for the 2013 Sack Attack game was attempted by team 1508 LancerBots fully autonomous robot. It uses gyro information to generate a navigation solution and then automatically sequences through several way points to solve the route sequences. Unfortunately as mentioned in earlier posts, the gyro drift causes heading corruption which then causes sacks to by slightly missed. One possible solution I am proposing is to use line sensors to update the gyro.
Figure 1 shows the geometry and formulas required to accomplish the update for a special case when the line is parallel to the truth x axis.    The coordinates used by 1508 were specifically chosen so all lines were parallel to either the x or y  axis.  This simplifies the update equations.

Simply put… when a line sensor event occurs, note the position error  with respect to the line (using the Nav coordinates) and divide it by the range from the origin.    This ratio is the gyro drift error in radians.

Error Contributions:  

Errors in the update equation can stem from errors in  the Nav initial condition (<.25 in, 1 deg heading) , encoder scaling (typically <1%) , encoder resolution(< .03 in) , line location measurements (<.25 in), line tape width (<.5 in) and Navigation solution numerical errors (sampling, round off).

The dominant error is the encoder scaling which can add up when the encoder has moved several hundred inches.   Lines can also be use to update the Nav  position solution so that these  errors remain less than 1% distance  from the field origin and not the total distance traveled by an encoder.   This error translates to about .6 deg of heading error from a gyro update.    So we should not expect much better than that from our updates.

General Case: Lines skew to the coordinate axes

To complete this note,  lets consider a more general line that is described by

c = a*x + b*y

where a,b and c are constants and again x and y are truth coordinates.   Now we have three unknowns (x,y and delta) and three equations:

x’ = x*cos(delta) + y*sin(delta)

y’ = -x*sin(delta) + y*cos(delta)

c = a*x + b*y

First we solve for x and y from the first two equations which is a simple inverse:

x = x’*cos(delta) – y’*sin(delta)

y = x’*sin(delta) + y’*cos(delta)

Make the small angle substitution gives

x = x’ – y’*delta

y = x’*delta + y’

Now substitute x and y into the line equation

c = a*(x’ – y’*delta) + b*(x’*delta + y’)

Now solve for delta

c -a*x’ – b*y’ = (b*x’ – a*y’)* delta

or

answer:

delta = (c -a*x’ – b*y’ )/(b*x’ – a*y’)

Check the special case above :  y = c, a = 0, b = 1

delta = (y – y’)/(x’)  : checks ok


Waypoint steering geometry for a mobile robot

February 5, 2013

waypoint stearing dia

Fig 1 shows the geometry that I will use in the waypoint steering algorithms that will be discussed in future posts.  The field geometry is North (N) along the y-axis and East (E) along the x-axis.   The heading angle , psi is defined positive clockwise from North as a compass rose.

Waypoint:   The waypoint is defined with both location (X_p, Y_p) and direction psi_p.   The slope of the center track line m is  1/tan(psi_p).

Cross track and Along track Ranges:

The two parameters of interest are the along track range R_y and cross track range , R_x.   The steering is determined by R_x = R*sin(delta_psi) where delta_psi is the angle between a line drawn from the robot to the waypoint and the actual track line.

Derivation of R_x  and  R_y without sin and cos functions:

We know that the track can be expressed as a line that goes through (X_p,Y_p) and has a slope m.   So we can write the track line as  y= mx + y_0 form but we need y_0.    Plugging in for point p gives  y_0  = Y_p – m*X_p .

Hence the line eq  is   0 =  -y +m*x + Y_p – m*X_p.

It can be shown that the distance R_x  between a point  (x_r, y_r)  and a line  a*x + b*y  + c  = 0  is

|R_x|= | (a*x_r+b*y_r +c)|/sqrt(a^2 + b^2)    (see  wikipedia)

where a = m ,  b= -1 ,  c= Y_p – m*X_p ,    m  = 1/tan(psi_p)

This form can lead to division by zero when psi_p = 0 but can be avoided by using the tan(90 – psi_p)  = 1/ m  .  We  divide the starting equation

0 =  -y +m*x + Y_p – m*X_p

by m   to change its form and use it whenever m >1 or psi_p > 45 degrees.

0 = -y/m + x + Y_p/m – X_p.

Now we have new definitions of a,b,c

a = 1, b = -1 /m, c = Y_p/m – X_p  , 1/m = tan(90 – psi_p).

R_y derivation

We can use a similar method to find R_y.

|R_y| =  |(a’*x_r+b’*y_r +c’)|/sqrt(a’^2 + b’^2) )

where we use the perpendicular line to the track passing  through (X_r,Y_r) with slope  m’ =-1/m and the point as (X_p,Y_p).    This leads to

a’ = -1  , b’ = m’ , c’ = Y_r  – m’*X_r  , m’ = -1/m = -tan(psi_p)  .  We use this when psi_p  < 45 degrees and the modified form

a’ = m , b’ = 1 , c’ = -Y_r*m – X_r    for psi_p > 45 degrees.

Making R_x and R_y signed values

By convention, I want displacement to the right as positive R_x.  (X_r,Y_r) will be to the right of the track if  0< delta_psi  < 180 otherwise we change the sign of R_x.

Similarly, we want the along track distance, R_y,  to be positive if we are heading in the direction of the waypoint along the track and we have not reached the waypoint. This occurs when  0<90 – delta_psi < 180 otherwise R_y is negative.


Navigation update equations for a two wheeled robot

January 31, 2013

Navigation update equations for a two wheeled robot

These equations assume that the robot is traveling in a circular path with constant turn rate. This is typical of a robot that has set its motor speeds constant but different for left and right speeds. The nonlinear form involves sin and cos of both the present and last heading and involves division by the change in heading. It is more accurate but can lead to division by zero if the robot is traveling in a straight line.. i. e. it has infinite turn radius. The approximate form which is valid for small heading changes between updates is more robust since it doesn’ t require division by the heading change.

If a gyro is available with heading output then you don’t need to compute heading, otherwise, heading is derived from the difference in encoders.   Usually, the navigation equations are run periodically at around 20 to 50 hz.    Rates are derived by dividing the delta changes in position and heading by the update time.  Velocities can be noisy when the update times are short so often an exponential filter is used to smooth the outputs before use in control laws.

In the figure, psi_1 and psi_2 represent last and present heading values respectively.   These are defined positive counter clockwise.   If your coordinate system is N, E and  positive heading clockwise  from N then you would modify the equations by letting delta E = delta x , delta N = delta y and replace psi_ccw with 90 -psi_cw since we are now defining psi_cw positive to the right of the y axis instead of the x axis.  So  the NE coordinates would look like this:

N = N + (sl + sr)/2 *(cos(psi_cw) – delta_psi*(sin(psi_cw))

E = E  + (sl + sr)/2*(sin(psi_cw)   + delta_psi*(cos(psi_cw))


Resources relevant to sampling and removal of plastic from the oceans

September 29, 2012

This post will be updated occasionally with links that could be useful in developing concepts for a robotics project to work with Algilita.

relevant Blogs and Scoop it:

Ralph Schneider Design Web site.  Scoop it :  Marine Litter

Vamfun Scoop it: Synthetic Sea Solutions

Marcela Garcia: Marine-Litter

Commercially Available:

Spray glider: This is drone submarine  that is equipped with a CTD (for conductivity, temperature and depth)
that measures temperature, salinity and pressure, as well as an optical sensor
that measures the turbidity, which is related to the biomass in the water.   I might be capable of being adapted to sampling plastic… not sure yet.

Wave glider :   This sensor platform uses the energy of the waves for propulsion.   Solar panels and battery power the electronics.  Has great long term sustainability and can be independently controlled using gps navigation system and satellite links.     Currently used for meteorological data collection and ocean surveillance…but I think it could be easily modified to contain plastic sampling sensors to monitor ocean surface plastic density.

Current Measuring App for IPhone/IPad

The Clean Oceans Project is planning to use this to direct their plastic scimming boat to the heavy debris areas of the bay.   Hopefully this techonolgy can be extended offshore.

The app was developed by researchers at San Francisco State and six other universities and can collect real-time information about surface currents by the Golden Gate Bridge, Oakland Bay Bridge and Richmond Bridge. The app uses Google (GOOG) maps, GPS technology and shore-based radar sensors on Angel Island, Treasure Island, Tiburon, Sausalito and Fort Point in San Francisco.
“We put together what we thought recreational boaters would find helpful so they could see what the currents are going to be,” said Toby Garfield, professor of geosciences and director of the university’s Romberg Tiburon Center for Environmental Studies. “The GPS actually shows up in the app. So when you are in the Bay, you can see what the currents are doing.”

http://www.oeatech.com/2012/04/iphone-ipad-app-for-codar-current-data/

Concepts:

The Clean Oceans Project

http://thecleanoceansproject.org/plastictofuel.php

http://www.youtube.com/embed/8qBFlOqLnJ8?feature=player_detailpage

Nick Drobac, Founder and Executive Director of The Clean Oceans Project, is interviewed by LivingECO.com’s Ken Spector.  Featured in the interview is the plastic to oil machine that could help to clean up the world’s oceans including the Northern Pacific Gyre.

Project _ Floating Horizon (Ralph Schneider)

Here is a link to Ralphs ppt.

Marine Drone  Although this doesn’t seem practical for marine debris collection due to the conglomeration of different types of flotsam…It may have some use in the short-term collection of samples under a watchful eye.  Popular Science article .

Here was a post that pointed out some problems with the drone and brought some new ideas about a floating plastic processing island that was self sustaining.

Marine Litter Extraction Project

Boyan Slat conceptual project that is stationary and proports to minimize by_catch of marine life due to the use of booms rather than nets.  He recently gave a TEDxDelft talk.  I have had some correspondence with him re the details of the project.   He claims that the clean-up of the ocean can be greatly accelerated …i.e. from Capt Charles Moores 79000 years to less than 10 years:)    His talk went viral and many news sources picked up his concept and presented it as a feasible method to clean up the gyre plastic.    This sparked a interesting and informative rebuttle by the 5gyres Stiv here http://inhabitat.com/the-fallacy-of-cleaning-the-gyres-of-plastic-with-a-floating-ocean-cleanup-array/.   It should be fun to watch  where Boyan’s concept evolves to in the next 5 years.

Bio-Pod

Pod Project (abundantseas.org/pod_project)

The Pod’s shell is made of recycled plastic.   Inside, the Pod features a geometry that draws plastic particles into the chamber and a proprietary mesh that entangles the particles for permanent sequestration.  Moreover, such mesh also absorbs Hydrophobic chemicals.  pod project conceptThe Pod also helps restore the marine biome.  Its exterior shell provides anchor points for biomass to grow and flourish.  This is assisted by the Pod’s porous scrap metal ballast, which releases iron ion nutrients to feed marine life.  Note: biomass growth will increase the base of the food chain and, further, naturally sequester carbon-dioxide.

Therefore, overtime, the each Pod becomes an island sanctuary for new marine life, and it permanently sequesters floating plastic, along with chemical contaminants: toxins that cannot be netted and, thus, are among the greatest threats to the food chain.

degrading Technologies

New Organism Found In Ocean Lives Off Plastic   Now this seems to be the best of all worlds.   An organism that feeds on plastic and hopefully has non toxic waste.   Of all the methods I have come across this trumps them all.   We need an army of these organism and hopefully they can become part of the ocean ecosystem.

Prototyped projects:

Midland High School  Passive scooper …with a great write-up.   This is the kind of write-up that I desire for Grant High School Project.

This project homepage #09-2004 was developed by Mainland High School in Daytona Beach, Florida, in response to the 2009-2010 Internet Science and Technology Fair

OpenROV: Open Source Remote Operated Marine Drone

ROV Robot Submariner

Plans available for about $10.

Robotic Jellyfish

Virginia Tech is working on Cryo jellyfish.  It has eight legs and a 5 ft diameter silicon body cover with lots of sensors to monitor the ocean.  Perhaps could be adapted to the plastic pollution problem in some way.

cryo robotic jellyfish

Read the rest of this entry »


smart_PTC_monitor beta code release

August 31, 2012

Ok, I’ve got the RobotC code used in my smart_PTC_monitor developed to a point where I would let others play with it.   I originally used a single timed iterative loop that ran in the same task as  autonomous and user modes.  I decided to create a separate task that simplifies the user interface so normal programming can occur without any of my constraints.  When done, the user functions are easily inserted into my template to seamlessly add the PTC monitor protection capability.    The program is self documented with liberal commenting but I am sure people will have a lot of questions.   I am putting it out without fully testing all the functions to get early user feedback and if it proves to have utility, I will put out a more mature version that includes user feedback.

Please post your comments to the Vex forum thread where the program is introduced.   Thanks

 

Download:  https://dl.dropbox.com/u/17455717/smart_PTC_monitor_template.beta.8.27.12.c

 

Below is a copy of the introduction comments in the program:

//*************************************************************************************************************** // smart_PTC_monitor_template.beta.8.27.2012.c   Rev 0

// This program is an open source beta version of a competition template for Sack Attack.  It adds a task // called smart_PTC_monitor which uses current and PTC temperature models to manage a current_limiter function // which can keep hardware PTC fuses in the motors,cortex and power expander from ever tripping.

// Program Author: Chris Siegert aka Vamfun on the Vex forums. // see my blog: vamfun.wordpress.com  for model details and vex forum threads on subject // email: vamfun@yahoo.com // Mentor for team 599 Robodox and team 1508 Lancer Bots

// Teams are authorized to freely use this program , however, it is requested that improvements or additions be // shared with the Vex community via the vex forum.  Please acknowledge my work when appropriate.  Thanks

// Scope and limitations: // Program assumes that servo currents are zero.  If servo position is known, then currents can be modeled. // Testing has been limited to 393 motors and 3wire motors, however, the program handles  269 motors. // Periodic updates to the models will be made and posted on the Vex forum as more testing is done. // Program handles the Power Expander PTC when the ports are entered with provided #defines // All other motor ports are automatically configured to calculate the correct currents for each PTC

// Basic Instructions: // Write your program as you normally would.  When done, put your autonomous code in place of my_autonomous() // and your user code in place of my_user().  Then do a find and replace to change all the “motor” functions to // “motor_input” i.e.  motor[Left_motor] –> motor_input[Left_motor].

// Put all your encoder speed calculations into  void compute_speeds() function and assign speeds to M[port].speed variable. // You can read these speeds from the global array whenever you need them.  This loop runs at about 100ms update rate.

// Use a #define or switch to create a // PTC_monitor_engage boolean and set true to engage the monitor.

// Tell the program which ports are used by the Power Expander as shown in the example below: // #define PE_CH1  UNUSED // if used put port number …. i.e. PE_CH1  port1  else put the #define UNUSED

// #define PE_CH2  Right_drive_motor  //use setup names

// #define PE_CH3  port3  //use port name

// #define PE_CH4  1  // use integer = to port number -1.  This is motor port2

// Initialize the PTC temperatures using these #defines: // #define T_0_DEG_F  (72.) //Set robot ambient temperature here.  If you are in a hot gym…this might be 85 deg

// #define T_M  (100.) //100 deg C =Setpoint temperature for the PTC current monitor.

// Motor currents and PTC temperature data are held in a global state matrix M[] which is a structured array that contains // the motor PTC/current data in the first 10 elements (index 0 to 9) and the non motor PTC’s data in the next three elements. // M[10] , M[11] and M[12] pertain to the cortex1_5,cortex6_10 and power expander PTC states respectively.

// Program uses two update rates: The current_limiter updates at PTC_TASK_DELAY_MS which is 15ms // and the temperature calculations are set to run at about 6 times {PTC_TASK_DELAY_MS + subtasks delays) ~= 100ms. //****************************************************************************************************************