Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: OT: Repeatably lobbing "projectiles"
Date: Fri, 22 Nov 2024 19:24:06 -0700
Organization: A noiseless patient Spider
Lines: 191
Message-ID: <vhrecf$1dvpp$1@dont-email.me>
References: <vhmm2k$hpg1$1@dont-email.me> <vhn6hv$kcv9$1@dont-email.me>
 <vhn7p9$klsd$1@dont-email.me> <vhn9cs$kvbs$1@dont-email.me>
 <vhn9u8$klsd$3@dont-email.me> <vhngkm$m5fp$1@dont-email.me>
 <vhnr2o$nurs$1@dont-email.me> <vhokk1$rvpm$3@dont-email.me>
 <vhorqs$t438$5@dont-email.me> <vhp11p$119hi$2@dont-email.me>
 <vhp69q$12dgb$2@dont-email.me> <vhqijd$19o2c$1@dont-email.me>
 <V250P.7783$hgYd.3742@fx41.iad> <vhqpra$1b1e7$1@dont-email.me>
 <qh62kjpel75ub9hgo24kctq9clrq5shs4q@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 23 Nov 2024 03:24:16 +0100 (CET)
Injection-Info: dont-email.me; posting-host="01962a914581412c1fe91addb5218a72";
	logging-data="1507129"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pBqsp6/bAgCO6Hv8wS98d"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:jTNQJ9b+2x8LYhrE+ihvZoExs5E=
In-Reply-To: <qh62kjpel75ub9hgo24kctq9clrq5shs4q@4ax.com>
Content-Language: en-US
Bytes: 10584

On 11/22/2024 5:22 PM, Jeff Liebermann wrote:
> On Fri, 22 Nov 2024 21:37:35 +0100, Jeroen Belleman
> <jeroen@nospam.please> wrote:
> 
>> On 11/22/24 20:36, Anass Luca wrote:
>>> bp@www.zefox.net wrote:
>>>> Don Y <blockedofcourse@foo.invalid> wrote:
>>>>> Most "guns" just want to achieve a "maximum" (range,
>>>>> load, etc.)
>>>>
>>>> Not sure I understand what you're getting at here. On
>>>> the face of it that statement seems mistaken.
>>>
>>> You are interacting with "Don Y".  If you go review other postings
>>> where "Don Y" has initiated a thread like this one you will find that
>>> the "Don Y" poster quite effectively trolls the group every single
>>> time.  The initial post is always ambigious and seriously lacking in
>>> necessary details, such that 234+ wrong possibilities could be seen by
>>> readers.  And as others in the group request details to try to gain an
>>> understanding from the vague, detail lacking initial post, they are
>>> slowly tricked out over the course of days and plural postings from
>>> "Don Y", intermixed with numerous random asides to maximize confusion.
>>> Meanwhile, as the supposed details are trickled out, the apparent
>>> requirements needed also shift as posters appear to gain any
>>> understanding in order to keep the responders in the dark and allow the
>>> "Don Y" trolling articles to continue to troll everyone who responds.
> 
>> That is unfortunately a rather accurate characterization, I concede.
>> Jeroen Belleman
> 
> You give up too easily.  Most people can solve an engineering problem
> if they are given accurate specifications and objectives.  In my
> limited experience, I've never received all the necessary information.

Engineering is not just about solving problems but, rather, about identifying
the problem to be solved.

> In the few times when I did receive accurate specifications and
> objectives, the client was made endless changes and "enhancements"
> until little clue as to what he wanted and somewhat less on what I was
> expected to accomplish.  Over the years, I've deduced that this
> typical and that Don Y is a good model for my typical client.

Note that my stated requirements haven't changed.  I've brought
up *issues* with various proposed solutions -- expecting their
presenters to refine their solutions to address these issues (which
may not be part of the problem but, rather, their proposed solution)

> Still, something can be done with the muddle.  The first step is to
> determine what problem Don Y is attempting to solve.  Don Y does a
> tolerable job of providing a partial solution, but without a clue what
> problem his partial solution is intended to solve, his partial
> solution is at best a moving target.  My guess(tm) is that it does
> nothing useful, so this initial step can be ignored.

The actual problem isn't important.  If you can't think in abstractions,
then reify my stated problem to something that you can wrap your head
around -- to overcome the limitations of your imagination.

Some examples:
- design a cornhole playing robot.  Or, bocce.  Or horseshoes.
- design a robot that "shoots baskets" (basketball)
- pitch pennies
- toss coins into bottles at a carnival (win a teddy bear!)

All are in the 0-20 ft range.
All toss projectiles
All *LOB* those projectiles
All expect those projectiles to land where targeted

None of these are the problem I want to solve but they give you
something to CONSTRAIN your imagination (and, sadly, limit
the ideas you are likely to come up with!)

> The next step is to determine what we have to work with.  Since there
> are no specifications except for 20 ft range, the launcher and
> projectile can be almost anything.  A 40 ft diameter ball would do the
> job and never miss the target.  However, that's probably not what Don
> Y is expecting.

Specifying the projectile to be a regulation basketball and fastening
a professional basketball player with a great freethrow rate to a
platform would also be a solution.  (Do you really think that would be??)

>  A smaller ball, with a 20 ft steel wire attached,
> would also work.  The 20 ft steel wire limits the flight distance to a
> 20 ft radius.  Then the steel wire become taught, the small ball fall
> straight down and into the target receptacle.

I've not said there is a receptacle.  If your mental model is that
of a basketball playing robot, you would limit your imagination
to those constraints THAT YOU IMPOSED ON YOURSELF.  I.e., a basketball
analogy implies the target is ~10 feet off the ground -- meaning the lob
would have to be at least that high.  It also means the projectile must
enter the target area (which I've merely specified as a distance as
*I* can adapt a particular solution to ensure other constraints are
met in the trajectory -- why further constrain YOUR thinking by
enumerating them")

>  Elevation and azimuth
> can be stabilized by spinning the ball, switching to pointed
> projectile, or both.  Using two steel wires to form a triangle, will
> eliminate the need for spin or fin stabilization.
> 
> At this point, I usually would present my worst and most ludicrous
> ideas to the client, who would immediately being crying, screaming or
> yelling.  Since that clients endless changes and meddling have dragged
> the estimated delivery date far too close to the deadline, the client
> has to select something.

Clients are usually lacing n technical ability.  They don't know
what is likely possible so are clueless as to how to constrain their
requirements.

We designed a printer at a firm many years ago.  The power supply requirements
were pretty significant; a variable 0-20A load switching at ~400Hz, small size,
low cost.

The guys designing the power supply opted to put a LARGE *battery*
in as the output filter.  Met the stated requirements -- because no
one thought to add "must not contain consumables" to the spec!

The folks writing the specification didn't anticipate that there would
be a technical problem in meeting the power requirements.  And, didn't
anticipate that the engineers would resort to something "consumable"
to solve that problem!

> It's at this time that he gets serious about
> defining specifications (with my assistance).  The rest of the project
> is comparatively easy and consists mostly of lost weekends and lack of
> sleep.

My requirements are unchanged.  But, solutions have to address the
other issues associated with their implementation.  How do you imagine
(unattended) LOADING the mechanism?  Calibrating it?  Reproducing
it?

You could suggest creating an overhead mechanism to which you
"hand" the projectile and let it shuttle the projectile to
the target coordinates.  That *may* be acceptable.  But, now you
have to address the issues of fabricating and calibrating that
mechanism -- along with the "hand-off" mechanism that allows it
to know how/where to accept the projectile from the launcher.
Who should create the specifications for this new contraption?

How many degrees of freedom in the solution space should be constrained
before posing a question?  Anyone ever have a client ask "how much will
that cost me? or "how long will that take?"  Gee, if those things are
important to you, why didn't you SPECIFY them, up front?

Ans:  because the client would like to be able to evaluate the quality
of a range of unconstrained solutions instead of limiting you to
some arbitrary constraints ("Gee, if your budget was N+1 dollars
or your schedule 3 days longer, I could have offered you a great
solution!  Instead, I'll simply 'no bid'...")

One of my favorite puzzles (interview questions):
- you have three bottles (I always suggest old-fashioned Coke bottles)
- you have three chopsticks
Arrange the three chopsticks so they don't touch the ground/table.

INVARIABLY (at least, every time I have posed it), the respondent
stands the bottles up, arranges them in an equilateral triangle
and then bridges the gaps between adjacent bottles with individual
chopsticks.

Hardly imaginative.

AND, suffers from assumptions of constraints THAT WERE NOT IMPOSED!

Next, remove one bottle and repeat the challenge.
========== REMAINDER OF ARTICLE TRUNCATED ==========