Restructered pre-import

Old Pages/Electronics/FPGAWorkshopDLotts.md

@@ -0,0 +1,114 @@
+Currently I only have some meta ideas:
+
+I'd like to do something that:
+
+\- can't be done using microcontrollers.
+
+\- that I can complete
+
+------------------------------------------------------------------------
+
+I thought I'd share another meta-idea that might lend itself FPGA
+programming. I have to come up with a practical application, to test out
+these ideas, but I need help working out an issue, described at the
+bottom of this.
+
+This idea follows what I call the "sailing philosophy", that is: meet
+requirements using the wind that you get, even if you have to zigzag,
+and NOT getting all silly about controlling the wind and rest of the
+environment.
+
+This may also be an example of the ["Worse is
+better"](http://en.wikipedia.org/wiki/Worse_is_better) philosophy.
+
+## The sloppy redundant full feedback approach to physical computing
+
+-or-
+
+## The Cloud Computing approach to Managing Sensors
+
+Abstract: Physical computing, robotics, and mechatronics suffer from a
+mapping problem, a mechanical complexity problem, and a configuration
+management problem. These problems can be solved by creating and using
+clumps of cheap sensors, attached using modern adhesive materials and
+connecting their output wires randomly to the input of the computer
+controller. Then, requiring the designer to set a sensor clump for every
+movement, the controller can manage it's own configuration
+automatically.
+
+Sensor mounting: Wrap-on, spray on, glue on. Must work without perfect
+positioning and without careful mounting of screws and mounting plates
+-- none of that. It should be like putting on a band aid, a bandanna, or
+peeling a Bannana. :^) It should be a blob of clay with wires that you
+push into the correct spot for sensing. (Epoxy putty and two part
+silicone come to mind.) Or perhaps like a strip of adhesive tape or
+Velcro(TM) that you wrap around or along a moving joint.
+
+Sensor clumps: Sensors must be a bunch of more or less redundant wired
+outputs that sense different portions of where they are mounted. For
+example, an array of light sensors, each positioned and pointed randomly
+and distributed. For another example, conductors thinly separated,
+changing resistance, distributed around something that moves, or
+capacitive around gaps, or hall affect around moving metal. Each sensor
+is actually a bundle of cheap sensors, maybe thirty or a hundred tiny
+points of electronics that change electrical output in response to a
+change in the environment.
+
+Connecting the sensors: Should be a bundle of wires, perhaps a ribbon
+cable, that makes it's way to each sensor. The mapping of the wires to
+the input on the controller MUST be inconsequential. Figuring out which
+wire goes to which sensor is a responsibility of the system, NOT human
+that connects them. The wires get bundled together randomly and
+connected regardless of what they sense, or even if they are not
+connected.
+
+Actuators: Motors, piston cylinders, lights, heaters, anything that
+moves, emits radiation, or otherwise changes a physical state MUST have
+a sensor clump mounted on or with it. This is practical because sensors
+are easy to apply and cheap -- see sensor clumps, and sensor mounts.
+
+Controller initialization: When the controller is powered on it must go
+through a series of movements whereby it changes an actuator and records
+which sensors are relevant to each movement and what scale . This way it
+can set up feedback loops from the control output to the sensor
+feedback. This is similar to what I imagine infants do, as they move
+randomly and map the sensations produced. It can store this mapping of
+actuator to sensor in non-volitale memory for next power up, perhaps use
+it as a hint, so that the initialization can be much faster and requires
+only a small movement.
+
+Limit sensing 1: Limit sensing must be done carefully since driving a
+motor past it's range of motion can damage the structure or the
+actuator. One idea perhaps to designated some sensors that report a bad
+state and other sensors that can predict the bad state. For example, a
+position sensor and a limit switch to indicate a bad state, or a
+temperature sensor that can be calibrated to predict an over-heating
+sensor. The bad state sensor must be manually calibrated, or positioned
+at the limit manually. I don't know how the controller would determine
+which is the bad state sensor. Perhaps it could be first initialized
+with all bad state sensors in their good state, then record that for the
+life of the device.
+
+Limit sensing 2: Another idea for limit sensing is the designer could
+associate particular actuators as having limits, so that during
+initiation it will search for it's limits by oscillating in small
+increments, progressing slowly in one direction, until it senses
+feedback with the same frequency as it's oscillation, and then do the
+same in the other direction.
+
+The blocking challenge: Another issue with this approach that I have to
+solve before I start is that of analog to digital. A wide variety of
+analog inputs with unpredictable ranges need to be connected to a large
+number of digital inputs. I'm hoping some simple thresholding with
+comparators or similar can allow easily connecting to digital inputs. I
+guess an analog multiplexer connected to an ADC might do the trick. Then
+I just need 8 or 16 bits to connect the signal input to the controller,
+and address bits that select a sensor's wire, maybe another few IO pins
+to control a gain amplifier for sensors with weak signals.
+
+I had hoped that FPGA's had more analog features at their inputs, but
+they seem black and white. This is the part that I haven't yet figured
+out. Please help! --[DLotts](User:DLotts "wikilink") 06:39, 28 February
+2010 (UTC)
+
+[Category:FPGAWorkshop](Category:FPGAWorkshop "wikilink")