Vex Note: How a single flywheel ball shooter minimizes the effect of ball mass variations

May 28, 2015

Nothing but Net 2015/2016 competition game involves shooting 4 inch balls that can have a 10% variation in mass.    We know that trajectory range ,R = V^2/g*sin(2*theta) so it  is dependent upon the square of the ball release speed , V, and shooter elevation, theta.   Mass does not enter into the equation unless it affects V.

Ball release energy :

Suppose we use a Vex 5″ diameter wheel as a flywheel and rotate it a w_wheel angular speed.      As the ball leaves the shooter, it will have a V = r_wheel*w_wheel/2.  e.g. half of the flywheel tangential speed.    The ball will have a spin rate , w_ball = V/r_ball.    The energy of the ball, E_b , is the sum of the ball translational energy and rotational energy.

E_b = 1/2*m_ball*V^2 + 1/2*I_ball*w_ball^2

where I_ball = 2/5*m_ball*r_ball^2 (solid sphere of uniform density).

so Eb =  1/2*m_ball*V^2( 1+2/5)  .   (corrected 5/29 Was 1/2*m_ball*V^2( 1+4/5)  So the rotational energy adds  40% more to the translational energy.  Rewriting in terms of w_ball gives

E_b = .7*m_ball*w_ball^2*r_ball^2  

Wheel Energy:

E_wheel = .5*I_wheel*w_wheel^2.  where

I_wheel = m_wheel*(r_wheel*.84)^2  (ref blog post

Energy Conservation:

E_wheel_initial = E_wheel_final + E_ball     This assumes that the wheel is not being powered by the motor during launch and that the extra energy needed for the ball comes from the flywheel.   Also, friction and ball compression energy losses are assumed zero to simplify this analysis but can be significant in actual percentages derived.   I am focusing  on how increasing flywheel mass lowers the percentage range errors caused by ball mass variations.

E_wheel_initial/E_wheel_final = (1 + E_ball/E_wheel_final)

Lets expand E_ball/E_wheel_final

E_ball/E_wheel_final = (.7*m_ball*w_ball^2*r_ball^2)/(.5*I_wheel*w_wheel_final^2)

= 1.4*m_ball*w_ball^2*r_ball^2/(m_wheel*r_wheel^2*.84^2*(2*w_ball*r_ball/r_wheel)^2)

= .4954*m_ball/m_wheel

SInce  m_ball = 60 g and m_wheel = 180 g   m

_ball/m_wheel = 1/3

So  E_ball/E_wheel_final = .165    for a single 5″  wheel flywheel     .165/n for n flywheels.    So the ball energy is almost equal to the 1/6 final energy of the wheel

Range Tolerance analysis:

So how does R vary with m_ball from all this.   Well , we know the range is proportional to V^2 which is proportional to w_wheel_final^2 which is proportional to E_wheel_final.

From above E_wheel_final = E_wheel_initial/(1+ .4954*m_ball/m_wheel)

So due to proportionality of R and E_wheel_final we can say

R/R_0 = ((1+ .4954*m_ball_0/m_wheel)/(1+ .4954*m_ball/m_wheel))

where R_0 and m_ball_0 are the nominal values without errors.

We can use R range= R_0(1+ %e_r)   and m_ball = m_ball_0*(1 + %e_m_ball) to work with % changes.

Then with some manipulation we can get %e_r as a function of %e_m_ball

%e_r  = -%e_m_ball/(2.02*m_wheel/m_ball_0 +1 + %e_m_ball)

Now m_wheel = n*.180 kg   and m_ball= .06 kg  so we can write an approx.

%e_r = -%e_m_ball /( n*6.06 +1)     where n is the number of 5″ vex wheels.

Lets put in a few numbers:

Assume %e_m_ball = 10%  then the range error is

n = 1, %e_r =  -1.42%

n = 2, %e_r =  -.76%

n = 3, %e_r =  -.52%

n = 4, %e_r =  -.40%

n = 5, %e_r =  -.32%

So you see the benefits of having a higher  flywheel mass to ball mass ratio.   The use of  two 5″ wheels in a single wheel design can reduce a potential 10% range error from ball mass variations  to  1% ( less than a ball radius).   To keep the spin up time to a reasonable number of seconds requires about 2 393 motors per wheel so 2 wheels costs 4 motors.   So there is a motor tradeoff to get that  higher accuracy with heavier flywheels.

Finding the moment of inertia of a Vex wheel using parallel axis theorem

May 17, 2015

vex 5 in wheel

The new Vex game “nothing but net” might involve rotating shooter wheels.  We know that if all the mass of a wheel was located on its rim then the moment of inertia about its rotating axis  (I_rim) would be

I_rim = r^2 * m   where m is the mass of the wheel and r = radius of wheel.   But we know that the wheels actually  have mass that is unevenly distributed along the radius so the moment of inertia I_wheel will be less than I_rim.

Easy experiment to determine I_wheel if we know its mass.

We can determine I_wheel experimentally using the parallel axis theorem and the dynamics of a pendulum.

Parallel axis theorem says that any object that is rotated about an axis parallel to and a distance , d, from an axis going through the centroid of the object will add an amount =  m*d^2 to the moment of inertia about its centroid.  I.e.

I_parallel = I_centroid + m*d^2 .

Suppose we now swing the mass, m,  about the parallel axis like a pendulum  using just the torque from gravity pulling on the mass.      It is easy to show that the period, T , of the pendulum is related to the distance , d, and the moment of inertial , I_parallel, by the following formula:

T = 2*pi*sqrt(I_parallel/(d*m*g))     .   g is gravitational constant and assumes swing angles smaller than say 10 degs from the lowest point on the pendulum path. 

If we measure the period of the pendulum we can rearrange the equation and find I_parallel

I_parallel = T^2*d*m*g/(2*pi)^2 

Once we have I_parallel, we can now use the parallel axis theorem to determine I_wheel.

I_wheel = I_parallel –  d^2*m  =  d^2*m * (T^2*g/d/(2*pi)^2 -1)

(This assumes  that the string has negligible mass relative to the mass of the wheel)

Vex 5 in Wheel experiment:

Given….r_wheel = 2.5 inches ,

wheel mass,   m = 180 gm (0.180  kg)

The pendulum is created by suspending the wheel with a thread 2.75 inches from its center so

d =. 07 m (approx. 2.75 inches)

The average period  T = .668 sec

I_wheel  = d^2*m*(T^2/d*9.8/(6.28)^2 -1)

     = d^2*m*( .248*T^2/d -1)

     = .07^2*.180*(.248*.668^2/.07 -1) = 0.00051 kg m^2

Equivalent radius with a rim only mass r_e

r_e = sqrt( I_wheel/m) = .0533 m ( 2.1 inches)  

This  means that the wheel behaves as if the mass if located at 84 %  of the radius of the wheel which one could almost guess by looking at it.

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.

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.


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

Homemade sea water for testing an ROV

March 16, 2014

Our GHCHS Algilata OpenROV project is not located near the ocean.   The OpenROV community has found that salt water operation can be flakey compared to fresh water due to low resistance between the salt water and  external wires that connect the battery tubes and the motors.     This post deals with making simulated sea water for testing the OpenROV in the lab.

Sea water conducts electricity due to the dissolved salts that produce ions for transporting charge between conductors submerged into the water.   Typical sea water has 35 parts per thousand  by weight of salt in water.    Since water at standard conditions weighs 1000 grams/liter then we can say that sea water has 35g of salt per liter.

I wanted to use just a cup measure to make a batch of sea water.     So I weighed one cup some Himalayan salt and found that it weighed 8 oz.  So we can estimate the weight of salt using this ratio…about 1  avoirdupois oz weight per 1  fluid oz .   Of course this will vary with the granularity of the salt due to variations in packing density but it should be good enough for conductivity testing.

Given that there are 28.3 grams per avoirdupois oz and  33.8 fluid oz per liter the sea water concentration of 35 gm per liter converts to  1.24 avoirdupois oz per 33.8 fluid oz or

1 avoirdupois oz per 27.2 fluid oz.

Since 1 cup (8 fl oz) of Himalayan salt weighed 8 avoirdupois oz then I would need to mix this with 217.6 fluid oz of water or 27.2 cups of water (1.7 gallons)

So I now have a simple rule of thumb for adding granulated salt to water using a volume measure:

volume ratio salt:water  1 : 27.2 

Other useful equivalents:   5.7 oz salt per gallon of water

                                              1/4 cup salt to 6 3/4  cup water

                                             1 tablespoon  salt to  1.7 cups water

Measuring salinity using conductivity:

Scientist often use conductivity to estimate salinity.   Standard units of conductivity are Siemans/meter  (S/m).    The electrical conductivity of 35 ppt salt water at a temperature of 15 °C is 42.9 mS/cm  (ref).   Thus 35 ppt equates to 42.9 mS/cm.


Taken from wikipedia

Conductivity measurements assume that there are two parallel electrical plates of area A in water at a distance L apart.   If a voltage (V) is put across the plates and the current flow (I) measured then the conductivity  k = I/V*L/A =  L/(R*A)  where R is the resistance V/I.    Under ideal conditions the conductivity between the ROV wires and the water should be very low (high resistivity) but if a small area of copper is exposed  then conduction can occur. eg  some OpenROV forum members are finding resistance on the order of kiloohms rather than megohms.

Practically, if you put two probes from an ohm meter into water, the measured resistance will depend upon the area of the probe submerged and the distance between them.   You can use this as a reference to test your simulated sea water at home.

conductivity plug testerI made a simple  crude conductivity  instrument out of a two prong to three prong electrical plug adapter.   The plug prongs are separated by 1 cm and the exposed area between the prongs is almost exactly 1 sq sm.  I covered the non-facing sides with tape or you  could use paint or nail polish to insulate the surfaces from water.   See photo.

In the field,  dip the plug tester prongs into the water and measure the resistance between them.  Note the temperature since conductivity varies a lot with temperature.

Theoretical  plug conductivity prediction for sea water.

k = L/(R*A)  = 1/R            S/cm

= 1000/R    mS/cm

Typically sea water resistance in ohms for this homemade instrument  at 15 deg C would be

R_ohms = L/(A*k)= 1cm/(1cm ^2)/(42.9 mS/cm) = 1000/42.9 = 23.3 ohms

When creating your simulated sea water at  home you would like to have similar conditions.   You would add salt to your water tank/tub until the resistance level matched.


I did a quick conductivity test by dissolving 1 tablespoon of Himalayan sea salt in 1 3/4 cups of water.   The measured resistance  using my plug conductivity tester was around 3 kohms with a VOM meter and using the voltage / current method the resistance was 230 ohms.     So it is reading much higher than the theory.    The test was done at 70F (21C).   Temperature changes the conductivity about 2% per degree.  The measurement was 6 deg C higher so at most we would expect a 12%  increase over the 15 C reference.

The absolute measurements can vary too much with conductivity so I would recommend just using the 35g/kg  salt/water mixing method or just doing relative conductivity measurements..i.e.  matching field conductivity to home conductivity under similar conditions.

OpenROV Cape Test Program (No Beaglebone required)

November 30, 2013

I decided to modify the OpenROV 2.4 Arduino source code to create an automatic test program that stimulates each of the cape outputs periodically to see if the Arduino ATmega328 chip and connecting circuitry are operating correctly.  Software has been tested with the cape operating  stand alone.  Hopefully it will run in a OpenROV cape with a Beaglebone attached provided the cape.(TBD)

Hardware Requirements:

OpenROV cape


LED lights

Battery Pack (12v)

ATmega328 programmer (Arduino Uno will do)


1) Remove the ATmeta328 chip from the Cape and use an Arduino board to load the Openrov_cape_test.ino with includes.

2)Place the ATmega328 chip back into the Cape and hook up the externals (motors, servo and lights) .

3) Connect the battery power to the Cape. (Typically 12v)

4) Watch motors , servo and light cycle periodically in sequence. Each command level lasts for 2 seconds.


Software Files: Download OpenROV_cape_test  folder from my dropbox. In it you will find the following OpenRov_cape_test.ino file.   Just use it instead of OpenRov.ino file.

/* OpenROV_cape_test  Written by Chris Siegert, 11.30.13 ,, This program is designed to test the OpenROV Cape.  Program generates commands that cycles motors, tilt servo and lights sequentially.  No Beaglebone is required for the test. Power the cape using the battery input terminals and connect the output devices. All motors are cycled simultaneously with 2 second steps at magnitudes {135,90,45,90}. Motors are left in reset mode. Next the servo is commanded to {170,10,90}Basically full tilt up to full tilt down and back to neutral. The light goes to full brihtness then to half brightness and then off. The device sequencing is then repeated continuously. If running without the Beaglebone, load the sketch and its includes into the ATmega chip using an Arduino project board or programmer.  Then reinsert the chip back into the cape.   If running with the Beaglebone, one might be able to just upload the program using the OPENROV cockpit utility. */

#include <Servo.h>

#include <Arduino.h>

#include “Motors.h”

#include “Command.h”

#include “Device.h”

#include “Timer.h”

Motors motors(9, 10, 11);

Command cmd;

Device vout(“vout”, 0, vout.analog,;

Device light(“light”, 5, light.analog, light.out);

Timer time;

Servo tilt;   int array[MAX_ARGS];

int case_no=1;   void setup(){


pinMode(13, OUTPUT);





delay(3000);//wait for ESC to calibrate }

void loop(){

switch ( case_no)   {

case 1:


Serial.print(”  mag = “);



delay(2000); //cds  set step delay


Serial.print(”  mag = “);





Serial.print(”  mag = “);





Serial.print(”  mag = “);


Serial.println();    //motors.reset();




case 2:

Serial.print(“servo” );

Serial.print(”  mag = “);





Serial.print(“servo” );

Serial.print(”  mag = “);



Serial.print(“servo” );

Serial.print(”  mag = “);




Serial.print(“servo” );

Serial.print(”  mag = “);






case 3:

Serial.print(“light” );

Serial.print(”  mag = “);




Serial.print(“light” );

Serial.print(”  mag = “);




Serial.print(“light” );

Serial.print(”  mag = “);







case_no = 1;  //repeat sequence

} //end switch


note 1 Beaglebone Black: Boot attempt using OPENROV image

August 9, 2013

As mentioned in my last Arduino post, the 599 Algilita ROV team selected the OPENROV processing architecture for their ROV.   It was hoped that this would save us a lot of time setting up the cockpit display software which is already working on OPENROV.   Ha…think again.   Unfortunately, the OPENROV flash image which works so nice in the Beaglebone doesn’t seem to boot with the Beaglebone Black (BBB), at least for me.

Flashing the OPENROV image to BBB (unsuccessful)

The BBB uses a built-in eMMC to boot from normally.   To flash a new image you insert a micro SD MMC and while holding down the User (boot) button on the BBB you power up the board either by USB or 5v power supply.  Continue to hold the button until the user LED’s begin to blink (See flashing procedure),  The BBB board is then boots up and transfers the image from the micro SD to the built-in eMMC.

I made a bootable 8GB micro SD card using the Windows solution outlined in the Getting Started link   I held the boot button down, powered up and waited for over 5 minutes for the user LED’s to light, but only the power LED lit.

I searched the forums and only found one comment re the BBB not being able to flash the OPENROV-image.  Apparently some modifications need to be made to the uSD 64K partition that contains a file called

I did check that I could flash something by starting with a fresh Angstrom image and booted that ok.