## 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 https://vamfun.wordpress.com/2015/05/17/finding-the-moment-of-inertia-of-a-vex-wheel-using-parallel-axis-theorem/)

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.

## All systems going for 599 Robodox 2013 Ultimate Ascent robot prior to bagging for competition

February 20, 2013

Prebag weekend was long but fruitful.  The kids and mentors put in about 12 hrs a day Sat, Sun and Mon to integrate and test all the systems prior to bagging the robot.  I must say, the shooter performance looked great… the Frisbee shots were fast and accurate.  The autonomous startup time including shooter spin up and firing 3 Frisbees was about 5 seconds which leaves us about 10 seconds to pick up and score two more.    It takes about 4 seconds for a ground Frisbee to reach the magazine so things are looking up for autonomous.

Video of first low hang:

Video of Frisbee floor feed into magazine:

Video of rapid shooter test:

Busy students and mentors doing final preparations of subsystems:

## Reflections on Robodox 599 LA 2011 Logomotion Regional

March 28, 2011

Wow… what a difference a few weeks makes.   The team performed very well in all aspects.  We picked up the Imagery Award and we were the number 1 ranked robot for most of the meet until a 330 strong alliance beat us and eventually we wound up as the 4th seed.   We teamed up with 207  Metalcrafters of Hawthorne and 973 Graybots of Atascadero for the elimination rounds and breezed into the semi finals where things got a little tougher.    We were beaten by the eventual champions 1197,968 and 3473.   This was a hard hitting match but we scored well and had the minibots done their job we could have advanced to the finals.

So…we live and die by the minibot deployment.  We lived early on and died when it counted.    The last match, 207 had its tower disabled due to a high minibot deployment violation and we had a no go deployment.  So zero points from the minibot race killed us.

Minibot Stuff

We diagnosed the missed deployments to a likely combination of several causes:

1) a weak spring tensioner on the end of the deployment beam.  This takes up the shock and is supposed to put pressure on the minibot wedge to keep it aligned.   But the spring had loosened up and wasn’t checked carefully enough by the kids to jump on it and get it fixed.  This was corrected prior to shipping the robot to St. Louis.

2) The deployment arm was drooping slightly because the slide rails were opening up slightly.  This was compensated for by tilting the arm up slightly.   A better fix might be to add a roller bearing that overlaps the support bracket and keeps the end of the arm from lifting off the slide when fully extended.

3)The minibot slide was missing two roller bearings on the very front of the slide.  This contributed to the droop mentioned in 2).

4) Hard collisions with other robots can jostle the minibot enough to cause the auto shutoff switch to activate from a strong hit on the cowling ceiling that protects the minibot.    I had cautioned the kids about this possibility but they were afraid to mess with the robot and felt that it probably wouldn’t happen.  But of course, I think it did and further analysis of match video might confirm this.   A partial fix was attempted prior to the final match, but this area needs a solid design fix since at Nationals, there will be a lot of hard hitting in an attempt to dislodge minibots from hostbots.   I will suggest that a latch be added that is released when the deployment is activated by pulling a pin out( like a dead man switch)

I did not catch the fact that the kids were not using the checklist that they used so well in San Diego.  I need a checklist for the checklist:) Proper use of a good check list certainly might have helped identify and correct the problem areas mentioned above.  Van gave them a good talking to.

Minibot 3.0:
Our minibot 2.0 and 2.1 run about 1.5 and 1.3 secs respectively.  This might be good enough to be competitive in St. Louis but we should continue to improve since other teams will.   At LA I spoke with several minibot mentors and we exchanged helpful tips.  The kids were mad at me for giving hints to a UCSB physics professor who used our scale and pole to tune up the 1717 minibot since they would probably be our opponents if we got to the finals:)    I learned from 207 that there is a silicon surgical tubing that is a little more sticky than the latex tubing.   We might give it a try along with reducing the normal force created by our magnet.   We should purchase another magnet that is more easily adjustable than the disc drive magnets we are using.   Team 330 had the fixed cantilever design which used polyurethane shrink tubing I think… but this really is not as good as latex in the friction dept.  but it does give them the ability to easily add layers of tubing to adjust the diameter of their roller to optimize the speed.
Our mini bot weighs about 2.5 lbs which is less than 1717s and other fast bots that I looked at so the main thing we can do is adjust the normal force and reduce friction and weight a little.   I am sure we can get to 1.2 sec climb time before St. Louis.    I believe our motors are slightly smoked and we are losing about 5 to 10% of power…but we may just live with this.
Autonomous:
This performed consistently during the meet.   It uses line tracking that is accurate but very lightly damped with large heading oscillations.   This may be cause by too high of speed on the motors or just due to the center of turn being too close to the location of the trackers.   Typically you want the trackers to be fwd of the center of turn.   The more forward , the better the damping.  When at the center of turn, the tracker is neutrally stable and will always oscillate.     I will suggest that we try a lower speed command….but if that doesn’t work we just live with what we have.

For sure, we should get the encoders working and have a backup heading hold with distance determined by encoders.   This is what the Beach Bots do and it works very well.   If a line sensor fails, we will be out of luck unless we are prepared.    A secoondary backup would involve just timed motor commands.
Strategy:
The main improvement would be in the area of defense.   Our team is offense oriented and this is ok…but I didn’t see the alliance partners playing tough defense against the opponent top scorers. When we went up against  the 330 alliance, their partners prevented us from deploying our minibot while both their minibots were allowed to score.    I think we need to show more leadership in getting our partners (who are less capable scorers ) to play better defense.

So we compete at the nationals in St. Louis on the last week of April and hopefully, these bugs will be fixed and improvements added.

Finally, my condolences to team 1366 and the young woman’s family re this accident.    It is a sobering incident and all teams should review how they watch out for the young team members that are on travel.

## Robodox teams Finish Strong at CSUN Vex Competition

December 12, 2010

Once again, three 599 teams (A,B,D) were in the finals with A on the winning alliance.   B and D were paired but experienced a few Vexnet problems again that may have cost them the match.

599D Semi Final match Video

599D Practice Match @GHCHS

D team entered a new concept robot that they constructed in 3 weeks after junking their old robot that was the number one ranked robot in the last two competitions (we all thought they were a little crazy to do this).   The new robot concept was to collect all the opponents tubes in a basket to deny their ability to score.   It also had the capability to score and de-score.   I haven’t seen any other robot that duplicates this capability.    It worked really well and got them to the finals again.   But they lost in a close match.  D has had their robot in the last three finals but have failed to prevail for various reasons.    We’ll see what they do if the team decides to go to worlds.

Team A also won the drivers skill challenge (107 score).

Team C had the best Programming challenge results (35 pts) but due to close of challenge mixup, the award was given to the second place team with the gracious consent of Team C.  Good sportsmanship prevailed so I say well done .  The kids put in a lot of hard work to win this and hopefully, the mixup won’t sting too bad.

More 2010 results:

Round up challenge at GHCHS.

CAMS.

## Proposed 599_Competition_Scripting_Template

September 12, 2010

On my TBD list was to adapt the mentor Bobcat program to a competition format.  I decided to propose a generic template with a few changes to the scripting concept which might be adopted by 599 and possibly other teams if they like it.  This differs from the Bobcat scripting in that is uses C switch() statements to step through the scripts instead of nested if else statements. Also, it uses separate script functions rather than stacking the scripts in a single function.   I actually prefer stacking them, but I’m sure others would rather use separate script functions.  Review Bobcat scripting concepts here first.

New program features:

The new RobotC program is called 599_Competition_Scripting_Template.c and uses an include 599_Competition_Scripting_Template.h .

The program keeps the same structure for both autonomous and user control modes.  Only the script selection routines differ and kill_switch logic.   Most teams use entirely different structures.  The main features are summarized here:

AUTONOMOUS

-autonomous scripts are selected by sensor inputs (plugs or potentiometer)

-Select_autonomous_script()  picks the script to run.

-kill_switch can be enabled.  auto_debug_mode is inhibited.

Top level progrom flow:

void Autonomous599()
{
while(true)
{

if((SensorValue[kill_sw] < 127)&& ENABLE_KILL_SWITCH) //kill button on robot is A/D port to save digital ports
{

if(script != no_script) // stop scripts by reinitializing
{
Initialize();
bsingle_step_mode = false;
}

allMotorsOff();
break;
}
Process_sensors(); // read and process sensors to get variables needed for functions

Operator(); // read driver commands from joystick which are not under script control

Select_autonomous_script();//call autonomous script based upon cortex input auto_select (in8) port status

Run_scripts();// Runs the selected script from Select_autonomous_script() to get commnads from scripts

//call core functions here that use commands from operator() and run_scripts() functions

Core_functions();

}//end while
}

USER CONTROL

-user scripts are selected by joystick buttons during competition

_Select_user_script() picks the script to run.  Otherwise top level logic is about the same as shown above in Autonomous599().

– In auto_debug_mode,   autonomous scripts are selected by joystick buttons.  So this can be the primary test mode for AUTONOMOUS scripts.   Once debugged, the names are put into Select_autonomous_script().

-ENABLE_AUTO_DEBUG  and ENABLE_KILL_SWITCH defines can be use to enable these modes for testing and disable them for competition.  If auto_debug_mode is enabled, then single_step_mode feature can also be used.

-joystick Btn8R is used for auto_debug_mode engagement and script disconnect

-joystick Btn8L is used for single_step_mode engagement and single_stepping.

Simulated script function testing :

The template has simulated functions that allow check out of the scripting logic.   Just need a Cortex and a Joystick, no motors etc.   Instructions are in the 599_competition_scripting_template.h file.

here are some of the introduction comments in the .h file:

//RobotC 599_Competition_Script_Template.h
//This program is a suggested template with dummy scripting for both user and autonomous modes testing.
//Simulated pwm commands are generated by joystick and scripting functions
//The pwm commands are integrated to create simulated distances, dist1,dist2 and dist3 which
//are functons of joystick axes 1,2 and 3 respectively.
//Download to cortex and use the Vexnet debug competition mode control (DISABLE,AUTONOMOUS,USER CONTROL)
//to exercise the software logic and  and watch global variables move with the joystick and scripts.
//DISABLE…nothing but timer moves
//AUTONOMOUS…runs auto_script_2 and stops.  auto_script_2 is determined by sensor port in8 (auto_select).
//USER CONTROL…move joystick axes 1,2 and 3 and watch dist1,dist2 and dist3 move.
//Then select scripts with buttons 5U,5D,6U,6D and notice how the scripts take control of its axis and
//allows the remaining joystick axes to function as normal to joystick inputs.
//If you hold button 8L down for 3 sec, you can then use single stepping of selected scripts with subsequent 8L pushes.
//USER CONTROL …. auto_debug_mode.  Allows autonomous scripts to be tested in USER CONTROL mode.
//Hold 8R down for 3 sec and now you can use the same buttons (5U,5D,6U,6D) to select auto_scripts.
//Single stepping works here too.  Disconnect auto_debug_mode anytime with another 8R push.

//More details below:
//Driver operation with no scripts active
//Joystick Ch1 controls pwm_cmd1 which sets the speed that dist1 moves.  Same for (Ch2,pwm_cmd2,dist2)
//and (C3,pwm_cmd3,dist3).

//Script calling during driver operation (uses buttons 5U,5D,6U,6D)
//Btn5D calls script = name_1;//moves relative distance 1 up by 500 and restores it
//Btn5U calls script = name_2;//moves relative distance 2 up by 500 and restores it
//Btn6D calls script = name_3;//moves relative distance 3 up by 500 and restores it
//Btn6U calls script = name_4;//script increments total time by 1000,2000 and 3000 ms in three script steps.

//auto_debug_mode allows autonomous scripts to be called by 5U,5D,6U,6D
//Set with Btn8R 3 second push and follow with push of script button.
//Btn5D calls script = auto_name_1;//moves relative distance 1 up by 500 and restores it
//Btn5U calls script = auto_name_2;//moves relative distance 2 up by 500 and restores it
//Btn6D calls script = auto_name_3;//moves relative distance 3 up by 500 and restores it
//Btn6U calls script = auto_name_4;//script increments total time by 1000,2000 and 3000 ms in three script steps.

//single_step_mode
//Set by Btn8L 3 second push. Subsequent Btn8L pushes cause the script step to increment by 1.
//Stepping can be used for both manual and autonomous scripts.
//Single_step_mode is reset by kill_sw or button 8R push once a script has been initiated.

//Script Reset
//Running scripts are reset when they complete, when the kill_sw is hit or when Btn8R is hit.

//Can set defines  ENABLE_AUTO_DEBUG and ENABLE_KILL_SW  to enable use in testing or disable for competition.

Here is the new Run_scripts():

void Run_scripts()

{ //Do not modify

static int last_script = no_script;

if(last_script != script && script != no_script)

{

step=0;

bsys_reset = true;

}

last_script = script;

if(script == no_script) return;

switch(script)

{

//Modify to match your script names and scripts

case name_1:

Script_name_1();

break;

case name_2:

Script_name_2();

break;

case name_3:

Script_name_3();

break;

case name_4:

Script_name_4();

break;

case auto_name_1:

Script_auto_name_1();

break;

case auto_name_2:

Script_auto_name_2();

break;

case auto_name_3:

Script_auto_name_3();

break;

case auto_name_4:

Script_auto_name_4();

break;

//do not modify between here and end of function

default:

Reset_scripts();

return;

}

if(done == 1 && script != no_script)

{

if(bsingle_step_mode)

{

if(bsingle_step)

{

step++;//increment to go to next step if button 8L is pushed

bsingle_step = false;

bsys_reset = true; //this is used to initialize each do_something script function

}

}

else

{

step++;

bsys_reset = true; //this is used to initialize each do_something script function

}

}

}

Here is a new typical script:

void Script_name_1()
{
switch(step)
{
case 0: //initialize script
done = 1;
break;

case 1:
done= Move_dist_ch1(500, 50); //command a rate of pwm 100 amd move to dist1 = 500
break;

case 2:
done= Move_dist_ch1(-500, 50);//command a rate of pwm 100 and move back -500 back to zero
break;

default:
Reset_scripts();

}

Posted pictures on the vex site:

High Hang??

More blog stuff:

https://vamfun.wordpress.com/2010/09/01/roundup-mentor-bot-operator-mode-scripting/

https://vamfun.wordpress.com/2010/08/05/roundup-mentor-bot/

https://vamfun.wordpress.com/2010/07/01/vexnet-joystick-stuff/

https://vamfun.wordpress.com/2010/06/10/vex-cortex-notes/