For anyone who doesn't understand what "control" is, the following is a small example of the work of a "control engineer". In this case, the engineer is one of my students. He's an undergraduate in a class I taught last quarter; this YouTube video is a demonstration of his final project for the class:As shown, his controller manages to keep the helicopter stabilized in a position that gets set by the joystick. The computer "flies" the helicopter with a heading set by a human via joystick. When they push on the helicopter, they're simulating a disturbance like a heavy wind gust. The helicopter's controller quickly brings it back to its old state. What you don't see is that the controller has been designed to do this as smoothly as possible (e.g., to prevent "jerkiness" within the helicopter).
This is a concrete example of classical control design. What I do in particular in my own research is quite a bit different. However, the video is a nice demonstration about what "control engineers" (like me) do.
Personal weblog of Ted Pavlic. Includes lots of MATLAB and LaTeX (computer typesetting) tips along with commentary on all things engineering and some things not. An endless effort to keep it on the simplex.
Showing posts with label control systems. Show all posts
Showing posts with label control systems. Show all posts
Wednesday, June 24, 2009
Thursday, April 23, 2009
Warning: Quanser flexible joint uses different angle convention than motor
Quanser Academic makes a line of products, which you can see demo'd at their YouTube channel, that are sold to university laboratories as teaching aids for control theory. Today I noticed a funny undocumented quirk about one of those products. I have notified Quanser of this, and there is some indication that they will update their documentation to reflect this quirk. However, because their documentation is not on-line, it's hard to see how that update will ever reach people who have already bought these products.
I TA a graduate control lab, and today's lab had the students design and implement an LQR controller that made use of a full-state observer to control Quanser's flexible joint. The motor angle is measured by a shaft encoder (which is the output we use to drive our observer), and the arm angle is measured by another encoder. We don't need the measured arm angle because we're using a full-state observer, but we still capture it for comparison to our estimated arm angle.
The students build a controller that stabilizes the plant to a moving equilibrium that tracks a square wave. At every transition, the observer trajectories had some peaky transients, as is expected, but it appeared like they were always in the wrong direction for the arm angle and its speed. I dismissed this as peaking, but one group wanted to investigate further, and so I had them track a sine wave instead. What did we find? The arm angle and speed estimates were always EXACTLY 180 degrees out of phase with the measurements.
I was shocked, and so I looked into it. Visually, I could tell that the FLEXIBLE JOINT's ANGLE ENCODER is mounted UPSIDE DOWN with respect to the motor's angle encoder. That means that rotating the motor to the "right" produces a positive angle even though rotating the JOINT to the right produces a NEGATIVE angle! The observer had it right; it was the MEASUREMENTS that were incorrect! (I built a minimal example to test my hypothesis, and what I say matched what I observed; the opposing rotations lead to equal signs)
Nowhere is this documented. Because this angle is not directly driven (it's coupled to the assembly via springs) and the arm+spring system is naturally stable and fast, this POSITIVE FEEDBACK doesn't lead to destabilize the system unless you have extremely high gain. So I'm guessing no one ever noticed. Multiplying the measurement by -1 restored intuition. I drilled down into some Quanser demo code, and I found that they do the same thing in their controllers. I have no idea why they would not document this in their rotary joint docs. Do they expect everyone to go through all of their MATLAB and Simulink code?
I could understand this error if the flexible joint was a generic component made by a different company, but the joint is solely for the purpose of connecting to the motor, and so it would make sense that its encoder orientation would match the motor encoder orientation! At the moment, we need different gains for both.
I TA a graduate control lab, and today's lab had the students design and implement an LQR controller that made use of a full-state observer to control Quanser's flexible joint. The motor angle is measured by a shaft encoder (which is the output we use to drive our observer), and the arm angle is measured by another encoder. We don't need the measured arm angle because we're using a full-state observer, but we still capture it for comparison to our estimated arm angle.
The students build a controller that stabilizes the plant to a moving equilibrium that tracks a square wave. At every transition, the observer trajectories had some peaky transients, as is expected, but it appeared like they were always in the wrong direction for the arm angle and its speed. I dismissed this as peaking, but one group wanted to investigate further, and so I had them track a sine wave instead. What did we find? The arm angle and speed estimates were always EXACTLY 180 degrees out of phase with the measurements.
I was shocked, and so I looked into it. Visually, I could tell that the FLEXIBLE JOINT's ANGLE ENCODER is mounted UPSIDE DOWN with respect to the motor's angle encoder. That means that rotating the motor to the "right" produces a positive angle even though rotating the JOINT to the right produces a NEGATIVE angle! The observer had it right; it was the MEASUREMENTS that were incorrect! (I built a minimal example to test my hypothesis, and what I say matched what I observed; the opposing rotations lead to equal signs)
Nowhere is this documented. Because this angle is not directly driven (it's coupled to the assembly via springs) and the arm+spring system is naturally stable and fast, this POSITIVE FEEDBACK doesn't lead to destabilize the system unless you have extremely high gain. So I'm guessing no one ever noticed. Multiplying the measurement by -1 restored intuition. I drilled down into some Quanser demo code, and I found that they do the same thing in their controllers. I have no idea why they would not document this in their rotary joint docs. Do they expect everyone to go through all of their MATLAB and Simulink code?
I could understand this error if the flexible joint was a generic component made by a different company, but the joint is solely for the purpose of connecting to the motor, and so it would make sense that its encoder orientation would match the motor encoder orientation! At the moment, we need different gains for both.
Labels:
annoyances,
control systems,
engineering,
estimation,
laboratory,
observer,
quanser
Friday, September 19, 2008
Pretty analog docs
Lately, I've noticed more hits on my website for documents that I put together for some classes that I've taught. So I decided to collect all the substantial ones and list them in one place. I figured I'd do the same here...
- Analog Electronics Information
- ECE327 — Electronic Devices and Circuits Laboratory I (I've included lots of information, documentation, and links on this course web page) Some example documents that I produced for the lab:
- Transistor Basics — Introduces bipolar (junction) transistors and gives schematics for several common circuits.
- Practical Integrators — Introduces the operational amplifier implementation of an integrator and discusses solutions to practical problems with the circuit.
- Linear Voltage Regulators — Introduces the Zener shunt regulator and several series pass-transistor regulators based on it. Also discusses practical uses of the LM317 integrated circuit bandgap reference.
- Voltage Regulators Lab Report Strategies — Gives more analytical details about shunt and series regulators used in the lab.
- LM317 Regulated DC Supply Quick Refrence — Quick reference on configuring an LM317 as a 10 VDC regulated supply (with basic capacitive bypassing).
- Bandgap Voltage Reference Example: LM317 — Explains how the temperature-independent bandgap reference circuit within the LM317 works.
- Transistor-Based Ramp Generator — Describes two ways to build a ramp generator using a PNP transistor configured as a current source.
- Current Sources and Ramp Generators — A more complete discussion of ramp generators and current sources. Includes (impractical) operational amplifier implementations as well.
- Transistor-Based Ramp Generator (Quick Reference) — Short description of two different transistor-based ramp generators.
- Single-Rail Level-Shifter Amplifiers — Describes several ways of building a level-shifter amplifier when only one power supply rail is available.
- Dual-Rail Level-Shifter Amplifiers — Describes several ways of building a level-shifter amplifier when only two power supply rails are available.
- Current Driver for (Infrared) LED — Describes four different ways of building a current driver for interfacing a low-power digital signal to an LED that requires a significant amount of current for operation.
- Output Filtering Laboratory Procedure — Describes level-shifter amplifier, Sallen-Key Butterworth low-pass filter, and a current driver for an 8 Ω speaker that uses a BJT push-pull Sziklai-based output stage. Also discusses other
- Choosing an Output for Maximum Power: Impedance Matching — Discusses why maximum power is delivered when a load impedance is matched to its source impedance.
- Digital-to-Analog Converter (DAC) Lecture Notes — Discusses several sampling, quantization, and modulation issues. Also includes figures explaining structure and function of R-2R ladder and "H" bridge.
- Part pinout quick references:
- Bipolar transistors, Diodes, and Electrolytic capacitors
- MOS switch, GP operational amplifier, CMOS inverter, 555 timer, and CMOS array
- Zener diodes, NPN bipolar transistors, LM317 regulator, and Electrolytic capacitors
- 741 and 351 operational amplifiers with specifications and 555 timer
- Open-collector voltage comparator, GP operational amplifier, JK flip-flop, MOS switch, Diodes, Bipolar transistors, and Electrolytic capacitors
- MOS switch, MOS-input operational amplifier, MOS inverter, JK flip-flop, Infrared LED, Infrared photosensor, and Bipolar transistors
- LM317 regulator, GP operational amplifier, Bipolar transistors, and Electrolytic capacitors
- ECE209 — Circuits and Electronics Laboratory
(I've included lots of information, documentation, and links on this course web page)
Some example documents that I produced for the lab:- Review of Circuits as LTI Systems — Brief overview of the mathematics and structures commonly encountered when analyzing linear circuits.
- Sources of Phase Shift — Uses simple low-pass and high-pass RC filters to show sources of phase shift in (electrical) LTI systems.
- Phase-Shifter Circuit — Describes and analyzes a simple all-pass filter phase-shifter circuit.
- Lissajous Figures — Describes the use and interpretation of input-to-output Lissajous figures for analysis of linear time-invariant (LTI) systems in the laboratory.
- Digital-to-Analog Converter (DAC) Lecture Notes — Discusses basic DAC circuit implementation issues. Includes descriptive figure of R-2R ladder.
- Part Pinouts — Gives descriptive part pinouts for several parts used in an introductory lab on analog electronics, including LM741, LM747, 1N914, 1N4148, 2N3904, 2N2222, and Electrolytic capacitors.
- ECE327 — Electronic Devices and Circuits Laboratory I (I've included lots of information, documentation, and links on this course web page) Some example documents that I produced for the lab:
- Control Systems Information
- ECE557 — Control, Signals, and Systems Laboratory (classical control lab)
(I've included lots of information, documentation, and links on this course web page)
- ECE557 — Control, Signals, and Systems Laboratory (classical control lab)
Monday, June 23, 2008
Letter to Prospective Graduate Student
Now that all of my adviser's older graduate students have graduated, I have somehow become an international ambassador (completely against my will) for the university. I've been getting e-mails from students interested in getting their PhD in the area of control here at OSU. Here's a sample response, which may or may not be helpful to some random Googler out there.
I'm leaving out many details that I bitch about frequently among friends. Maybe that's because I'm optimistic that the university (and the ECE department) will "change" for the "better," or maybe that's because I don't want to be the lone miserable schmuck.> I am interested in Fuzzy controllers in Control Systems
> and have done some paper presentation on that in under
> Grad school. I plan to take the same for my PhD studies.
It's good to hear that you're considering advanced
studies in control systems. Keep in mind that state of the
art control research is not in fuzzy control. Modern control
uses a more rigorous mathematical approach. Recent interest
in nonlinear systems has made the mathematics of real
analysis an important tool for the control researcher.
That being said, Professors Passino and Yurkovich are
experts in fuzzy control (you can see their book on the
subject). Professor Passino's current research investigates
biological and psychological systems (in particular, how to
integrate engineering ideas into those fields and use
insights from those fields to inspire engineering
solutions). Professor Yurkovich is highly active in
automobile control system research (spanning everything from
the automobile itself to the manufacturing systems that make
it). Because Professor Yurkovich's research is a little more
conventional, it tends to be more easily funded.
Additionally, there are several other strong control
faculty members here at OSU. Professor Ozguner, for
example, is a leader in coordinated control (e.g.,
integration of multiple vehicles or systems with independent
controllers). Professor Serrani is an expert in nonlinear
dynamics (e.g., control of fluid flow through an
airbreathing supersonic jet). Check out OSU's ECE webpage
for more information on the other control faculty.
> 1. How do you find the course you are pursuing. That is
> about the quality of teaching, course material and other
> facilities at the university?
I think that the courses at OSU are very strong,
especially in control and *mathematics*. Keep in mind that
OSU's math department has a strong theoretical bias, which
actually makes it ideal for engineering disciplines
surrounding communication systems, signal processing, and
control systems (a focus on algebra for the first two and
real analysis for the latter). All of these courses are
taught by experienced faculty, and I have been very happy
with the level of instruction here at OSU.
That being said, some of our facilities are older.
Additionally, primarily due to lower undergraduate
enrollment in the ECE department, *internal* funding
opportunities for graduate students have been on the
decline.
> 2. Do I need to get in touch with any Professors before
> applying for admission?
*YES*, it would be a good idea to see
what space will be available. However, many will probably
tell you to get back in touch with them after you have been
admitted to the program. Still, you should contact them to
see if they'll be available to take on new students. It is
usually best to make first contact by e-mail (though,
depending on the professor, your mileage may vary). Make your
intentions clear in your e-mail's subject (e.g., "Considering
PhD Study in Control Systems Area at OSU").
Keep in mind that many professors will favor PhD
students over MS students (which shouldn't be an issue in
your case). Additionally, the OSU ECE department has
recently "modernized" its advanced degree program. Now there
is a 4 year (nominally) "direct to PhD" program that may (or
may not) be attractive to you. You might want to consult the
"ECE Graduate Handbook" (available on the ECE webpage in the
section for graduate students) to get more details about
those programs.
In the meantime, you should definitely be pursuing
outside funding options. Having outside funding will make
you more attractive to any university and will give you more
flexibility when doing your own research.
I hope that helps. Best wishes --
Ted
Labels:
advice,
control systems,
doctoral program,
ECE,
fuzzy control,
grad school,
graduate programs,
nonlinear control,
OSU,
PhD,
schmucks
Monday, December 25, 2006
Roomba Robots as Development Platforms
Evidently, the iRobot home robots (the Roomba and Scooba varieties, with emphasis on the former) are now being used as robotic development environments.
It makes sense. They're tiny. They're robust. They're packed with sensors and motors. On top of all of this, they've gone through a modern manufacturing process so they make for a nice little package. On top of all of this, iRobot provides a serial interface by way of a 7-pin mini-DIN on top of the unit (this pin-out is the same as an 8-pin mini-DIN, so it's not so difficult to find a cable to work with it).
How do you use all of this? Well, iRobot has a developer page to get you started. From there, you can find information about the serial command interface (SCI). From the resources there, it's pretty easy to hack together serial interfaces to get up up and running programming the internals of your robot . . .
. . . HOWEVER, RoombaDevTools has done a great deal of the work for you. The two apps that I think are the coolest are the RooStick and the RooTooth.
So RoombaDevTools gets you right up and running with documentation, hardware (including cables), and software as well as lots of other helpful stuff. PLUS most of the importnat software is either platform-independent (i.e., Java libraries made for the JVM) or provided for OS X, Windows, and more. IN FACT, a common application is to combine a Roomba with a control system built on top of a GumStix. That's WAY cool.
So there ya' go... The Roomba(+Gumstix, perhaps) -- the next affordable robot development platform.
It makes sense. They're tiny. They're robust. They're packed with sensors and motors. On top of all of this, they've gone through a modern manufacturing process so they make for a nice little package. On top of all of this, iRobot provides a serial interface by way of a 7-pin mini-DIN on top of the unit (this pin-out is the same as an 8-pin mini-DIN, so it's not so difficult to find a cable to work with it).
How do you use all of this? Well, iRobot has a developer page to get you started. From there, you can find information about the serial command interface (SCI). From the resources there, it's pretty easy to hack together serial interfaces to get up up and running programming the internals of your robot . . .
. . . HOWEVER, RoombaDevTools has done a great deal of the work for you. The two apps that I think are the coolest are the RooStick and the RooTooth.
So RoombaDevTools gets you right up and running with documentation, hardware (including cables), and software as well as lots of other helpful stuff. PLUS most of the importnat software is either platform-independent (i.e., Java libraries made for the JVM) or provided for OS X, Windows, and more. IN FACT, a common application is to combine a Roomba with a control system built on top of a GumStix. That's WAY cool.
So there ya' go... The Roomba(+Gumstix, perhaps) -- the next affordable robot development platform.
Labels:
control systems,
controls,
development,
geeky,
hobby,
irobot,
robotics,
robots,
roomba,
scooba
Subscribe to:
Posts (Atom)