PID on a diet? How to tune your PID

There are two facts about PID that truly amazed me. The first one is the amount of people that use it and the second one is how many rules and utilities are out there to tune them.

In my mind, implemeting a PID is a little bit like going on a diet. Everyone wants to loose weight (or improve performance) and there are lots of different diets (tools, rules of thumb, programs) but there is no "magic diet" that miraculously lets you loose weight without some effort.

I don't have a solution for it; if anyone does feel free to add it in the comments!. What I do have is an Adaptive PID Example. It is not perfect, by any means, but shows the interesting concept of using online system identification to identify the plant and change the PID gains based on it.

My colleague Brian McCleery wrote a whitepaper about it and Dr. Jeannie Falcon demonstrated it

Enjoy!

The importance of being in Sync - Centralized vs Distributed

As if often happens, this post comes from a discussion I had with a customer.

One common trend that I see with test systems, is the need for them to be distributed. Having a distributed system has several benefits

- You can get your instrumentation closer to the signals, thus reducing noise. I had a customer that had to read lots of signals from sensors all around a facility and having very long cables didn't work very well with small signals, particulary when the cables had to run paralell for a long trek

- Since there will be some sort of data bus, less cabling is needed. In the case above, some of our systems act as concentrators, drastically reducing the needed lengh of cable

- You can have your instrumentation with the unit under test while having the control of your instrumentation on a safe location.

I think a graph will help explain it

So why don't we have more of this distributed architectures? Well, as you might guess from the post title, we might want to have the data that is collected synchronize. But what does it mean to be "synchronized", it basically means that signals use clocks that are correlated. The tighter the synchronization the closer the clocks need to be in synch.

Is this always neccesary? As usual, it depends on the application and the signals being developed. If you are building a control system based on temperature readings on different parts of the building (to activate the boiler, for example) signals do not need to be closely synchronized, as it is typically a slow control systems and temperature doesn't change rapidly.

On the oposite side of the spectrum, you might be building a iron-bird. In this case you need the information to share a timebase, among other things.

How is this accomplish? You'll have to read my next blog post :D

You want to see a system tightly sincronized? Behold the "Gears of Death" Demo!

Have fun!

MIL, SIL, PIL, HIL..... How is the "in the loop" term used.

Hello all!

It's been a while. I read a while ago that one shouldn't apologise for not writing and just keep writting as if nothing happen, so I'll take that advice.

Often in my customer interactions I hear and use the term "HIL". As you might know, HIL stands for "Hardware In the Loop" and is a testing methodology to verify and/or validate and embedded system design. I heard it was developed around 30 years ago by the automotive industry (feel free to correct me!) and had evolved much since. You can learn more from the wikipedia entry.

Interesting enough, there are a number of different "In the Loop" variations, depending on methodology used, equipment and even culture inside a company. By no means the terms I will refer below are anything like industry standards, but that's the way I have them in my head and make quite sense.

To simplify the explanation, let's assume we are developing an embedded control algorithm that will act over a physical system. The plant execution is needed to provide the information needed to close the control loop on the embedded device.  For example, let's assume the control system for an automatic transmission.

MIL ("Model in the Loop"):  In this instance, both the control algorithm and the plant model (transmission and car) are implemented as simulation models. Here is one example that ships with LabVIEW

SIL ("Software in the Loop"): Here we have created the optimized code for the embedded target but still run it against the plant model on a computer environment.

PIL ("Processor in the Loop"): The embedded code is running on an embedded target. The plant model. Here is great video below about simulation, control theory and a PIL system

HIL(or HWIL "Hardware in the Loop"): Embedded target is finished (or nearly so) and plant model is executed on an external device.

Test Cells: This is an extension of the methodology where both the embedded system and the plant are physically present and external elements are simulated. In the case of our automatic transmission, both transmission and TCU (Transmission ECU) exist and the engine input torque and road/car  load are simulated by electrical motors. Here is an example for a transmission from a customer.

There are many more terms I've heard like "Person in the Loop", "Sensor in the Loop", etc, but thought it would be good just somewhere to start on.

At the end of they day, when I have to explain my kids what I do, I tell them I help people build "simulators"

Using the right tools for the right job

How often has it happened to you that, just because you have a tool handy, you use it for a total different use (PowerPoint to edit images, anybody?). The same happens when you are talking about using tools to design and algorithm, to deploy it and to validate it.

It happens often that the design tools is "missused" to do other kind of work that was not design for. Notice that I use quotes since someone might say that the right tools is the one that gets the job done, independently of other tools out there that might be suitable.

When there is a small team, this issue might not be such. For example, below is an example of a student team that use the same platform for design (model plant and control algorithm), Prototype (using tether IO on a scale system) and Deploy (deploy the algorithm to a Real Time system).

http://multimechatronics.com/images/uploads/movies/NI%20RPI%20Transporter.wmv

This is an example on how using the same platform helps speeding up the left side of the V Diagram.

But there are instances where the team in charge of the plant modeling would like to use one tool. Let's say SimulationX. The team that design the control algorithm use another tool. Let's assume LabVIEW. The embedded team doesn't have any idea of either modeling or control design as they only care to deploy to and embedded target. And there is the validation team that is in charge to validate the embedded code that is more concern on how to build a test system capable of consistently and automatically test different test scenarios. How to bring everything together?

Here is where a platfrom that integrates different tools and can be used without programing skills is very useful.

The image above show a combination where we have a tool to automate the tests (TestStand) and another tool to run the dynamic simulation (VeriStand). This kind of approach allow users to use the tool more suitable to their needs (or the one they are more comfort with) while reusing and interacting with different parts of the organization. And all while saving money in the process!

 Here is a video that goes in detail explaining the architecture in detail.

http://zone.ni.com/wv/app/doc/p/id/wv-2618

Enjoy!

More on the V-Diagram: How to move models around

As I mentioned in the previous post, we have different phases in our (simplified ) development process. Each one of the different phases have their own test where we simulate components and replace them as the physical systems be one available.

When we talk about "model in the loop" all do the components are simulated. If we use a simple process description where we have a control system that acts on a system, both are simulated. Once the control system is validated and embedded code is created, we could replace that control algorithm and add all necessary extra code, like safety and diagnostics) and test it against the plant model, always simulated.

Model in the Loop (MIL)

 Once we have an algorighm that works, we might want to deploy it to a phisical system to test it out. In this stage of the development we are more concerned to have a system that allow us to debug failures related to phisical implemenation than an cost-optimized solution. We have a Rapid Control Prototyping application

Rapid Control Prototyping

Once we have a (more or less) final embedded solution, we might want to test it against a "simulator" that behaves like the system the embedded controller is meant to act on, without the risk of breaking anything (remember, we are still developing and thus prone to failures). This test is called hardware in the loop (HIL)

Hardware in the Loop (HIL)

Hardware in the loop has been around in one fashion or another for many years (I recently read that it started in the 50's) as it has many benefits that I will address in a different post.

Along this concept of moving from simulated models to simulated there other testing option. One that I like the most is "human in the loop" that my friends from Tecnalia. In this case, an embedded controller under test inputs don't come from a test profile a it is common, but rather from a simulation environment that allow the test engineers for more realistic scenarios. Check the email below to see how the move from simulated system to final, hardware based solution.

Enjoy!

V (Or W or Y) Diagram. What’s yours?

I recently talked in a keynote about the V Diagram and how it helps design engineers have a methodology to design and test embedded software. There are many variations of the diagram (thus the W diagram and the Y diagram) but the most common reference I’ve seen by far is the one that uses V.

In a simplified view, the general idea behind the V diagram is to start in the top-left with the requirements development and design of the control strategy and move your way through prototyping, deployment to production hardware, and then on to various real-time testing tasks such as hardware in the loop testing, test cell validation, and so on until the entire system has been implemented and tested.


The goal is to enable system level testing at each phase of the process with a different mix of real and simulated systems. During the design stage everything is being simulated with models. And with each subsequent step in the process simulated models are being exchanged for real components as they become available.

Why would you care? Altough being created in the aerospace industry and heavily adopted in the automotive the benefits of the V diagram are being incorporated into other industries. Check for example this application where Whirpools uses the V Diagram to design and test new advanced 6th sense control algorithm in their high-end washing machines.

http://sine.ni.com/cs/app/doc/p/id/cs-14447

Enjoy!

Not everything is about design

Most of the posts of this blog (including the name) is about how to design an algorithm so that a particular action, typcially a control, can be perform. We have talked in the past about advanced control algorithms and, while control design is fun, we must also talk about how to test and validate those algorithms that we are designing.

While we work on our control problem we work with simulation tools, right? Nowadays simulation is cheap and fast. But one can't always work only with simulations on a computer and need to test embedded devices (where the algorithm is going to run) against something that behaves like the system is being control. Let's make an example. If someone is designing a control algorithm for a cruise control, you "might" want to test it first on a simulated car rather than on a real one, just in case the algorithm is not working as expected.

Here is where some of the "XiL" (Model in the Loop, Hardware in the Loop, Processor in the Loop, Software in the loop.....) come into place. The main idea is to run some or all of the compements of our embedded system in a simulated environment so that we can safely test it.

Here is a video from my colleage Chris Washington explaining more in detail what Hardware in the loop is



Have fun!

Probing your system

When I build a new VI program, I always put VIs and indicator to check the step response an bode plot of my models and, once check, I deleted them.

Thanks to Andy Chang, users can now leverage custom probes to check their models in LabVIEW without the need of extra code!



http://decibel.ni.com/content/docs/DOC-12804

Enjoy!

NIWeek is near!

Hello all

NIWeek is very near. I'm going to improve my "coverage" with news and updates relevant to the world of Algorithm design and Simulation. If you are coming, feel free to comment a post to meet!

I'll leave you with the vide0s from NIWeek last year



Enjoy!

Want to get an sbRIO? submit your Inverted Pendulum control code in LabVIEW

Ok, that might be a little bit long of a title, but will give you the idea. National Instruments and Ammons Engineering are sponsoring a code challenge. The goal is to design and implement a control algorithm for the... guess what... exactly: An inverted pendulum.

The best part (other than the fun of programing) is that we are giving way a NI Embedded Kit!!!

You can see all the details in the NI Community Forums

http://decibel.ni.com/content/message/16920#16920

Enjoy!

Another inverted pendulum.

By now you probably know I have something for inverted pendulums. I just found this project done in the University of Michigan as a Senior Design project. I like this particular project because:

- The inverted pendulum model was provided using Matlab, but it was implemented MathScript
- LabVIEW used for the control algorithm and cRIO for the embedded control platform
- I like the enclosure used to make it safe. This system is meant to be in a museum for children
- I also like the use of magnets to disturb the plant. Slick!

Here is a link to the youtube video



I know, I have to start posting about something different from inverted pendulum :D

Enjoy!

How low can you go? PID Performance?

I can't wait for Toy Story 3 to come out in cinemas. I still remember when I skip a couple of classes in university to see Toy Story with a couple of good friends and how long we stayed afterwards discussing the merits of the 3D generated characters.

One of my favorites sequences in Toy Story 2 is when in Al's Toy Barn they are looking for Buzz and drive along the isle where the Barbies are playing and one of the games go "how far can you go, how far can you go".

I guess that applies today to computing plaftorm used for control. There is a wide variety, from multicore CPUs machines to 8 bit processors and the control engineer has to find the balance between performance and cost (among other things). I wanted to test the performance on three embedded computing platforms that I have on my desk. A PXI, my Laptop, a CompactRIO and and embedded ARM board.

I've successfully run Simulation Loops (the backbone of simulations in LabVIEW) in all of those platforms. More soon!

Build your own robot

It's probably no surprise that I'm a Sci-Fi fan. I always wonder how many of the technical marvels that appear in Sci-Fi books and movies are actually going to happen in real live. I particular enjoy reading old Sci-Fi books because it is easier to check those futuristic predictions with our current lives. Some are way off, like Isaac Asimov mentioning the "universal sliding rule", and some are right on the spot, like with William Gibson's Neuromancer.

I recently went to see "Surrogates" and, altought I will keep to myself what I think about the movie but it bring the point of human-machine interactions, where the limits are going to be and so on. Although we are way off of creating such complex machines (like the ones we found in I Robot") we are taking steps to be there.

I it great to work in a company like National Instrument whose software and hardware are involved in creating and prototyping robot. Here are a few examples

Lego-based Robots

Automonous Car


Flying Quadcopter(becacuse Helicopter are for sissies)

But I recently came across this one. I couldn't help but to think in the movie "Transformers" :D



Enjoy

NI Week Day Two

So, what is my best new feature of Day 2? Altough is difficult to decide, without any question is the NI Hypervisor.

This new tools allow to run both Windows and LabVIEW RT in the same CPU!!!! The idea, although not new, is genius. If a computer has several CPUs, why not have different OS running on those different CPUs? I know the problem is way more complex of what I've just mentioned, that you get the latest idea, right?

here is the video with the Hypervisor running

http://zone.ni.com/wv/app/doc/p/id/wv-1695

If you want to have a more, detailed information on how the Hypervisor works, check this link

http:\\www.ni.com\virtualization

Enjoy!

NI Week Day One

What an exciting day! For those of you who are not familiar with the NIWeek Keynote, day 1 is when we show new product that are typically release that same day. As promised, here is a list of the products that are more relevant to control application

- LabVIEW 2009. As we have been doing for the past 5 years, we release a new version of LabVIEW. At this point I don't think many people is surprised we announced we are moving to a yearly release cycle. Probably the most shocking news is that we change the "version" name of LabVIEW to reflect that change.

You can find new features in LabVIEW 2009 in the following link.

http://www.ni.com/labview/whatsnew/features.htm

Enjoy

You can also download the eval version and start using it today

NIWeek 2009 with a spin on control

NIWeek 2009 is almost here.

NIWeek is the industry's premier event on graphical system design and attracts more than 3,000 of the world's brightest engineers, educators, and scientists. The conference lasts for three days full of interactive technical sessions, targeted summits, hands-on workshops, and exhibitions on the latest developments for design, control, automation, manufacturing, and test.

With so many new features is often difficult to find what is more useful or interesting for your particular case. I'm going to make a wild guess here, but if you are reading this blog you might be interested in (mostly) control and simulation stuff. So, for the first time, this year you are going to have someone who will point you to the new features and applications that are geared toward those areas.

Enjoy!

A little experiment

Let me do a little experiment with you. Here at National Instruments we tend to put a lot of information in PowerPoint format. Well, I've recently seen in Jim Cahill's blog how he shares slides using SlideShare, so I decided to give it a try myself.

Let me know what you think. Enjoy!

How To Improve PID

View more Microsoft Word documents from JavierGutierrez.

No software? No problem!

Hello there!

I've recieved some emails asking how to run the code I shared in the previous posts. Users might be interested in LabVIEW for simulation but don't have LabVIEW and/or some of the extra libraries needed.

Fear not, Guti is here to help you out!

National Instruments allow users to download LabVIEW-related software for free and evaluate it for 30 days. Follow this link to get the software

https://lumen.ni.com/nicif/us/evaltlktcds/content.xhtml

here, you can download not only core LabVIEW, but also very cool related toolkits and modules like the Control Design and Simulation Module, System Identification Toolkit, PID Control Toolkit, Real Time Module, FPGA Module, Statechart Module and more..

Go ahead, download all of them! but make sure you have a broadband connection :D

Now that you have the product, let me help you get started. There are a number of tutorials about LabVIEW on the web, but I have to suggest one place to start with, check out this link

I know, I know, you are eagerly to get started and don't feel like spending hours reading manuals, right. Well, here are a couple of youtube videos for the control geek that there is in you! Emily recorded a while ago, but is still valid




Here is one I just recorded (sorry, my voice is not as nice as Emilie's) the other day using the simulation loop



Enjoy!

Will LabVIEW take us to warp speed?

I don't know many engineers that are not fun of Star Trek. It's probably one of the first TV shows/movies where engineering had and leading role; as a matter of fact I do know a few engineers to whom Star Trek was their inspiration to became engineer.


One of the recurring topics is the propulsion, or the warp engine. It seems the engineering crew deck (and Scotty, LaForge, Be'Elanna an others) are always struggling to maintain the warp core "contained". I've always guessed that containment was some kind on magnetic field, since the exotic matter that power the different Enterprise ships might not be just put into a fuel tank.

That let me think of one application at the Max Planck Institute for Plasma Physics in Garching, Germany, where researchers implemented a tokamak control system to more effectively confine plasma. Probably the most cool technology used in this application was LabVIEW's capability to leverage multiple cores present in computers to split matrix multiplication operations using a data parallelism technique on an octal-core system


LabVIEW is also bringing us closer to interact with machines using our voice (or thought). Here is an application where a wheelchair was controlled using the mind. The question is, are we going to program LabVIEW???

Enjoy!

Time to share some code

By popular request, here are the code of the two examples we've posted before.


Let me start with the pendubot. I reused (A.K.A "stole") this code from Alex. This example does it all! It linearizes a the (obviously non-linear) model, designs a full state controller, simulate the behaviour of the controller with the non linear system and, if you happen to have a pendubot and a cRIO at hand, actually runs the controller to the real think! All you need is LabVIEW and the Control Design and Simulation module (for the design and simulation) and the Real Time and FPGA module (for the controller).

By the way, if you run the controller, you can actually see how the 3D picture does the same as the real thing!. You can download the code form NI Community

http://decibel.ni.com/content/docs/DOC-4788


Now is my turn.



Below is the code for the Active Suspension Demo from Quanser. I know, I know.... is not as complete as Alex's, but gets the job done. It implements two control loops in parallel, one to control the "road" and one to control the "suspension" you can change both controllers on the fly as well as setpoint magnitude and frequencies


http://decibel.ni.com/content/docs/DOC-4789

Enjoy!