Re: Team Update #18
 

Yup.

Re: Team Update #18
 

WooHooo! I've still got it!

Re: Team Update #18
 

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)

Re: Team Update #18
 

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

Please explain your reasoning and show your calculation.

Re: Team Update #18
 

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?

Re: Team Update #18
 

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

Re: Team Update #18
 

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.

Re: Team Update #18
 

... or Karthik.

Sorry, I couldn't resist.

Re: Team Update #18
 

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.

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.


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

Re: Team Update #18
 

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

Re: Team Update #18
 

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.

Re: Team Update #18
 

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.

Re: Team Update #18
 

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.

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.

Re: Team Update #18
 

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).

Re: Team Update #18
 

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.