FRC 599 2012 Meet Schedule

This year’s game is called Rebound Rumble.  It is a basketball game with bridge balance bonus at the end.

We have a schedule set for the Robodox 599  regional competitions.

San Diego Arena March  1,2,3 and 4   I will be coming down on the 1st, 2nd is practice , 3 and 4 are competition days.

Long Beach Arena March 14,15 16 and 17  Same schedule.

If we make it to the Nationals in St. Louis we will be there April 25 – 28th.

Come on down and visit the team.  We love supporters.

Note: FRC Rebound Rumble Requirements

I have been thinking a little more about capabilities a robot needs to compete successfully in Rebound Rumble:

Shot accuracy tradeoff:

Comparing a robot that can make 100% of its 2 point shots with a lower accuracy 3 point shooter:

In hybrid a 3 point shooter can miss 1 out of 6 and still get the same points. (83 % accuracy)

In user mode a 3 point shooter can miss 2 out of six and still get the same points.   (67% accuracy)

To achieve the hybrid accuracy,  one can use manual sighting from the key line and design an accurate cannon.  Pending a lot of testing, lets assume that a ball trajectory variation of about 5 inches out of 100 inches or about 5 percent will give a 95% probability of success.   This translates to roughly 2.5% on a one sigma basis or about 1.5 degrees one sigma in angle accuracy.

If the robot moves forward to the fender, it can reduce the range to 4.5 feet from 9 feet and the % errors are inversely proportional to the range… so one could stand a one sigma error of around 5% or 3 degrees.     This makes for better scoring if you are aligned to the target… however, you lose you manual sighting and must rely on hybrid or autonomous targeting.  I am not sure that you can rely on encoders or gyros to keep you aligned to within 3 deg because you might bump a corner of the robot or slide a few inches sideways.   However,  in hybrid, a camera bore-sighted with the cannon can display the aiming error and the Kinect driver could make fine corrections where necessary or there could be auto aiming by closing a control loop adjust both range and sighting angle.   This is more complex and shot reliability may be degraded since you are doing more things.  Also when a robot moves toward the fender it takes longer to get to the bridge and retrieve possible extra balls to shoot especially if planning on capturing the ones on the cooperative bridge.

I believe there is great utility to scoring one or two extra balls in hybrid even if they are put in the 1 or 2 point baskets.  The 3 point bonus looms large.  So I recommend that shots be taken from a manual sighting from the key and then a quick maneuver to get the balls off the bridge.  I believe a robot can quickly align with the bridge using autonomous programming but if a ball doesn’t fall into the ball scoop then it is possible for a Kinect operator to retrieve a loose ball and if maneuvering is simple might still be able to score an additional ball.   Here  I think Mechanum wheels would have an advantage over a 6 wheel robot since the robot can keep its alignment a wall while collecting a ball and then make a quick run to the fender for a shot without making turning maneuvers.  This would simplify Kinect control since the robot is only moving forward or sideways.   … So need to have a requirement for arena based heading either from gyros or encoders.

That Darn Bridge:  The team chose to make getting the 40 point elimination balance bonus a priority.   However, I do not see a design that can achieve this reliably and therefore driving the design in this area at the detriment of scoring may not be the best trade-off.   Perhaps we should strive to be compatible with a super 3 robot balancer robot rather than be one and focus more on being a good shooter.

There are three basic approaches  to three robot balancing and each has its flaws:

1) Ride the rail with a skinny ,  half hanging robot.  This is great, but there must be a 10 in wheel base to support this.   This could be achieved by adding extra rider wheels that don’t normally contact the rug.  I suspect that these would have to be powered since using the power of just the two inside wheels would drive motor currents to roughly 50% of max for as long as you are on a tilted ramp.    Normally, we design a robot to have enough torque to accelerate at 1 g .. typically requiring 40 amps max.   To climb a 15 deg slope you need .25 g capability.  With all motors powering, this would require roughly 10 amps per motor.  If you have two wheels off the rail then we need 20 amps.    So it would be important to have the extra rider wheels powered.       I believe both 6 wheel and Mechanum drives could be adapted to use this concept.

2) Fit three robots end to end on ramp.   Allowing 12 inches for balancing adjustments this leaves 72 inches to share among three robots.   Allowing another 12 inches for 4 bumper widths leaves 60 inches for three robots.   So one can fit three 20 inch robot frames on the ramp.     Typically, two robots must be sideways with narrow profiles and the other one could be length wise and hanging off half of the robot or one robot would be sideways and two robots must hang off. ( very unlikely to achieve).    If robots are sideways, it is hard to imagine that they must not have the capability to adjust sideways as the robots work their way up the ramp.  Hence, a 6 wheel robot would be at a disadvantage to a Mechanum robot here.   A 6 wheel robot could get towards the center of the ramp and turn sideways but it will likely have to reposition itself to help the balance.   In this scenario , an active auto balance system could work better with the Mechanum.    In a two robot balance, both would work ok with auto balance.

3.  Fit two robots end to end, one with a third robot stacked onto it.    This scenario probably will surface.  I can envision a specialized robot that is one foot high that will take a piggy back robot from the ramp onto its back and then join the remaining robot on the ramp for a two robot balancing act.   This to me is the most effective way to balance three robots but it requires careful coordination and several configurations of robots on the ramp… If it is a real threat I also believe that a good defense can be done by restricting access to the ramp and delaying the balance.      If an alliance tries to achieve this from their lane then several offensive robots must cross the bump or the ramp to get into the lane.  A good set of defensive robots can run interference to one or two of these robots to prevent a three robot balance.   If offensive robots try to get on the bridge opposite the lane then again they are vulnerable to blocking or temporary pinning.     As a defender, a six wheel robot probably has the edge over a Mechanum due to its traction and pushing strength but a Mechanum robot might better defend against a very agile robot.

Not probable but it will happen:  Based upon the difficulty either from execution complexity or good defense I believe that there will be a small number of successful 3 robot balances.   Maybe less than 1 in 10 tried.   So the average points gained would be more worth 4 rather than 40 points.  This is  based upon the fact that if you fail to balance three, then likely you will fail to get two or even one balanced.

Teams will only attempt this if absolutely necessary since it is very risky.  But if you are down by 6 to 10 points when the last 30 second period starts… then it is worth the risk.    If I was the alliance with that kind of lead, I would defend heavily against the three robot balance and probably make a tough job almost impossible.     If an alliance tries to set up before the thirty-second point, they give up opportunities to score.

Mechanum over 6 wheel drive for 599:

One can always make an argument for sticking with the tried and true 6/8 wheel drive.  Many robots will have it and one or two will likely be on the winning alliance.    Based upon the discussion above re the three bridge balance  I don’t see this requirement driving the 6 wheel drive.  If anything, I think the added maneuverability coupled with a skinny profile can make a Mechanum design more robust and also fit better with different types of robot designs to achieve a balance.   If it is a wash with the 3 robot balance, then the Mechanum would be favored for the targeting/ball retrieval tasks.

But… my main reason for favoring Mechanum’s is to gain experience with them.   We will never know unless we try them.   (Same with swerve drive which I think is highly favored by this game…but we can’t do this because we as a team have been reluctant to try these too. )

Skiff Design:  If the skiff is going to pull down the bridge it must turn around and go up the bridge to keep the skiff able to grab the next robot bumper to help keep it on the end of the bridge.  Perhaps the skiff should have the capability to swing completely to the other side for knocking down the bridge.  It  could have a foward slant and allow the bridge to slide down it even while you are driving with some speed.   This capability would require a clamp on the frame that would relieve the stress on the pivot joint.  The clamp could be pneumatically actuated….. at last an excuse for air on the robot.  Also, the arm could be use to lift the robot off the bridge and act as a brake if there was room to deploy it.

Having the ball scoop on the opposite end of the robot than the direction you are shooting has an advantage in that it extends the rear of the robot to allow you to shoot about a foot closer to the rim and still stay in touch with the colored key.   Also it allows robots to feed the scoop from the open field rather than having to go between you and the rim.

Braking requirement:  Wouldn’t it be nice to drop a foot or be able to lock the wheels once you get to the end of the bridge?  Using the motor current manually or with encoder position feedback seems iffy particularly if there is movement in the bridge that creates transverse inertial forces.

Note: FRC Rebound Rumble Trajectory Data

I decided to run a few simple trajectories of a ball launched at 45 deg at various speeds with and without air resistance.  With air resistance you need about 70 fps launch speed to get from the far corner to the basket (about 55 feet).   Expand the table to see other ranges with different speeds.  The table also has kinetic energy and an rpm for a launch wheel that would have a tangential speed equal to the ball speed. [update 1/16/2012: the kinetic energy values  and weight must be multiplied by approximately a factor of 2 due to weight error in excel sheet]

A launch angle of 45 degrees doesn’t necessarily give the maximum launch range when drag is present.  Typically a lower angle of around 40 gives more range.     An Excel calculation sheet is available here .   It does simple integration to take into account the nonlinearity of the air drag.   Click on the table below to expand it.     Here is a link to Brandon Gunn 2151  nice Excel trajectory generator.

1508a Robot eats tennis shoes while doing the polka

This is funny

http://www.youtube.com/watch?NR=1&feature=endscreen&v=DHf1amWqC9U

Thanks for posting it Gevorg.

Another one is here:

http://www.youtube.com/watch?v=2-66BDQwmfE&context=C33e8c7aADOEgsToPDskJ2QQrmV0PiSOX8PUR75hhS

Irene’s Paper on Vex expansion into Europe

Here is a link to a paper ”Vex Robotics: STEM Program and  Robotics Competition Expansion into Europe”   written by a former 599 student Irene Caro.    The paper was submitted to the Eurobot 2011 International Conference in Prague.   I helped a little on the editing.

Note: Minimum Motor Torque for Turning

I wanted to do a quick calculation for a student Vex robot that has 5 in wheels and is having one rail stalling during a turn.    The stalling could have been predicted with some basic torque calculations.

Using static moment equations you can easily derive the minimum torque to just turn  for a symmetric robot with four direct drive  motors on wheels with radius r .  Legacy three-wire 6.5 inlb motors are assumed.

Define the half spacing between axles as “l” and the half width between wheels as “w”   , the robot weight as W_lbs and the coefficient of friction for a tire side force as u.  Also assume that the weight is evenly distributed on the four wheels and the center of turn is at the cg.  Also w > l so turning can occur.

Then

Input turning moment per wheel = w* torque/r and this must be greater than the moment resisting the turn caused by the side friction forces on the wheel.

Resistance moment = l*W_lb*u/4  .    The factor of 4 converts the W_lbs to normal force on the wheel.

So torque > r*(l/w)*W_lb*u/4

Lets plug in some typical numbers.  r = 2.5 in, l=3.5, w = 7

This gives a required motor torque of  2.5*3.5/7/4*W_lbs*u

or torque >( 2.5/8) * W_lbs* u

or W_lbs <  torque*8/2.5/u

Without omni wheels, u is typically  around 1 or higher and if the robot W_lb is 12 lbs  then the minimum torque

torque_min > 3.75 in lbs

This represents about 60% of the old three wire motors 6.5 in lb  spec torque .       Clearly there is not much margin for any torque losses in the drive train or extra side friction on the wheels or extra weight from a heaver robot or from game objects.  Also any contact forces resisting the turn will easily stall the turn.

Using a 4 in omni wheel in place of the 5 in traction wheels increases the input torque by  5/4 and reduces the u by about 1/3   so we get a combined improvement of  15/4 or 3.75 factor on the required torque.

min_torque_ 4 in omni =  3.75 / 3.75 = 1 in lb or about 15% of the available torque of an old motor.   This is where you want to be in your design.

Note: Robot Drive Train Stalling

The Grant HS team 1508 competed in the Vex Gateway regional at GHCHS on Nov 19th.  They placed 2nd but had trouble in the early rounds because of drive train stalling.   599 teams with similar drive trains were having the same problem.   This was corrected by cutting the Arcade gains in half for the turn channel and multiplying  the forward-aft channel inputs by a factor of 2/3.  A turbo button on the stick was used to restore the gains to unity.

12/5/11 Update:  Seems the programmers were the main cause of the PTC heating.  After careful examination of the Arcade function, the small motors were being driven in opposing direction to the big motors during turns.   Hard to believe… but this happens under the pressure of  getting a robot working the morning of a competition:) 

The drive train on this robot is typical of several 599 robots and copied by 1508 with their permission.   It has two 4 in omni wheels in the front and two 4 in traction wheels in the back.  The wheels are cantilevered and are located on axles that have two bearing blocks holding them that are spaced around 1 in apart.    The width spacing between wheel centers on any given axle is about 16.5 inches and the length spacing between axles is 8 inches.   We also know that the friction of the drive train is very small.  A big 393 motor geared for 160 RPM direct drives the rear wheel and a small 100 RPM motor drives the same wheel through a gearing of 5/3 to match the big motor speed pretty closely.     The front omni’s are also driven by coupling gear train to the rear wheel.

The motors are stalling because of too much current draw  tripping the PTC 4 amp fuse in the Cortex.     The question is why?

Each half of the Cortex drives one big motor and a power expander is used to drive the other two small motors.  This is the best one can do to distribute the load between the three power supply PTC fuses involved.     All the PTC fuses are 4 amp rated and are easily tripped when the big motors stall since they alone can draw 4 amps.  If the driver is actively jerking the stick back and forth then the processor could see between 4 and 8 amps on a single PTC from a big motor.   This occurs when you are moving forward with a high-speed and then cause a reversal command to the motor for fast braking.    The drivers were warned about this and even with smoother driving the motors were still stalling.

It is my theory that the main reason for Cortex PTC  blowing  is a stall of one drive rail during turning.   This is a phenomenon that I have noticed with many robots that are driven with the same type of drive set up including our FRC robots.   It has always baffled me because simple torque models don’t predict this type of behaviour.   Suppose you give a pure spin left command from the stick.   What we notice is that the left drive train (the one on the inside of the turn) seems to stop while the outer drive train keeps the turn going.    We would expect the center of turn to be near midway between the rear wheels but instead it seems to be more about the left rear wheel.   This is not always the case but it happens frequently probably when the left and right drive train powers are not evenly matched.

The only reason one side rail can stall is because of excess torque loads.    We know the motors have enough torque to overcome the side friction forces opposing the turn.   This can be calculated easily from the robot geometry and known or estimated coefficients of friction plus the known Normal forces on the wheels.

SO… there must be an additional drag on an axle caused by a twisting torque from the stalled rear wheel that is digging into the soft tile as it turns OR the wheel is rubbing on the chassis during the turn.   Where else?

The drag torque must be on the order of  3/5*(13.6 + 6.5) or about 12 in lbs less the torque drag of the drive train gears and axles.  Lets say the net is conservatively around 9 in lbs of  torque.    It is hard to imagine a drag of this magnitude coming from extra side forces on the axle caused by a twisting torque from the wheel but maybe so….  Additional testing is required to verify that the wheels are not rubbing on the chassis and to take a more careful look at the center of turn under various turn scenarios.      Anyone reading this…please chime in if you have some idea of what is happening.

11.23.11 Update:

Did a few turning tests to check the center of turn.   With lots of torque the turn center was near the center of the robot between the rear wheels.  As the torque was lowered one rail did stall and the turn center shifted to the inside wheel.   So I think my theory is only partially correct.   When low torque turns are made, one rail will stall and cause PTC heating.   I will do some more experimenting when I get a chance.

As you can see the wheels on this drive train are cantilevered which many would never do.   We have had a lot of success with this configuration.   We pay some penalty in friction loads since with this geometry I estimate that the Normal loads on the axles are increased by a factor of 2… hence also the axle drag.    But we make the trade-off to gain extra 2 inches in width for tipping stability and simple gearing.    We have compared unloaded drive train friction with and without chain drive.   Direct gear coupling won out.   As I mentioned above, it also allows us to direct drive with a 393  160 rpm  motor on the rear wheel.  A 100 rpm motor is mounted adjacent driving a 60 tooth gear that in turn drives a 36 tooth gear on the same shaft as the 393 motor.  This provides a close balance between two different geared motors.    If the wheels are not cantilevered then the 36 and 60 tooth gear spacing cannot be put on axles along the rail since they will interfere with the tires and you would probably have to revert to using chain and having the motors offset from the rail which will probably also raise the cg.

Error in Scissor Lift Equations at Engineers Edge??

Error in Scissors Lift Equations??

bottom actuated

I was looking for some lift equations for our Vex students to use.  I derived some myself but decided to check them against a popular  reference site.

The equations stated in this engineersedge scissor-lift link seem incorrect.

For the bottom actuator the force should be   F =( W + wf/2)/tan(phi)

and

for the center pin actuator  the force should be F = 2*(W+wf/2)/tan(phi)

Where W is the load weight, wf = the total frame weight and phi is the interior angle between the horizontal and the arm.

The proof used  in the site for the bottom force incorrectly assumes that the P force which is the vector sum of F and (W + wf)/2 vertical force is colinear with the arm.   This cannot be since there is a moment about the center pin of lift arm that is caused by the force of the load.   This requires a component of force at the bottom that is normal to the arm at the point where F is applied.  So P cannot be colinear with the arm.

The correct solution is obtained by using the moment equation written about the center pin of the lift.  This gives:

F*L*sin(phi) = (W + wf/2)*L*cos(phi)

or F =( W + wf/2)/tan(phi)

where L is the half length of a scissor leg.

This is easily checked by an energy approach.   If the load W is lifted by dh  then the center of mass of the frame (with weight wf)  is lifted by dh/2.

We know that if the actuator moves a distance of dx the work input is F*dx which must equal the potential energy increase of the lift masses moving against gravity.

So F*dx =(W + wf/2)*dh
or
F = (W+ wf/2)*dh/dx

From geometry, dh/dx = 1/tan(phi)

Hence F =( W + wf/2)/tan(phi);

When the force F is applied to the center pin of the lift the same dh is achieved with dx/2 movement so the force F must be twice as large to raise the masses.

So F_center_pin = 2*F_bottom = 2*( W + wf/2)/tan(phi);

When multiple stages are added the force is simply multiplied by the number of stages.  This follows from the energy formulation since each stage adds another dh but the dx displacement of the actuactor remains the same.

An excellent reference for a more detailed proof is from a paper ”Mathematical Analysis of Scissor Lifts” by H. M. Spackman .  He also wrote a paper

“Mathematical Analysis of Actuator Forces in a Scissor Lift”

12/18 Update: Pivot torque required to extend a scissor lift

If one wanted to apply a torque τ to the center pivot pin to extend the lift rather than use a base force F (similar to the “Chinese Vex scissor lift”) the equation is

τ  = (W + wf/2)*L*cos(theta)  where L is the half length of a scissor leg.

Proof:

Let

theta = interior angle between the scissor legs.

d_theta = a small change in this angle.

          τ = torque applied to the scissor joint

The torque must do the same work that was done by the force F derived above.

τ*d_theta = F*dx =  work done to move the lift a height of dh  against gravity.

So    τ = F*dx/d_theta.

Using half of the base triangle  we know that the base x is

x = 2* L*sin(theta/2)  .

So  we can differentiate with respect to theta

  dx /d_theta = L*cos(theta/2)

We want this in terms of    phi = 90- theta/2      so

dx/d_theta = L*cos(90 – phi) = L*sin(phi)    

Now plugging in for F and dx/d_theta

τ = (W + wf/2)/tan(phi) * L*sin(phi)  or

τ = (W + wf/2)*L*cos(phi) 

Again, if there are N stages then the total torque = N*τ

 

Intake Test RobotC code

This code was used to run the motors for a prototype intake mechanism with a left and right motor.  A single switch was used to start, stop and reverse the motors.  The Vex .5 ucontroller was used.

#pragma config(ProgramType, StandaloneWithWiFi)
#pragma config(Sensor, in1,    button,              sensorTouch)
#pragma config(Motor,  port1,           lt_intake,     tmotorNormal, openLoop)
#pragma config(Motor,  port2,           rt_intake,     tmotorNormal, openLoop, reversed)
//*!!Code automatically generated by ‘ROBOTC’ configuration wizard               !!*//
// Code written by Vamfun for Gateway: Oct 31, 2011
// This program provides a single button control of a prototype intake.
//Push and hold the button for 2 seconds and release turns on the motors.
//Push and hold the button for 2 seconds and release turns off the motors if running.
//Push and hold the button for short interval (2 milli seconds) and reverses the direction.
bool timer_started = false;
bool on = false;
int sw = 0;
int sw_last = 0;
int cmd = 0;

task main ()
{
while(true)
{
sw = SensorValue[button];

if(!timer_started)
{
time1[T1] = 0;
}
if (!sw_last && sw && !timer_started )

{

timer_started = true;
}
if(on &&!sw && sw_last && timer_started && time1[T1]> 2)
{

cmd = – cmd;
timer_started = false;

}
if(sw && timer_started && time1[T1] > 2000)
{
timer_started = false;
if( !on )
{
on = true;
cmd = 127;
}
else
{
on = false ;
cmd = 0;
}

}

 

motor[lt_intake] = cmd;
motor[rt_intake] = cmd;

sw_last = sw;
}

}

Team 1508a Vex Peaucellier Lift Roundup Youtube Video

I finally got around to posting some video of the Peaucellier arm design on youtube.