"Twitchie"

[From Bruce Abbott (2018.01.11.2330 EST)]

I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.”

image00295.jpgThe “forearm” is the bottom arm that is holding the two Lego tires in its “hand.” The “elbow joint” is a shaft attached to an angle sensor; when the forearm is level the angle sensor reads zero degrees. The angle becomes negative if the arm falls below the horizontal and positive if the arm raises above the horizontal.

The large Lego motor at top, together with the rubber band, acts as the forearm’s flexor muscle. When the short arm attached to the motor output wheel rotates upward, this simulates the muscle contracting. The rubber band simulates the muscle’s elastic property (although in quite exaggerated form relative to real muscle!).

The angular position of the forearm is regulated by a proportional controller, which compares the reference angle (currently zero degrees or horizontal, set as a parameter) to the “joint angle” reported by the angle sensor. The difference between them (the error signal) is multiplied by the output gain factor Ko and this result sets the rotational velocity of the motor. The direction of rotation is determined by the sign of the input to the motor block and its rotational speed by the magnitude.

If the forearm angle is negative, this causes the motor to rotate so as to raise the short arm attached to its output wheel. This action pulls on the rubber band, and when the tension is high enough, lifts the arm, thus reducing the error (negative feedback). If the load is decreased (e.g., by removing the Lego tires), the stretched rubber band shortens, pulling the forearm upward and thus creating a positive forearm angle. The system responds by lowering the arm attached to the motor, thus lowering the forearm back toward the horizontal.

With a relatively heavy load, the arm tended to be driven into oscillation because of the springiness of the rubber bands. To overcome this tendency I created a dashpot made from a discarded pill bottle and a few Lego parts. As the forearm moves it raises or lowers a small wheel (serving as a paddle) inside the water-filled container, thus generating some resistance to movement that is proportional to the rate of movement of the paddle. The dashpot acts as a damper, much like a car’s shock absorbers.

Lego does not offer a stand-alone angle sensor, so I ordered one from HiTehnic. It turns out to be rather noisy electrically, and consequently, spurious angle readings are generated that occasionally cause the forearm to twitch, hence the name “Twitchie.” I tried out a smoothing algorithm but this introduced a fair amount of lag in the system’s response to changes of load without entirely eliminating the twitches, so I’ve gone back to using the unfiltered signal.

The output function of the proportional controller simply multiplies the angle error by the output gain Ko – there is no leaky integrator and, consequently, no “slowing factor.” The output gain Ko is set to around 0.5 rather than to the values we typically use in our “leaky integrator output” simulations, which typically have values from the tens to the hundreds. So here’s a nice test of your understanding – can you explain why the hardware implementation can get away without a leaky integrator in the output of the control system, and why the proper output gain is so much lower.

I’ve posted a brief (30-s) video showing Twitchie in action to my YouTube site at https://youtu.be/Y_f9FV1ymIU .

Comments?

Bruce

p.s. Adam Matic, I haven’t forgotten about your implementation, which is better than mine in that it had “muscles” acting on the limb in both directions! The challenge for me was simply to learn how to do something similar using the Lego EV3 setup. I could duplicate your setup by adding a second motor pulling on the same limb from the opposite direction – although I’d have to extensively redesign the framework to accommodate the extra muscle.

Bruce

image001192.jpg

[From Erling Jorgensen (2018.01.12 0820 EST)]

Bruce Abbott (2018.01.11.2330 EST)

Hi Bruce,

BA: I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.�

[...snip...] I’ve posted a brief (30-s) video showing Twitchie in action to my YouTube site at <https://urldefense.proofpoint.com/v2/url?u=https-3A__youtu.be_Y-5Ff9FV1ymIU&d=DwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=-dJBNItYEMOLt6aj_KjGi2LMO_Q8QB-ZzxIZIF8DGyQ&m=hq8u_2b6spjVQR3j45jo4yR7X0G3Yegi4ufHW3PPM20&s=61fuknqgn7tjBu4ArCJoztlWG46reB7BMPVIP8OJ2aQ&e=&gt;https://youtu.be/Y_f9FV1ymIU .
EJ: This really is fascinating. I appreciate the elemental form of this! Boston Dynamics it ain't, but it's the kind of thing that could be taught in the classroom in elementary or middle school, to give kids a clean working knowledge of how the different components work and fit together. And I appreciate that you explain each portion, (for us middle schoolers who never got a chance to take Robotics!)
EJ: I like how you improvised a dashpot damper for the thing. Maybe it's just that I recently saw "The Martian" on DVD, and liked how Matt Damon (and NASA) had to improvise all these things to survive! It'd be nice to see the more "twitchie" version in your YouTube, like a before and after view.
EJ: I'm curious if you know how that angle sensor actually calculates the perception of joint angle. I'm also curious whether the human system actually has that perception, or whether (y)our simulations use "joint angle" as a stand-in for a different mechanism being calculated among combinations of tendon stretch, or some such thing.
EJ: Without a leaky integrator output, my understanding is that the need is to guard against overshoot and resulting oscillation. Combining a higher gain with an integrator, I believe, allows for strong response but graded implementation. I describe it as the output _starts to move_ in the needed direction.
EJ: Nice job. I hope you and Twitchie can have many hours of meaningful and informative interaction!... (letting us listen in on the process.)
All the best,
Erling
EJ: (Because I'm sending this from the work computer, our standard confidentiality caution follows. Sorry about that.)

Confidentiality: This message is intended only for the addressee, and may contain information that is privileged and confidential under HIPAA, 42CFR Part 2, and/or other applicable State and Federal laws. If you are not the addressee, or the employer or agent responsible for delivering the message to the addressee, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete the material from your computer.

Please also note: Under 42 CFR part 2 you are prohibited from making any further disclosure of information that identifies an individual as having or having had a substance use disorder unless further disclosure is expressly permitted by the written consent of the individual whose information is being disclosed or as otherwise permitted by 42 CFR Part 2.

Thank you for your cooperation.

Bruce,

This is nice stuff.

  You ask about the lack of integrator, but I think you do have an

integrator, the dashpot. As for your question about why the
proportional gain is so much lower than the numbers used for
“gain” in simulations, I think you are comparing apples and
oranges. The so-called “gain” in the simulations is not a gain but
an integrator gain rate. The asymptotic gain of a leaky integrator
is gain-rate/leak-rate, and a gain of around 10 means pretty good
control. The asymptotic gain is the loop gain in the analyses we
usually see on CSGnet, but not what is reported in the simulations
that are based on sample rates. They are (or should be) reported
as gain per second (or per minute or per year), not as simply
“gain”. It’s very hard to guess what the loop gain in your device
might be, because it is determined by translations such as error
angle-to-motor-velocity, and motor-velocity to arm-angle, not to
mention the lever mechanical advantage of your short and long
arms.

  There are several possible reasons why you might get oscillation.

As you say, the undamped spring of the rubber band is part of it,
and part of a solution might be to push a foam pad against the
band or find some other way to create friction in the
rubber-band-load subsystem, which in electronic terms is an LC
tuned “resonator” circuit (energy storage moves back and forth
between the potential energy of the load and the energy stored in
the stretched band). The foam pad would reduce the Q of this
resonator circuit, but you could induce friction in other ways,
such as making something like a open-ended dashpot in which a pad
moves as a piston along a tube, creating friction along the walls
but no air compression. The point is to reduce the energy that is
transferred back and forth by diverting some of it into heat.

  The generic source of oscillation in a loop is phase shift around

the loop. The system will go into uncontrolled exponentially
increasing the size of the oscillation if the loop gain exceeds +1
at a frequency where the phase shift is 180 degrees, but will show
a damped oscillation if the loop gain is positive when the phase
shift is 180. Your dashpot induces a phase shift, and so does your
rubber band-load resonator. Increasing your proportional gain
increases loop gain, whether at any particular frequency that gain
is positive or negative, so if there is a frequency at which the
loop gain is at all positive, there will be a threshold of
proportional gain at which the oscillation becomes noticeable.
Changing the load changes the resonant frequency of the band-load
resonator, and hence the frequency/phase-shift relationship.

Does this make sense?

Martin

image00295.jpg

···

On 2018/01/11 11:32 PM, Bruce Abbott
wrote:

[From Bruce Abbott (2018.01.11.2330 EST)]

      I’ve been playing around with my Lego

Mindstorms EV3 set and came up with a demo I thought worth
sharing. It implements a simple proportional control system
to keep a simulated forearm level against changes in the load
placed in its “hand.”

      The “forearm” is the

bottom arm that is holding the two Lego tires in its “hand.”
The “elbow joint” is a shaft attached to an angle sensor; when
the forearm is level the angle sensor reads zero degrees. The
angle becomes negative if the arm falls below the horizontal
and positive if the arm raises above the horizontal.

      The large Lego motor at top, together with

the rubber band, acts as the forearm’s flexor muscle. When
the short arm attached to the motor output wheel rotates
upward, this simulates the muscle contracting. The rubber
band simulates the muscle’s elastic property (although in
quite exaggerated form relative to real muscle!).

      The angular position of the forearm is

regulated by a proportional controller, which compares the
reference angle (currently zero degrees or horizontal, set as
a parameter) to the “joint angle” reported by the angle
sensor. The difference between them (the error signal) is
multiplied by the output gain factor Ko and this result sets
the rotational velocity of the motor. The direction of
rotation is determined by the sign of the input to the motor
block and its rotational speed by the magnitude.

      If the forearm angle is negative, this

causes the motor to rotate so as to raise the short arm
attached to its output wheel. This action pulls on the rubber
band, and when the tension is high enough, lifts the arm, thus
reducing the error (negative feedback). If the load is
decreased (e.g., by removing the Lego tires), the stretched
rubber band shortens, pulling the forearm upward and thus
creating a positive forearm angle. The system responds by
lowering the arm attached to the motor, thus lowering the
forearm back toward the horizontal.

      With a relatively heavy load, the arm

tended to be driven into oscillation because of the
springiness of the rubber bands. To overcome this tendency I
created a dashpot made from a discarded pill bottle and a few
Lego parts. As the forearm moves it raises or lowers a small
wheel (serving as a paddle) inside the water-filled container,
thus generating some resistance to movement that is
proportional to the rate of movement of the paddle. The
dashpot acts as a damper, much like a car’s shock absorbers.

      Lego does not offer a stand-alone angle

sensor, so I ordered one from HiTehnic. It turns out to be
rather noisy electrically, and consequently, spurious angle
readings are generated that occasionally cause the forearm to
twitch, hence the name “Twitchie.” I tried out a smoothing
algorithm but this introduced a fair amount of lag in the
system’s response to changes of load without entirely
eliminating the twitches, so I’ve gone back to using the
unfiltered signal.

      The output function of the proportional

controller simply multiplies the angle error by the output
gain Ko – there is no leaky integrator and, consequently, no
“slowing factor.” The output gain Ko is set to around 0.5
rather than to the values we typically use in our “leaky
integrator output” simulations, which typically have values
from the tens to the hundreds. So here’s a nice test of your
understanding – can you explain why the hardware
implementation can get away without a leaky integrator in the
output of the control system, and why the proper output gain
is so much lower.

      I’ve posted a brief (30-s) video showing

Twitchie in action to my YouTube site at https://youtu.be/Y_f9FV1ymIU .

Comments?

Bruce

      p.s. Adam Matic, I haven’t forgotten about

your implementation, which is better than mine in that it had
“muscles” acting on the limb in both directions! The
challenge for me was simply to learn how to do something
similar using the Lego EV3 setup. I could duplicate your
setup by adding a second motor pulling on the same limb from
the opposite direction – although I’d have to extensively
redesign the framework to accommodate the extra muscle.

Bruce

[From Bruce Abbott (2018.01.12.1220 EST)]

Hi Earling,

[From Erling Jorgensen (2018.01.12 0820 EST)]

Bruce Abbott (2018.01.11.2330 EST)

Hi Bruce,

BA: I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.�

[…snip…] I’ve posted a brief (30-s) video showing Twitchie in action to my YouTube site at https://youtu.be/Y_f9FV1ymIU .

EJ: This really is fascinating. I appreciate the elemental form of this! Boston Dynamics it ain’t, but it’s the kind of thing that could be taught in the classroom in elementary or middle school, to give kids a clean working knowledge of how the different components work and fit together. And I appreciate that you explain each portion, (for us middle schoolers who never got a chance to take Robotics!)

Thanks!

EJ: I like how you improvised a dashpot damper for the thing. Maybe it’s just that I recently saw “The Martian” on DVD, and liked how Matt Damon (and NASA) had to improvise all these things to survive! It’d be nice to see the more “twitchie” version in your YouTube, like a before and after view.

I had saved several plastic pill bottles with the idea that they might serve as cylinders for a pneumatic actuator, and it finally occurred to me that they might also work as the “pot� of a dashpot.  Enter some serendipity: the Lego kit includes  thin wheels that happen to have just the right diameter to fit the inner diameter of the pill bottle without being too snug. I’m currently using water as the working fluid but if more damping were required I could switch to something with more viscosity and preferably that wouldn’t make too much of a mess if spilled, such as liquid dish soap.

EJ: I’m curious if you know how that angle sensor actually calculates the perception of joint angle. I’m also curious whether the human system actually has that perception, or whether (y)our simulations use “joint angle” as a stand-in for a different mechanism being calculated among combinations of tendon stretch, or some such thing.

I don’t know what’s inside the angle sensor, but its shaft turns freely so it’s probably not a potentiometer.  If I were to build such a thing I’d use a photo emitter/receiver unit reading the reflected light from a disk inside the case. The disk would have a black spiral imprinted on it that increased in width from center to outside edge. The electronics would read the reflected light and convert this to a digital value ranging from 0 to 359. (And this is the actual range of values that the HiTechnic angle sensor reports, with a claimed 1-degree accuracy.)

Unfortunately my angle sensor is rather noisy; fluctuations on the order of plus or minus 1 or 2 degrees occur without any shaft rotation. I don’t know whether this is a defect in my particular example or a general characteristic of the sensor.

The program that runs Twitchie subtracts 180 rpm the sensor reading. This produces negative values when the sensor shaft turns in one direction and positive values when it turns in the other direction, so long as the shaft does not turn more than 180 degrees. I set the sensor shaft so that the zero-point occurs when the arm is horizontal relative to the frame on which the sensor is mounted.

The Lego motors include digital shaft encoders that can be read in software. These are accurate but the readings are based on the motor output wheel’s position at the start of the program (or when reset to zero), not the absolute shaft angle.  To get absolute values for use in a program, one must assure that the motor output wheel has been rotated to the desired starting position before the program starts. Twitchie’s program does not use the motor shaft position in its calculations and so is not subject to this restriction.  The motor simply rotates until the error between reference forearm angle and sensed angle are brought close to zero.

EJ: Without a leaky integrator output, my understanding is that the need is to guard against overshoot and resulting oscillation. Combining a higher gain with an integrator, I believe, allows for strong response but graded implementation. I describe it as the output starts to move in the needed direction.

One needs to guard against oscillation with or without a leaky integrator output. In software simulation, the leaky integrator introduces time into the computations, preventing the full computed output (Ko times error) from taking effect instantaneously. The so-called “slowing factorâ€? sets the leak rate – what proportion of this output is appplied on each iteration. So we have

New Output = Current Output + Change in Output, where

Change in Output = (Ko * Error)*dt/Slowing Factor

“dt� is the time elapsing per iteration of the loop. Note that the per-iteration gain in the output function is

Ko/Slowing Factor. So if Ko is 100 and Slowing is 200, the effective per-iteration gain is 0.5.

EJ: Nice job. I hope you and Twitchie can have many hours of meaningful and informative interaction!.. (letting us listen in on the process.)

All the best,

Erling

Bruce

[From Bruce Abbott (2018.01.12.1220 EST)]

Â

···

One needs to guard against oscillation
with or without a leaky integrator output. In software
simulation, the leaky integrator introduces time into the
computations, preventing the full computed output (Ko
times error) from taking effect instantaneously. The
so-called “slowing factorâ€? sets the leak rate – what
proportion of this output is applied on each iteration.Â
So we have

          New Output = Current Output + Change in

Output, where

          Change in Output = (Ko *

Error)*dt/Slowing Factor

Â

          “dt� is the time elapsing per iteration

of the loop. Note that the per-iteration gain in the
output function is

          Ko/Slowing Factor.  So if Ko is 100 and

Slowing is 200, the effective per-iteration gain is 0.5.

Â

[From Rick Marken (2018.01.12.1225)]

···

Bruce Abbott (2018.01.11.2330 EST)

Â

BA: I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.â€?..

Â

BA: I’ve posted a brief (30-s) video showing Twitchie in action to my YouTube site at https://youtu.be/Y_f9FV1ymIU .

BA: Comments?Â

RM: Very nice work. Â

BA: So here’s a nice test of your understanding – can you explain why the hardware implemeentation can get away without a leaky integrator in the output of the control system, and why the proper output gain is so much lower.Â

RM: My guess is that the necessary dynamics are handled by the connection between the output (rotation of the motor) and the input (arm angle). I think the output gain of the proportional controller isn’t really .5; that is a measure of delta output to motor/delta error, where both variables are measured in, say, volts. So the .5 “gain” in your program is dimensionless. The actual output gain is delta force on arm angle/delta error which is in units of newtons/volt. So the value of .5 which is used in the proportional controller implemented in the program, does not necessarily imply a lower gain system than the one’s we implement in software alone.Â

RM: The temporal integration necessary to dynamic stability of the system occurs, I believe, in the environmental connection between motor force (the output variable) and arm angle. I think it’s carried out by the motor itself (a time integration from electrical signal to the change in force that is a function of that signal), the physical connection between motor force and angle of rotation of the motor shaft (another integration); and the rubber band connection from motor shaft to the arm angle (another integration); the dashpot probably acts like a leak on these integrations. So that’s why you don’t need a leaky integrator in your program; it’s all being handled by the feedback function.

RM: What I would suggest now is that you make a slight alteration to it as a way to make it clear that what the system is controlling is a perception that is not necessary a representation of something that we think of as being “out there” in the world (like the angle of the arm seems to be). How about adding a little microphone sensor to the system and have the system control a perception that is some linear combination of the angle of the arm and the level of the sound. Now sounds will be a disturbance to this variable that can only be compensated for by a change in the angle of the arm. One you have this system set up, have people try to figure out what the system is “doing” (ie. controlling). Their first guess would surely be that it is controlling arm angle if the only disturbance used is the weight. But then you can confuse things by pointing making some loud sounds near the microphone to show that the arm apparently moves in response to the sounds. And eventually you could demonstrate that the system isn’t controlling arm angle but a perception that is a combination of arm angle and sounds level -- a perception of something that is definitely not a variable in the environment, but is a function of such variables. Â

RM: Again, very nice demo.

BestÂ

Rick

Â

Bruce

Â

p.s. Adam Matic, I haven’t forgotten about your implementation, which is better than mine in that it had “musclesâ€? acting on the limb in both directions! The challenge for me was simply to learn how to do something similar using the Lego EV3 setup. I could duplicate your setup by adding a second motor pulling on the same limb from the opposite direction – although I’d have to extensively redesign the fframework to accommodate the extra muscle.

Â

Bruce


Richard S. MarkenÂ

"Perfection is achieved not when you have nothing more to add, but when you
have nothing left to take away.�
                --Antoine de Saint-Exupery

[From Erling Jorgensen (2018.01.12 1535 EST)]

Bruce Abbott (2018.01.11.2330 EST)

Rick Marken (2018.01.12.1225)

BA: I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.�..

RM: What I would suggest now is that you make a slight alteration to it as a way to make it clear that what the system is controlling is a perception that is not necessary a representation of something that we think of as being “out there” in the world (like the angle of the arm seems to be). How about adding a little microphone sensor to the system and have the system control a perception that is some linear combination of the angle of the arm and the level of the sound. … But then you can confuse things by pointing making some loud sounds near the microphone to show that the arm apparently moves in response to the sounds. …

EJ: Sounds something like Post-Acoustic Stress Disorder! Maybe you could call that version “Jumpie.”

All the best!

Erling

Confidentiality: * This message is intended only for the addressee, and may contain information that is privileged and confidential under HIPAA, 42CFR Part 2, and/or other applicable State and Federal laws. If you are not the addressee, or the employer or agent responsible for delivering the message to the addressee, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete the material from your computer.*

Please also note: * Under 42 CFR part 2 you are prohibited from making any further disclosure of information that identifies an individual as having or having had a substance use disorder unless further disclosure is expressly permitted by the written consent of the individual whose information is being disclosed or as otherwise permitted by 42 CFR Part 2.*

Thank you for your cooperation.

I’ve been playing around with my Lego
Mindstorms EV3 set and came up with a demo I thought worth
sharing. It implements a simple proportional control system
to keep a simulated forearm level against changes in the load
placed in its “hand.”

[From Rick Marken (2018.01.12.1610)]

···

Erling Jorgensen (2018.01.12 1535 EST)]Â

BA: I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.â€?..Â

RM: What I would suggest now is that you make a slight alteration to it as a way to make it clear that what the system is controlling is a perception that is not necessary a representation of something that we think of as being “out there” in the world (like the angle of the arm seems to be). How about adding a little microphone sensor to the system and have the system control a perception that is some linear combination of the angle of the arm and the level of the sound. … But then you can confuse things by pointing making some loud sounds near the microphone to show that the arm apparently moves in response to the sounds. …Â

EJ: Sounds something like Post-Acoustic Stress Disorder! Maybe you could call that version "Jumpie."Â

RM: Yes, if you did it the way I described that would probably be the way it looked. But I think a nicer (less jumpie) way to do the demo would be to provide the observer with a tone generator that would allow continuous variation of the amplitude of the tone (I was assuming the controlled variable to be a linear combination of arm angle and tone intensity) so that by slowly varying the volume of the tone you would see slow variations in arm angle to compensate for the sound intensity variations (assuming load constant). You would see more puzzling behavior (of arm angle) if you were able to slowly vary the sound intensity and load magnitude simultaneously and independently (so that the variations in tone intensity are uncorrelated with the variations in load magnitude).Â

RM: It seems to me that this would make a pretty good demonstration of the “control of perception” characteristic of control systems. What do you think?

Best

Rick

Â

All the best!Â

Erling

Confidentiality: * This message is intended only for the addressee, and may contain information that is privileged and confidential under HIPAA, 42CFR Part 2, and/or other applicable State and Federal laws. If you are not the addressee, or the employer or agent responsible for delivering the message to the addressee, any dissemination, distribution or copying of this communication is strictly prohibited. ** If you have received this in error, please notify the sender immediately and delete the material from your computer.***

Please also note: * Under 42 CFR part 2 you are prohibited from making any further disclosure of information that identifies an individual as having or having had a substance use disorder unless further disclosure is expressly permitted by the written consent of the individual whose information is being disclosed or as otherwise permitted by 42 CFR Part 2.*

*** Thank you for your cooperation.***

Richard S. MarkenÂ

"Perfection is achieved not when you have nothing more to add, but when you
have nothing left to take away.�
                --Antoine de Saint-Exupery

[From Bruce Abbott (2018.01.13.1210 EST)

[From Rupert Young (2017.01.12 22.50)]

(Bruce Abbott (2018.01.11.2330 EST)]

I’ve been playing around with my Lego Mindstorms EV3 set and came up with a demo I thought worth sharing. It implements a simple proportional control system to keep a simulated forearm level against changes in the load placed in its “hand.”

Bruce, this is really nice stuff!

Lego does not offer a stand-alone angle sensor, so I ordered one from HiTehnic. It turns out to be rather noisy electrically, and consequently, spurious angle readings are generated that occasionally cause the forearm to twitch, hence the name “Twitchie.” I tried out a smoothing algorithm but this introduced a fair amount of lag in the system’s response to changes of load without entirely eliminating the twitches, so I’ve gone back to using the unfiltered signal.

Is this the HiTechnic gyro sensor? Lego does have an equivalent, which gives you angle, https://shop.lego.com/en-GB/EV3-Gyro-Sensor-45505. I used the latter for my standyuppy Robot, https://youtu.be/FCPDEeosCPU, with some smoothing. What smoothing function did you use? There’s a lot of flexibility with an exponential function which should give some smoothness.

I used the HiTechnic angle sensor. The supplied programming block for the Mindstorms Labview-based programming environment provides the shaft angle (0-359 degrees), accumulated angle, and angular velocity (RPM). As I noted before, HiTechnic claims 1 degree accuracy but I have found mine to be somewhat noisy, so I’m not especially happy with it. For smoothing I simply averaged the current reading and the previous one.

I do have the Lego gyro sensor. I purchased the angle sensor with the intention of building a hardware demo of my self-righting inverted pendulum simulation, but thus far have not been able to get that to work, possibly due to the noisiness in the sensor. The gyro sensor will not do for that application as the pendulum shaft must rotate freely. The gyro’s cable would prevent that.

I haven’t tried the gyro in the Twitchie demo as yet but may give it a try. A possible problem is that the gyro’s cable might offer some resistance to the movement of the forearm.

You may also want to try the Mindsensors AbsoluteIMU, http://www.mindsensors.com/ev3-and-nxt/15-gyro-multisensitivity-accelerometer-and-compass-for-nxt-or-ev3, which is a gyro, accelerometer (gravity sensor) and compass (magnetometer) all in one. I used the gravity sensor in my leggy demo, https://youtu.be/ofN-VrVyKmM, to keep the sensor horizontal. I found this much less noisy than the gyro and you may be able to use it to keep your arm level.

Thanks for the info; that sounds like a nice one to have! By the way, I see that Mindsensors also carries an angle sensor, said to be accurate to ½ degree.

Bruce

[Eetu Pikkarainen 2018-01-17]

[From Rupert Young (2017.01.12 22.50)]

(Bruce Abbott (2018.01.11.2330 EST)]

···

So here’s a nice test of your understanding – can you explain why the hardware implementation can get away without a leaky integrator in the output of the control system, and why the proper output gain is so much lower.

I’d guess because the integration is taking place in the environment, in the damper, which I think Martin has said already.

Could the (quite) flexible ribbon play also a role in integration?

Eetu

[From Bruce Abbott (2018.01.17.1935 EST)]

[Eetu Pikkarainen 2018-01-17]

[From Rupert Young (2017.01.12 22.50)]

(Bruce Abbott (2018.01.11.2330 EST)]

So here’s a nice test of your understanding – can you explain why the hardware implementation can get away without a leaky integrator in the output of the control system, and why the proper output gain is so much lower.

I’d guess because the integration is taking place in the environment, in the damper, which I think Martin has said already.

Could the (quite) flexible ribbon play also a role in integration?

Martin may have a better answer for this than I do; I would say that It does, by storing/releasing the forces accumulated as the rubber band stretches and relaxes. But I think the main factor is the inertia inherent is the system’s moving parts.

Bruce

[Martin Taylor 2018.01.18.00.04]

If you want to know whether something is an integrator, think of it

as a storage cylinder. If you keep putting things into it does it
continue to increase some related variable such as the mass of its
contents? You can use that metaphor quite widely. If you apply a
force consistently to a mass in a friction-free environment, it goes
faster and faster, so the velocity is the result of integrating the
force. If you have a bucket and you pour water into it from a tap,
the water level rises, so the level is the result of integrating the
flow rate (the level being a surrogate for the quantity of water in
the bucket, that same way a neural current is a surrogate for an
averaged neural firing rate). If you keep rubbing on a fabric, it
will become worn and frayed, the wear is an integration of the
rubbing. Lots of things can be integrators. But not all energy storage
elements are. A helical spring is not; you supply it with potential
energy by pushing or pulling on it, but it only stretches or
compresses to the point where its restoration force is exactly the
match of your pushing or pulling force, and when your force is
removed, the spring goes back to its original length rather than
staying at its stretched length.
I don’t know what flexible ribbon Eetu is referring to, or why its
flexibility might affect it’s function (if any) as an integrator.
What is being put into it that makes something continue to increase
proportionately as a result? With the dashpot, the height of the
piston continues to move as a pushing or pulling force is applied,
so the height of the piston is the effect of continuing the applied
force. Take the force away and the piston stops moving, so the
dashpot is an integrator (If it didn’t leak around the piston or
through some small hole, there would be a level of the piston at
which the internal pressure force on the piston matched the ambient
air pressure plus the pushing or pulling force, and it wouldn’t be
an integrator.)
Maybe this metaphor will help determine whether Eetu’s flexible
ribbon is an integrator. What is the input, and what output behaves
proportionately to the sum of what has been input?
Martin

···

On 2018/01/17 7:33 PM, Bruce Abbott
wrote:

        [From Bruce

Abbott (2018.01.17.1935 EST)]

        [Eetu Pikkarainen

2018-01-17]

        [From Rupert Young

(2017.01.12 22.50)]

(Bruce Abbott (2018.01.11.2330 EST)]

          So

here’s a nice test of your understanding – can you explain
why the hardware implementation can get away without a
leaky integrator in the output of the control system, and
why the proper output gain is so much lower.

      I'd

guess because the integration is taking place in the
environment, in the damper, which I think Martin has said
already.

        Could the (quite) flexible ribbon

play also a role in integration?

        Martin may have a better answer for

this than I do; I would say that It does, by
storing/releasing the forces accumulated as the rubber band
stretches and relaxes. But I think the main factor is the
inertia inherent is the system’s moving parts.

Bruce