launcher

@Clio Batali has joined the channel

@Clio Batali set the channel purpose: For all things launcher-related

@Jack Chapman has joined the channel

@Dana Batali has joined the channel

@Brian Hutchison has joined the channel

@Jeremy Lipschutz has joined the channel

@Ronan Bennett has joined the channel

@Finn Mander has joined the channel

@Mike Rosen has joined the channel

@Adrianna Carter has joined the channel

@Samantha Rosen has joined the channel

@Alex Larson Freeman has joined the channel

@Will Hobbs has joined the channel

@Jon Coonan has joined the channel

@Kenneth Wiersema has joined the channel

@Enrique Chee has joined the channel

@Rose Bandrowski has joined the channel

@Kaedric Holt has joined the channel

@Andrew Peterson has joined the channel

@Paul Vibrans has joined the channel

For all working on launcher: Make sure we understand this! What types of wheels work well (look at past games and Chief Delphi, etc.)?

Thanks.

Do we want to test orange wheels? Green wheels were 30A and orange are 40A. The A-scale is a durometer scale.

Do we have orange wheels ? So what does a durometer scale mean ?

A durometer measures the hardness of a material. The A-scale is used for softer plastics. I am not sure if we have orange wheels or not.

We have one small orange wheel

y primary concern with respect to the launcher is that we have not yet prototyped the mechanism by which the agitator feeds the shooter. Seems like this aspect has, so far, fallen between the cracks because we've divided these two subsystems into separate groups.

I understood from Alex that the plan is to try to feed the launcher from "behind" rather than from the side. This makes a lot of sense to me but has serious volume-management implications that must be validated poste-haste.

Current planning is to feed the launcher directly from the carousel. My layout shows it will work with one ball left in the pipe when the bin is empty

That solves on of our problems, but placement of the launcher becomes an issue, unless we use something similar to your design.

I don't really have a design. I just have a 2-D layout that shows the carousel can feed a launcher directly

paul: in your design is the ball fed from side or back (orthogonally or in-line)

In line

I grabbed Paul's design and

1) stashed in the shared steamworks/launcher subdir

2) imported it into my robot-sketch file (avaiable here: http://a360.co/2jgzHUO

Then i moved it around a bit, just to get a sense of scale and orientation. The tricky bit is to visualize the exit path of the ball and how/whether it interacts with our other robot-volume requirements.

There are a small number of potential alignments/positions available and I'm not suggesting that this is the best one...

this alignment choice points to the fact that the ball collector (bin) might need to be oddly shaped/sculpted. It also suggests there may be interference concerns with the intake system. I also looked at the shoot-sideways option and that would require that we move the gear intake to the same position as the inteke. I beleve this was the choice made by the quebec team in the 100h video posted elsewhere.

Thx Dana, that really helps with the physical visualization

@Chris Mentzer has joined the channel

@Riyadth Al-Kazily has joined the channel

@Timo Lahtinen has joined the channel

I want to take about the orientation of the shooter at the meeting, and which way we're shooting

@Lia Johansen has joined the channel

@Jack Stratton has joined the channel

@Michael Nelson has joined the channel

@brian_bonifaci has joined the channel

@Kaedric Holt, @Andrew Peterson: reminder to finish the CAD's for the launcher

I'll finish in the morn

@Binnur Alkazily has joined the channel

@Kenneth Wiersema can you do that edit to the tracks so we can finish the model?

You guys can go ahead and change it. The edit to the tracks that I was going to do was to fix the heights, but that can be done later.

K

@Kenneth Wiersema , when will you have the wood order to Robert ? When you are done please share with me directly also.

I'm planning for either tomorrow morning or tomorrow afternoon.

Why not tonight ? I would like to be done with ordering .

People working on the ball feeder need to be careful with the location of the carousel motor. It has a preferred direction of rotation noted on the drawing. I believe the life of one of the bearings on the worm is very short when run in reverse for long.

Wood is in. @Will Hobbs , which CNC are we using ? Did you speak to Michaels ? If you are going to cut the wood with Michaels please arrange time with him at his convinence which may not match our build session time and day. I suggest the launch team do it in the mornings with Michaels. Otherwise lets cut with our X-carve.

I will let the launcher team decide which CNC they want to use

I am willing to use either one

If we do decide to use the xcarve then I would like to do some test cuts

@Alex Larson Freeman: @Kenneth Wiersema what do you guys think

I asked for more wood than what we need for two, so there is some room for error. I vote for using the x-carve just so we can get people acclimated to it. There's plenty of room for error.

You will need to use the table saw in the wood shop to cut the piece of wood down. Our table saw is much to small to cut those pieces.

As long as we make sure the X carve is reliable enough then I'd say we should get used to it

@Jim Carr has joined the channel

@Will Hobbs: did you ever get word from Mr. Michaels on the use of his table saw, if not, wouldn't the jig saw be fine for cutting the wood.

The jigsaw would be a really rough cut

He said he could do Friday

Before or after school?

Give me a time and I will make sure it works with him

Right after school ends friday? 11:35

Don't forget we are meeting at 12 pm for leadership and I will not be available at 11:30 am. So 11:35 is a no. Pickup the wood Friday morning at 8:00 am if you want.

@Kaedric Holt, @Andrew Peterson What did you guys do to the Launcher CAD file? I fixed the rails, but I can't get the file to have the updated ones.

So what have you guys decided on the wood and with Michaels ?

So I think I got the updated file for the tracks, but it still won't fit.

@Will Hobbs: does Friday morning work for Mr. Michaels?

I will check but I think it should

@Kaedric Holt: I didn't know that the tracks didn't fit, all I was doing was to get the ridges to touch the ball. Anyway, why didn't you guys just import all of the pieces into the drawing so we out edit the pieces in the files and then get the new files in the cad?

@Will Hobbs: Good, so tomorrow morning at 8:00 to cut the pieces.

I am double checking with Mr Michaels

Okay

I won't be in my room till 8:15 am on Friday. So what will the plan be ? Use Michaels bandsaw only to rip the 5 x 5 ft. board into what dimensions to fit on our x-carve which is 4 x 4 ft. ? I suggest you don't cut the 2nd 5 x 5 ft board until you know exactly what your plans are. Please let me know if you need me to be in my room at 8:15 am on Friday.

My plan was to cut the board into fourths, as cutting it out should fit on one of the 2.5 by 2.5 foot pieces, with ~55% of the board being waste. I asked for more in order to give us some room to change the design and room for mistakes. We shouldn't need the second board, but I'm thinking that we might need to use it at some point.

Ok. 55% seems like a lot waste .

Is there a better way to maximize the use of wood ?

We could probably optimize it, just a calculation done to get the maximum area needed,.

I believe that that is unused not waste

And the program will automatically nest the components to have the least waste

Thats what I meant, the amount of wood not used by the parts.

Ok

So let me know by 10 pm tonight if I need to be in my room at 8:15 am Fri. For you guys to pickup the wood .

If you can't cut it with Michaels by 12 pm then please arrange with Michaels to cut at 2 pm . I want all mechanics to be in the room from 1 to 2 pm . We have some stuff to cover . Will go over at leadership at 12.

Okay, Will's the one who's communicating with Mr Michaels.

@Kenneth Wiersema Is the final CAD of the launcher in fusion?

More or less, the parts should be all done, but I was running into a difficult updating a part in the built form.

what is the most up to date version?

And is it final enough to prep CNC the pieces tomorrow?

The most up to date version is the Launcher, and the pieces should be done.

the yellow and blue one?

Yes, the rails need to be updated, but aside from that there shouldn't be a problem unless Kaedric hasn't told me something

I need the updated rails

I am trying to get parts all ready to CNC

All of the separate part files are done, they just did something weird with the main file.

That may have been me

Is it rail or rail for launcher?

Rail for launcher, the other one is a file that Paul gave us

are all of the pieces cut out of the same material?

I believe that all pieces except for the tracks are in

The tracks do need to be edited though to fit the curve of the base.

then that needs to get done ASAP

Like right now

We need those files at the beginning of the meeting tommorow and I am getting them downloaded now

I did not design them, Kenneth did. I'm not sure how to fix it

@Kenneth Wiersema Did you fix it already?

@Enrique Chee: you do not need to be there at 8:15

@Kenneth Wiersema: we will have to go sometime after school tommorow probably immediately after school

I should be able to help if you want.

Like I said I won't be around after school until 12 pm when we meet with leadership so swing by after 5th period during break to get the wood out of the robotic room . We can store outside my room so you guys have access to it at 11:35 am . Makes sense ?

@Will Hobbs: All of the pieces are going to cut from the same material, and I did fix the tracks so that they hold the ball, but I don't get what Kaedric said about fitting them to the curve of the base?

Look at the launcher model and try jointing the two pieces .

I remain very concerned about the decision to disallow the ability to change the Launcher speed at run time. I'm unclear about the reservations using the Zaxis on the controller for this but agree that we shouldn't just implement it anyway without concurrence.

One suggested alternative is to use the SmartDashBoard to read the default value and set it that way, perhaps only during initialization.

The SmartDashboard documentation is here: http://first.wpi.edu/FRC/roborio/release/docs/java/

You'll see some examples of writing (but not reading!) in Climber, Drivetrain and Intake.

Consensous with the drive team is that we don't want a speed controller for the launcher as that would add an additional level of complexity for the mechanism controller. If we can't shoot one game, we fix it for the next.

What about a speed "trim" that moves speed up or down tiny steps to tweak performance.

the idea s that if we want to run n "speed mode" (where we have a PID controlled velocity) we need a motor encoder. The theoretical value of running in speed mode is that as the ball applies load to the motor, the controller will add more voltage to reach the target velocity)... I'm not sure if that's the point under discussion here. Presumably we need to choose a speed at which to run the launcher whether we have an encoder or not. As soon as that speed can be controlled by the software, it's a trivial thing to to expose or hide such a knob for drivers or tuners to employ.

If the point is merely: if the drivers don't want a knob, then certainly there'd be no need to use it.

To back up what Dana said, without closed loop control of the launcher motor, rapid deployment of fuel balls will slow the launcher wheel down, resulting in missed targets.

Driver station "adjustment" of the speed should be implemented during development to help us dial in the right speed (and maybe even adjust it on the practice field between matches, as parts wear). The drivers during a match probably should not be adjusting the speed, so the setting should be something not easily changed on the smart dashboard.

I envision a pair of buttons that are calibrated to add or subtract approximately 3 inches of range each time you poke one. Sort of like the +/- control on an automotive cruise control.

I like Paul's ideas, but I want to talk about this at the meeting.

Guide rails and bearing plates for the second robot will be delivered Sunday.

there is some question in programming regarding the intended trajectory of balls from the launcher. Referring to the images below, i see four potential tractories...

#1: due to the curvature of the launcher egress, one might conclude that the intent is to cross the body of the robot and target the boiler represented by the blue circle. Here, then we'd need to park the robot with the opposite side parallel to the boiler wall.

#2,3: if the launcher is twisted so that the egress is at an angle (toward the viewer in pic below), Then, I suppose it could be suggested that we're intending to target some distance along the back side of the robot - represented by the green or purple circles. Here, we'd park the robot with the front side touching the boiler lob the ball in an odd angle into the boiler stack.

#4: if the launcher had less outgoing curvature, it might be possible to output the ball on the same side of the robot - represented by the red circle.

In last night's test, i think the intent is #2 (to target the purple (or green?) circle). I observed the ball coming out with a weird twisting spin which, in my intuition, derives from the angle between the gravitational field and the tangent to the ball trajectory. My sense was that the trajectory and the twist may be problematic for our goal of high precision.

I guess I'm wondering if there are alternate ways to tune the ball's ejection path & spin. Or perhaps I'm premature in inferring anything, since we're literally on our very first steps out of the cradle. I do understand that for this launcher positioning, the goal is to make it really easy & fast to find a canonical field location - one that doesn't require "parallel parking". If it turns out that the ball-spin that arises due to our goal to target the green/purple circles, we may have an additional option - of parking perpendicular to the walls adjacent to the boiler.

The launcher geometry is based on a purple circle shooter. Yesterday it looked to be set up as a blue circle shooter. We could cut new rails with longer or shorter arc to accommodate better blue circle or red circle performance respectively. I was told yesterday that the team had decided to be a green circle shooter, which I think will be difficult.

@Paul Vibrans @Dana Batali this takes agile development to the next level! :slightlysmilingface: And, @Riyadth Al-Kazily is wondering if you considered using triangles :wink:

Yesterday the target was the green circle. Launcher team and captains what is our target ? color Circle ?

From what I believe, it was the green circle but I may be wrong. @Kenneth Wiersema ?

The plan was to use the green circle, but the only one that the Launcher can't physically do right now is the red one. I think the decision should be more reliant on the ease of driving the robot over to the shooting position.

Yes although the closer it is to the wall may be better, less of an arc for the ball to change course in thus being more accurate (again, if my thinking is correct).

The red circle requires the rails to be cut off a little at one end or the other. That might stop them from being used on the blue circle as there could be problems with infeed.

From what I saw from testing, infeed shouldn't be too much of a problem as the launcher was set pretty far that way and there wasn't a problem with the launcher when we tested the arigator.

If the gap between the agitator floor and the rail ends is too great I fear accuracy will be reduced.

my sense is that both green and purple may impart a weird spin… that neither blue nor red would

As long as the curve or slider has a consistent break it should not matter.

perhaps it’s not consistent?

on another note, with the way the field is shaped, trying to park angularly (blue circle, short side of the bot) would probably mean more time spent lining up rather than parking the (conveniently boiler-sized) back of the robot straight in to go for the green circle.

if our precision is equivalent in all cases, then parking time wins… I guess I’m currently questioning whether green and purple will be able to deliver… Perhaps it’s just a matter of more tuning...

@John Sachs has joined the channel

@Brian Hilst has joined the channel

We need build to buy this or build a jig plus buy a heating plate for our polycord . Can someone research where to purchase and how much ? https://www.youtube.com/watch?v=1WYlhu-0I

https://www.mcmaster.com/#belt-welding-kits/=16elm44

too expensive, please reearch where to get for less or get the parts separately for less.

Nevermind about buying. They want a ridiculous amount $2000.

http://www.fennerdrives.com/welding-kits-and-components//Eagle-Freestyle-Welding-Kit/

1crazy $2000

Paul, can we build a jig ? Please !!!

We need to fuse polycord belts without taking apart intake system. https://www.youtube.com/watch?v=Ggsb2yunCss

We might be able to fuse round cord in place. Fusing flat belting with some initial tension while tensioned belts are close on either side is difficult without a fixture that is very elaborate.

Looking at the launcher code, I think I see a bug.

private boolean isLauncherAtSpeed()
{
final double epsilon = 100; // allow 100 RPM of error.
double speedTarget = SmartDashboard.getNumber("LauncherTGT", Launcher.DEFAULTLAUNCHERSPEED);
double speedActual = mlauncherMotor.getSpeed();
if (speedActual >= speedTarget - epsilon || speedActual <= speedTarget + epsilon)
{

Looks like that if () should have an AND instead of an OR.

Right now it will always resolve as true.

Also, I need an explanation for how this actually works. The LauncherCommand calls the following on 'end()':

protected void end()
{
mlogger.notice("End (" + mstate + ")");
mlauncher.setLauncher(LauncherState.OFF);
}

But when I look at setLauncher(), it doesn't look like the state LauncherState.OFF is actually used to stop the motors. They are still set to the speedTargets at the end of the method:

public void setLauncher(LauncherState state)
{
if (initialized())
{
if (mstate != state && state == LauncherState.ON) // Occurs when state switches to on from any other state
{
mstartupCount = 0;
mlogger.debug("startupCount = 0");
}
mstate = state;
double speedTarget = SmartDashboard.getNumber("LauncherTGT", Launcher.DEFAULTLAUNCHERSPEED);
double agitatorSpeedTarget = SmartDashboard.getNumber("AgitatorTGT", Launcher.DEFAULTAGITATORSPEED);
double speedActual = mlauncherMotor.getSpeed();
SmartDashboard.putNumber("LauncherACT", speedActual);
String msg = String.format("%.0f / %.0f", speedActual, speedTarget);
SmartDashboard.putString("LauncherMSG", msg);
mlauncherMotor.set(getLauncherSpeed(speedTarget));
magitatorMotor.set(getAgitatorSpeed(agitatorSpeedTarget));
}
}


Hey Riyadth, when we set the motor speeds we use an enum of states to determine what numbers are returned in the getLauncherSpeed() and getAgitatorSpeed() methods. "speedTarget" in those two methods are not used when the state is in OFF mode. They should be just returning values of zero. However, in different modes such as ON, the methods would return values based on the "speedTarget"

Ah! I see that now. OK, although it is a bit confusing. Or maybe it's just late at night. :-)

I measured the tread diameter of the launcher wheel that was removed and it was 4.855". My design layout for the launcher parts that are installed in the robot now used a wheel diameter of 4.85", which was the diameter of an unused wheel. My inspection of the removed wheel showed edge wear, edge roughening, and accretion of plastic from balls all across the width of the wheel. Accretion is greatest at the edges and not uniform at the center of the tread. The plastic accretion from balls is noticeably slicker than the tread of a clean wheel. The wheel needs to be cleaned without wearing it down. Scraping the wheel with a fingernail worked but was slow.

The Blue Alliance feed shows the launcher working very well. Great job team!!

Thanks!! Thanks to your awesome design and help guiding us on building it though :)

Thank you Paul for everything. The launcher is holding up well.

@Cruz Strom has joined the channel

At Auburn Mountain View we started the tournament with a new shooter wheel. At Glacier Peak we started the tournament with a shooter wheel that had been cleaned, maybe not enough. Do we have a new wheel that we can put on in Cheney or should we spend the time trying to really clean the old one?

It's very hard to replace and we have no unbag time, I think it's more viable to clean it

(Seemed to be working pretty well on saturday if my memory serves me well, we should clean it between days/matches)

We will need to really clean the wheel. It might be easy enough to replace it with a new one (I did not work with it so I do not know).

@Kenneth Wiersema

Not easy

we have to take the whole thing apart to do so, which could potentially involve human error - feels risky.

Nevermind then, we just need to remember to clean it every day.

The original practice wheel should be somewhere. I cleaned it somewhat. If it can be found we can use it to test cleaning methods. I'm not sure scraping the wheel with a thumb nail or rubbing it with an eraser is the best we can do.

The wheel we have now is holding up really well in comparison to the practice

^Side note

We do have new ones. But I think we should clean first . Could it also be wear and tear on the bearings ? Should we lubricate certain moving parts ?

Hmm good question, Kenneth would probably know best. I did not anticipate that.

I recommend lubrication. My thoughts (in #programming ) are that something changed in the mechanism, and my theory is that increased resistance would be one explanation.

agreed. Or less resistance since the ball is going higher than normal?

The ball is going higher because the wheel speed is higher (more energy). The wheel speed is higher because the "recovery" from the previous ball is overshooting the target speed. This could be due to lower resistance, but could also be higher resistance. With higher resistance, the algorithm adds more voltage to the motor to overcome the friction. This could cause the system to end up going too fast if the voltage isn't shut off quickly enough.

Makes sense

Okay then I think it's more likely it's higher resistance.

And the voltage is shut off by an algorithm that has parameters set for the original condition of the shooter. If we change those parameters, we could probably correct the overshoot. But if the friction (or whatever) is continuing to change, then the new parameters will not be good for long.

Okay. We'll have to work on this at the next competition.

The weird thing I observed was that it was fine during auto but not during teleop?

Any idea why that is (of course we're not shooting for long during auto maybe my time frame of watching is just too short to see much error)

It has a lot to do with the shot-to-shot time, and that may be a little slower with auto (with only 10 balls in the hopper) vs. a full load of balls. If the wheel settles down in between shots, then the problem is less noticeable.

Okay

I'd need to take a look at the launcher to get ideas on what's happening, but I don't think the resistance change would reflect what was changing, as wouldn't the resistiance changes be cyclic on the rotations of the bearings, and from what I saw from the stands it was more in periods of 3 to 4 balls of overshooting then going back to being accurate. The wheel isn't that bad to remove and replace, but the shaft does have a hard time coming out, so I think the plates are miss-alined, which could be easily fixed, but it would require the shooter to be re-tuned. I would put a wheel replacement at 30 minutes-1 hour, as it took 30 minutes last time. Replacing the wheel is still the same problem as the extra resistance, the changes should be negligible due to the high rpm of the motor.

It might be possible to speed up or slow down the agitator a tiny bit, to get the balls to touch the flywheel when it is at a slower speed. But that would probably be a touch adjustment.

Paul mentioned that we didn't check on the status of the 'Peacemaker' roller in the hopper. Maybe it has stopped making peace?

Hey have we investigated the launcher at all since you guys got to the competition?

Any problems found / fixed?

The encoder on the shooter shaft had become dismounted. We fixed that and shooting is more consistent.

Yay!

Thanks paul

@John Sachs has left the channel

@Jon Coonan archived the channel