Team Update #18

[Ether]

Originally Posted by jspatz1

1. 0.586 ft.

2. 474 N

Yup.

[jspatz1]

Originally Posted by Ether

Yup.

WooHooo! I've still got it!

[Chexposito]

to trip it, you have to be traveling ~.39 meters per second or ~1.28 fps for a 1 kilogram minibot using EBE assuming no friction, the minibot is not back driving, there is no rotational inertia, and pretty much everything else.

pretty much if you're not going that fast you are not winning anyways (~15 sec with more rounding and constant acceleration)

[Ether]

Originally Posted by Chexposito

to trip it, you have to be traveling ~.39 meters per second or ~1.28 fps for a 1 kilogram minibot

I doubt you would ever successfully trigger the switch with those numbers.

Please explain your reasoning and show your calculation.

[JesseK]

I'm not so sure it's that simple Ether. Such a simple model isn't explaining what's being seen on the field. Additionally, why a 1/4" stop? Why not 3/4", which may be just as valid a distance that prevents the sensors from triggering (I'm assuming the plates are ~1" apart, which may be wrong since I still haven't examined the field drawings).

Additionally, how does your model take into account any mechanical (dis)advantage that plate exerts due to binding on the bolts opposite the minibot's impact point?

[wireties]

Originally Posted by Mike Copioli

I am well aware of the greater purpose here....are you? It's to inspire. It is not inspiring to work as part of a team, to inspire others to strive for excellence and success only to have that under minded by a poorly documented field condition that changes the outcome.

I hope this all gets resolved in a way that satisfies everyone. BUT this is a good life lesson for aspiring engineers. We have to respond to technical specifications all the time that are vague (where our potential customer knows much less about the problem/solution domain than we do). On some level, it is our responsibility to request clarification BEFORE designing/building a solution.

And BTW Linux == Embedded, my company has put it on several satellites and on some tiny tiny platforms. Linux does soft real-time quite well these days and is closing in on hard real-time performance.

HTH

[Ian Curtis]

Originally Posted by JesseK

I'm not so sure it's that simple Ether. Such a simple model isn't explaining what's being seen on the field. Additionally, why a 1/4" stop? Why not 3/4", which may be just as valid a distance that prevents the sensors from triggering (I'm assuming the plates are ~1" apart, which may be wrong since I still haven't examined the field drawings).

Additionally, how does your model take into account any mechanical (dis)advantage that plate exerts due to binding on the bolts opposite the minibot's impact point?

I think the point is that that is a lot of force. If it really requires 2-4 newtons to trigger the plate, 474 newtons should definitely trigger the plate. It obviously does not always do this, so there are other issues at play like you said.

474 newtons is the equivalent force of an FLLer (~100 pounds) standing on the plate.

[Paul Copioli]

Originally Posted by Ian Curtis

474 newtons is the equivalent force of an FLLer (~100 pounds) standing on the plate.

... or Karthik.

Sorry, I couldn't resist.

[Ether]

Originally Posted by JesseK

I'm not so sure it's that simple Ether. Such a simple model isn't explaining what's being seen on the field.

It was never intended to model or explain what's being seen on the field. Please re-read the disclaimer at the bottom of my original post. All it shows it that minibots which DO successfully trigger the tower are exerting way more than 4 Newtons.

Additionally, why a 1/4" stop? Why not 3/4", which may be just as valid a distance that prevents the sensors from triggering (I'm assuming the plates are ~1" apart, which may be wrong since I still haven't examined the field drawings).

AFAIK, we have no official drawing or specification of the switch mechanism, but colt527 provided a sketch as an attachment to this post which shows 1/4" travel required to trip the switch.

Additionally, how does your model take into account any mechanical (dis)advantage that plate exerts due to binding on the bolts opposite the minibot's impact point?

It doesn't, and wasn't intended to.

[Ether]

Originally Posted by Ian Curtis

I think the point is that that is a lot of force. If it really requires 2-4 newtons to trigger the plate, 474 newtons should definitely trigger the plate. It obviously does not always do this, so there are other issues at play

Precisely. I couldn't have said it better myself. In fact, I didn't :-)

[wireties]

Originally Posted by Cory

Or FIRST should fix their system. Why should the customer fix a part that came to them out of spec? We are paying for something and if FIRST doesn't deliver the onus should be on them to fix the problem, not on us to work around their broken implementation.

The teams, of course, pay FIRST to compete. In that sense the teams are customers. But FIRST is largely a set of volunteers, at least the staff at the regional events. If we think of this game as a simulated engineering exercise, FIRST is actually the customer (having provided a specification).

Our team, like most, did not query the "customer" about a vague requirement. This is totally "our bad" though one hopes FIRST does not intentionally put out vague specs. Our first heavy-ish 4 second minibot triggered the sensors every time in week 1 at The Alamo but our evolving optimized minibot design is now gonna be a little stronger and stay in contact with the plate a little longer than originally designed.

[Chris is me]

I think Cory's point is that FIRST shouldn't be let "off the hook" every time they do something at the expense of teams just because it's a volunteer organization. We do still pay to compete, after all.

[JesseK]

Originally Posted by Ether

It was never intended to model or explain what's being seen on the field. Please re-read the disclaimer at the bottom of my original post. All it shows it that minibots which DO successfully trigger the tower are exerting way more than 4 Newtons.

Sorry to be pedantic, but...

You're basically saying that it's OK to imply an assumption for the calculation and then ignore the assumption for the conclusions of overall system characterization. You did this with your Mecanum analysis a few months ago as well.

Originally Posted by Chris Is Me

I think Cory's point is that FIRST shouldn't be let "off the hook" every time they do something at the expense of teams just because it's a volunteer organization. We do still pay to compete, after all.

Which would probably be a great broad stroke to paint, yet the whiners haven't proposed a solution. The fact of the matter is, Physics beat the crap out of FIRST's system during Week 0 and Week 1 by exposing a severe flaw. Why are we complaining that FIRST had to adapt to it? Why should they put out a specific spec in the form of a rule that teams WILL simply complain about regardless? The referees already made concessions to manually score the towers even though it wasn't in the rules.

Honestly, the only concession FIRST can make at this point is to give us dedicated MINIBOT time on Thursday. 4 teams at a time can have their MINIBOTs climb, uninhibited, yet with the real field's triggering/scoring system. If it's dedicated minibot time, then every team should be able to test their ascent and triggering 4-5 times in an hour or two.

[wireties]

Originally Posted by martin417

As an engineer, I work to engineering specs. If I meet those specs, I expect to be paid. You can imagine that I might be a wee bit upset if I were to design a product that meets the customer's specs, deliver that product, and be told "I'm not paying you because the product didn't do what I expected it to do". If your specs are not written clearly enough, that is your fault, not mine.

This is a good lesson for the students and for mentors that do not typically address similar challenges at work. Think more like an engineer that owns the company or an engineer helping to form a response to a proposal. Taking a risk (being able to satisfy) a vague requirement from a customer is NOT a good idea. You very well might not get paid and it does not matter if one is correct or not. In this case, the customer (FIRST) supplied a vague spec but did provide a compliance test.

If the specs are not written clearly, it is ALSO our responsibility to request clarification or we risk NOT getting paid (or tripping the sensor).

[Chris is me]

Originally Posted by JesseK

yet the whiners haven't proposed a solution.

Proximity sensors and light sensors are two common proposed solutions.

Personally, I don't see what's wrong with a photo finish here. Yes, "instant replay" is a dirty word, but it would clearly be the best.