not OT : fear

On 07/31/2022 12:38 AM, Don Y wrote:
> We have a project in which we provide students with a laptop that allows
> them to develop a virtual robot and have it compete, on screen, with other,
> pre-made virtual robots.  They can sit in their bedrooms, libraries,
> classrooms, park benches, etc. and learn how to develop algorithms to
> control their "robots" (autonomously).  They can test those algorithms
> against other strategies that have been pre-delivered.  They can test their
> strategies against those of their friends/classmates.

How much room does a robot car chassis take up?

https://www.amazon.com/MakerFocus-Chassis-MEGA2560-MEGA1280-Microcontroller/dp/B01LYZDP9U/

It comes with 4 independent motors? What type motors are they? Can you 
control them with a L298N H-bridge? How many? Do you want to control 
each wheel separately or pair them? What effect does that have on 
maneuverability? Do you want to go with PWM or a simple bang-bang? Would 
an Arduino be sufficient for the task? Does it have sufficient i/o 
capacity for other sensors? Or possibly a RPi? Or maybe multiple 
Arduinos, each handling a specific task. If so, how will they communicate?

How are you going to communicate? Will one of the 433 Mhz transceivers 
work? Does it have enough range for the purpose? Enough data rate or do 
you want to go for one of the 2.4 Ghz versions? What sort of 
communication protocol are you going to use between the two?

Are you going autonomous or do you want to control it with a joy stick? 
If you're going with a xy joystick module, how do you handle the analog 
input?

And so forth and so on. Something like that introduces both software and 
design decisions. There is a lot more involved than loading an algorithm 
into a 5' tall robot that magically appears.

On 7/31/2022 1:43 AM, rbowman wrote:
> On 07/31/2022 12:38 AM, Don Y wrote:
>> We have a project in which we provide students with a laptop that allows
>> them to develop a virtual robot and have it compete, on screen, with other,
>> pre-made virtual robots.  They can sit in their bedrooms, libraries,
>> classrooms, park benches, etc. and learn how to develop algorithms to
>> control their "robots" (autonomously).  They can test those algorithms
>> against other strategies that have been pre-delivered.  They can test their
>> strategies against those of their friends/classmates.
> 
> How much room does a robot car chassis take up?
> 
> https://www.amazon.com/MakerFocus-Chassis-MEGA2560-MEGA1280-Microcontroller/dp/B01LYZDP9U/ 
> 
> It comes with 4 independent motors? What type motors are they? Can you control 
> them with a L298N H-bridge? How many? Do you want to control each wheel 
> separately or pair them? What effect does that have on maneuverability? Do you 
> want to go with PWM or a simple bang-bang? Would an Arduino be sufficient for 
> the task? Does it have sufficient i/o capacity for other sensors? Or possibly a 
> RPi? Or maybe multiple Arduinos, each handling a specific task. If so, how will 
> they communicate?
> 
> How are you going to communicate? Will one of the 433 Mhz transceivers work? 
> Does it have enough range for the purpose? Enough data rate or do you want to 
> go for one of the 2.4 Ghz versions? What sort of communication protocol are you 
> going to use between the two?

There is no communication.  The student plugs his thumb drive into the robot
and steps back.  He has no need to understand how the mechanisms in the
robot work; rather, that they nominally respond as the little red dot on the
LCD screen responded to his algorithm's commands.

The "5 ft robot" is there simply to make a spectacle out of the (end of
course) tournament.  You use that to drum up excitement (and community support)
for the effort.  You rely on students WANTING to participate (because it is
an "off hours" activity... they give up some of their spare time OUT of school
in order to take on this activity).  You want to ENCOURAGE students to
think of this (STEM) as fun/exciting, not just "yet another math test".

You want to have something that a local news station can cover to help solicit
donations from prominent community leaders/groups (because you aren't CHARGING
the students to participate as that would just be a deterrent).

> Are you going autonomous or do you want to control it with a joy stick? If 
> you're going with a xy joystick module, how do you handle the analog input?

The whole point is to test *algorithms*, not "cognitive skills of 'operators'".
So, you want to let the algorithm compete without any additional input
from the student.

There are groups that design robots for competition.  *A* group designs
(and fabricates) *a* robot.  And, operates it in the arena (to meet some
particular set of tasks).  These groups rely heavily on the "educator"
for guidance in the design and fabrication.  And, on having access to
a "shop" with sufficient tools to actually construct the robot.

Yay *team*!

But, the contributions and learning for each individual is hard to
codify.  How do you *measure* the impact you've had on the students
in the program?  How do you correlate their performance in the
program with any changes in their performance in the "general
curriculum"?

[You have to be able to MEASURE the impact of your program in order
to be able to justify the expense -- to the grantor or, ultimately,
to the school district.  Just because it's "fun" doesn't mean it
is worthy of dollars!]

> And so forth and so on. Something like that introduces both software and design 
> decisions. There is a lot more involved than loading an algorithm into a 5' 
> tall robot that magically appears.

The thumb drive is the sole means of exchanging information between
"host systems".  E.g., if you go visit your friend and want to try
your latest robot algorithm against his, you carry your thumb drive
to his house (and plug it -- and his -- into your laptop or his laptop).

[We don't want the laptops to be "general purpose laptops".  We keep
them locked down so they only have value as "robot simulation platforms".
This cuts the cost of supporting them down (no risk of malware, disks
being erased, additional software installed, etc.).  It's the equivalent
of an interactive *book* -- it serves ONE purpose.]

It is a logical extension (in the minds of the students) to plug the
thumb drive into the "robot controller" located in the base of the
robot -- and expect the commands to control the motors instead of
the "X,Y display cursor".

For students with no prior coding experience, burdening them with all
these ancillary engineering issues just makes it intimidating.

"First year" students just learn enough about writing code to navigate
a (*randomly* generated) maze.  This is an activity that they can
personally relate to -- even if just dragging a pencil through a
print copy of a maze ("keep the wall on the left of your pencil and
just keep moving; notice the path it traverses?").

This also takes the "stress" of a one-on-one competition out of the
equation -- you just TIME their performance (assuming they are able to
complete the maze as you would obviously include structures that
defeat/complicate common algorithms).

"Second year" students learn to interact with a *dynamic* environment
(a maze is static) -- "where is my opponent?  why is he shooting at me?
how should I respond?"

"Third year" students have a finer-grained set of "opcodes" that they
can execute so have more control over how they spend resources.  E.g.,
computing the distance and angle to an opponent takes longer than
moving out of the way -- so, an opponent can leverage that liability
on your part to move out of the way before you can get a fix on him.
MEMORY gives you some compensating leverage as you can make educated
guesses as to where he MIGHT have moved, given that making a turn
(in place) costs more than moving forward.

They also deal with non-ideal mechanisms.  E.g., why didn't the
robot move EXACTLY one unit to the west?  How do we compensate
for this?  How do we determine the NEED for compensation?

[earlier classes relied on the "robot operating system" and
"arena dynamics" to ensure "MOVE WEST 1" gave exactly one
unit of displacement so the students don't have to address
those real-world issues.  We always deal with discrete time
operations -- my turn, your turn -- instead of a continuous
process.  This helps minimize any effects of physical robot
performance from biasing the results (if your mechanism is
slower, then it will just take a little bit longer for your
robot to complete its move -- but your opponent won't be
able to benefit from this "deficiency")]

If there is some sign of "success" (increased interest in STEM,
improved academic performance, increased DEMAND for the program,
etc.) then there is a chance for followup grants (or public
funding) to perpetuate/enhance/expand the program.

Our goal isn't to teach them any specific "language" (ROBOL?).
but, rather, to get them thinking analytically about the sorts
of problems that they might encounter if they pursued a career
in STEM (how do you determine the range to an adversary?  how
do you determine the proper angle of elevation of gun turret
to target that adversary?  how...)

On Sun, 31 Jul 2022 00:09:37 +0200, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:

>On 27/07/2022 04.10, bitrex wrote:
>> On 7/26/2022 10:06 PM, Rich S wrote:
>>> On Tuesday, July 26, 2022 at 6:38:36 PM UTC, John Larkin wrote:
>>>> On Tue, 26 Jul 2022 14:11:00 -0400, bitrex <us...@example.net> wrote:
>>>>
>>>>> On 7/26/2022 1:43 PM, John Larkin wrote:
>>>>>>
>>>>>> https://www.studyfinds.org/fear-for-safety-every-day/
>>>>>>
>>>>>> What's wrong with kids these days? Most have been super-protected
>>>>>> children but are afraid of life.
>>>>>>
>>>>>> Engineers have to THINK, blow things up, take calculated risks. Fear
>>>>>> warps prudent judgement.
>>>>>>
>>>>>> I've had interns that were afraid to touch a board powered from 5
>>>>>> volts, or handle a 12 volt battery. And wanted eye protection and
>>>>>> masks for everything. And who wouldn't crank up a power supply to see
>>>>>> how much an electrolytic cap would leak past abs max voltage rating.
>>>>>
>>>>> I guess you get what you pay for
>>>> Interns are cheap and most don't last long.
>>>
>>> Maybe during the interview, you ask them to
>>> "taste" the top of an 9V battery. If they refuse,
>>> or they do but get really upset&#4294967295; then don't hire
>>> &#4294967295; them. :0)
>>>
>>> I think getting shocked, blowing fuses, etc,
>>> were a rite of passage for young experimenter.
>>> Getting of visceral sense of energy, feel what is electricity.
>>> But in today's highly safety-conscious society we mustn't
>>> say such things&#4294967295; :-X
>>>
>> 
>> Pretty sure I recall people here complaining more kids were going into 
>> software than hardware these days.
>> 
>> Might have something to do with that nobody asks you to suck on a 9 volt 
>> to get your first job in that field. And that first job usually pays way 
>> better, too.
>> 
>
>The engineers graduating predominately in software engineering, and 
>Hardware is becoming extinct:
>
>Engineers on the brink of extinction threaten entire tech ecosystems:
>
>https://www.theregister.com/2022/07/18/electrical_engineers_extinction/
>
>Grapgh showing the trend:
>
>https://twitter.com/magicsilicon/status/1545276464567726081?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1545278290319253506%7Ctwgr%5Ebaadd480e2d52bf87ee5ecf3ee403b114571677a%7Ctwcon%5Es2_&ref_url=https%3A%2F%2Fwww.theregister.com%2F2022%2F07%2F08%2Fsemiconductor_engineer_shortage%2F
>

Nice links. I've noticed that increasing trend, kids with ee degrees
who know basically nothing about electricity, except they are afraid
of it.

So a good product line would have difficult analog i/o circuits,
usuallly backed up with digital signal processing in an FPGA an/or a
uP. SOC chips do both.

The people who architect the digital parts of a product still need to
understand signals-and-systems and control theory, even if they don't
code it themselves.

A good product needs good packaging and thermals and a clean human
interface too, more stuff the kids can't do.

I took two semisters of thermo in college, some time ago, and it was
all about enthalopy and steam tables and such nonsense. No discussion
about cooling electronics.

On Sat, 30 Jul 2022 23:38:22 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/30/2022 10:37 PM, rbowman wrote:
>> On 07/30/2022 04:09 PM, Klaus Vestergaard Kragelund wrote:
>>> On 27/07/2022 04.10, bitrex wrote:
>
>>> The engineers graduating predominately in software engineering, and
>>> Hardware is becoming extinct:
>
>Verilog, VHDL

Still typing, not drawing.



>
>>> Engineers on the brink of extinction threaten entire tech ecosystems:
>>>
>>> https://www.theregister.com/2022/07/18/electrical_engineers_extinction/
>> 
>> I think the article has a valid point.
>
>I think you're ignoring the paradigm shift.
>
>One could rewrite this:
>
>   "For most of the history of electronics, there was a clear on-ramp for
>    this, and an industry that didn't need to sell itself because it was
>    inherently cool for geeks. Look at the biographies of the great names
>    in electronics, such as Intel co-founder Robert Noyce or the father
>    of the information age Claude Shannon, and you find them as teenage
>    geeks pulling apart, then rebuilding, then designing radios and guitar
>    amplifiers. The post-war generation tore down military surplus gear
>    to teach themselves how it worked and mine components to build their
>    own inventions."
>
>replacing references to pulling apart (DISASSEMBLing!) then rebuilding
>hardware (SOFTWARE).  How many howto's cover hacking a serial console
>onto an existing COTS product and then poking around inside to enable
>features -- or even reimage the firmware.
>
>Sadly, "hardware types" are likely clueless as to how these things are
>done.  Who do you think comes up with workarounds for the multitude of
>copy protection schemes that have been deployed?  Who do you think
>uses the sources to FOSS products to modify (tinker) with them and
>add value/functionality that isn't present in the original offering?
>
>It's like a sculpter complaining about all the young kids taking up
>PAINTING (for "fear" of a hammer and chisel?).  A fair bit of arrogance,
>there ("What *I* know is important; what I don't, isn't!")
>
>Sadly, "coders" probably take on the greatest risk as their efforts
>won't see success or failure for many months/years (a power supply
>likely blows pretty quick!).  And, most have no control over the
>hardware that will host their code.
>
>[How often do you release a hardware design to manufacturing without
>having the design finished, implemented and tested? 

Never. Released products are supposed to work. First time.



 How often do you
>DELAY the product release until the same can be said of the software?
>Who takes up the slack, do you redesign the hardware to accommodate
>the FINISHED/tested software?]

Design the hardware and software together. Of course, the software is
finished last, but by weeks, not years.



>
>How much TEXT will the application require?  DATA?  Real time?  What
>recourse if you exceed the resources available -- will they reengineer
>the hardware to fit your ACTUAL needs, /ex post factum/?
>
>What's the maximum stack penetration for THIS task?  In what
>circumstances?  How does that differ for each of the other tasks?
>Have you configured them as-needed?  Or, adopted a one-size-fits-all
>approach?  What happens to the code size if I add a single call to
>printf()?  How long will XXX take to execute?  What sort of latency
>will the user experience between his taking an action and the
>device responding to it -- in a meaningful way?
>
>If <someone> plugs your 120VAC appliance into 220VAC mains and the
>power supply blows up, catches fire, etc. IT'S THE FAULT OF THE USER!
>But, if the user enters an unusual keystroke sequence and the device
>crashes, IT'S BUGGY SOFTWARE!
>
>> I've got hopes for the maker culture but 
>> I don't know how many participate.

A lot of maker stuff is robotics, which starts with an Arduino or
something so is mostly a coding project.



>
>I actually think software makes engineering more accessible to folks.
>The problem I see is that it makes *programming* more accessible and
>sidesteps the engineering aspect of software.  You *design* software
>just like you design hardware.  You don't just sit down and "write code"
>(that's what CODERS do!)
>
>> Our new library has a nicely equipped 
>> makerspace with several printers, scanners, laser cutters and so forth. I 
>> should snoop around and see how much it is being used. I'll confess that with 
>> ebooks I don't physically visit the library often.
>
>Damn near anyone can afford a (used) laptop.  And, with it, you can learn
>a multitude of languages, programming skills, styles, etc.  AND ACTUALLY
>CREATE "PRODUCTS"!
>
>Buying a scope doesn't eliminate the need for a signal generator.  Or, freq
>counter.  Or, soldering iron.  Or, mantis.  Or...

Nowadays one can set up a decent electronics bench for way under
$1000. A good scope used to cost more than a Chevrolet.



>
>Where do you put all these things?  Maker shops attract folks who can't
>afford the equipment or the *space* for same in their own condos, appartments,
>dorm rooms, etc.  You don't see folks scampering for space to set up a laptop!
>
>We have a project in which we provide students with a laptop that allows
>them to develop a virtual robot and have it compete, on screen, with other,
>pre-made virtual robots.  They can sit in their bedrooms, libraries,
>classrooms, park benches, etc. and learn how to develop algorithms to
>control their "robots" (autonomously).  They can test those algorithms
>against other strategies that have been pre-delivered.  They can test their
>strategies against those of their friends/classmates.
>
>We use this as a teaching platform to introduce programming AND algorithm
>design to the students.  It's not "in a vacuum" as you are competing with
>another algorithm; if you use a sloppy implementation of the same algorithm
>as your competitor, he will beat you!  So, you have to manage time
>resources as well as get the logic correct.  We expose different aspects
>of the problem space that the kids might not appreciate ahead of time which
>could cause naive algorithms to fail.

Few coders know what a state machine is. They write hairballs, like
people used to design asynchronous logic.

On 07/31/2022 04:31 AM, Don Y wrote:
> If there is some sign of "success" (increased interest in STEM,
> improved academic performance, increased DEMAND for the program,
> etc.) then there is a chance for followup grants (or public
> funding) to perpetuate/enhance/expand the program.

Perhaps. What age group is this aimed at? I still think a kid that 
cobbled together a semi-autonomous robot/drone to annoy the family cat 
would have an edge if (s)he showed up at Boston Dynamics someday looking 
for a job. Extra points for a camera feed into FPV googles.

Somebody has to understand the Nuts & Volts aspects of real world 
mechanisms and you won't get there with programming alone. Perhaps I'm 
nostalgic. The first half of my career involved making real world stuff 
happen. The second half has mostly been pixel pushing with the exception 
of the occasional need to read from a GPS receiver stream to determine 
where the ambulance or firetruck is.

On 07/31/2022 09:09 AM, jlarkin@highlandsniptechnology.com wrote:
> Nice links. I've noticed that increasing trend, kids with ee degrees
> who know basically nothing about electricity, except they are afraid
> of it.

Different era but when I was a IEEE member most of the interesting stuff 
happened in the Boston chapter. My home chapter in New Hampshire was 
almost all classic electrical engineers working for Public Service, the 
power company. They basically knew nothing about computers except they 
were afraid of them.

On 07/31/2022 09:29 AM, jlarkin@highlandsniptechnology.com wrote:
> A lot of maker stuff is robotics, which starts with an Arduino or
> something so is mostly a coding project.
>
>

True, but it still has a link to the real world, even if it's only 
adapting ArduPilot.

On 7/31/2022 11:27 AM, rbowman wrote:
> On 07/31/2022 04:31 AM, Don Y wrote:
>> If there is some sign of "success" (increased interest in STEM,
>> improved academic performance, increased DEMAND for the program,
>> etc.) then there is a chance for followup grants (or public
>> funding) to perpetuate/enhance/expand the program.
> 
> Perhaps. What age group is this aimed at? I still think a kid that cobbled 
> together a semi-autonomous robot/drone to annoy the family cat would have an 
> edge if (s)he showed up at Boston Dynamics someday looking for a job. Extra 
> points for a camera feed into FPV googles.

We're targeting the "junior high" crowd -- 11 - 13yo.  The thinking being
that you want to get them "pointed" in a STEM direction before they start
their high school education (which, in many places, requires students to choose
a business vs. college vs. vocational path for their curriculum -- prior to
that, everyone is largely treated the same)

> Somebody has to understand the Nuts & Volts aspects of real world mechanisms 
> and you won't get there with programming alone.

I'm building the mechanisms, compilers, virtual arena, curriculum, etc.  As
well as setting up mechanisms to "mass produce" the "per student" items (only
need a couple of "5 ft robots" as they are only used in the tournaments).

If a *real*, supported program arises from these efforts, it will acquire
administrative bloat, as expected.  But, my involvement will be over long
before that (I'm not fond of "long term relationships" with projects  :> )

> Perhaps I'm nostalgic. The 
> first half of my career involved making real world stuff happen. The second 
> half has mostly been pixel pushing with the exception of the occasional need to 
> read from a GPS receiver stream to determine where the ambulance or firetruck is.

For me, it has been similar.  Deeply embedded devices throughout.  But,
slowly moving up the complexity (cost) scale and into higher volume devices
(I currently price in 100K quantities).

Early designs ran on 4 and 8 bit hardware with scores of BYTES of RAM
available, cycle times on the order of a microsecond or slower.  Presently,
a couple hundred 64b quad core GHz processors (Cortex A53) each with half
a gig of RAM, internetworked to work as a composite unit.

[This will likely change before I finish all of the software; why *settle* on
hardware before the software is done?  Hardware is considerably cheaper than
software so why skimp?!]

E.g., my current RTOS does things that "big machines" can't do -- and at
bargain basement prices!  But, is still "appliance" oriented (though the
appliances are now "system components" instead of dumb little islands).
No "graphic workstation" aspect.

In article <jko0b1Fmb9hU1@mid.individual.net>, bowman@montana.com 
says...
> 
> Different era but when I was a IEEE member most of the interesting stuff 
> happened in the Boston chapter. My home chapter in New Hampshire was 
> almost all classic electrical engineers working for Public Service, the 
> power company. They basically knew nothing about computers except they 
> were afraid of them.
> 
> 
> 

It is amazing to me how about 10 years can make a difference.  I am 72 
and a friend is 82.  He was an electronics engineer with a 4 year degree 
and worked in the Bell Labs and Western Electric.  He is stuck in the 
vacuum tube era.  Does not like to use a computer and fills out his tax 
by hand.  I just went to a 2 year tech school for electronic 
engineering.  A few years after school the home computers came out.  My 
first was a TRS80 model 3.  While I may not be great with computers now  
I do use them all the time.  About 2 years go I got into the Arduino 
world and taught myself how to get around with one.

On Sun, 31 Jul 2022 12:42:55 -0600, rbowman <bowman@montana.com>
wrote:

>On 07/31/2022 09:29 AM, jlarkin@highlandsniptechnology.com wrote:
>> A lot of maker stuff is robotics, which starts with an Arduino or
>> something so is mostly a coding project.
>>
>>
>
>True, but it still has a link to the real world, even if it's only 
>adapting ArduPilot.

But seldom real electronic design. Maybe copy a relay driver or
something.