Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
On Fri, Feb 26, 2010 at 02:26:01PM -0800, I wrote: > Quoting Doug Ausmus : > > >Have you calculated the sampling/control intervals yet? If so, what are the > >fastest ones or most critical ones that must absolutely be deterministic? > > No, but we have them bounded. There is no need to run the control > loop faster than 1000Hz (which is a 25-50Hz *control* bandwidth) as > we proved when considering actuator force would destroy the fins, > yet I think I can easily make the case that it must be faster than > 10Hz (which is a 0.25-0.50Hz *control* bandwidth) due to the fast > roll axis dynamics. > > So, between 10 and 1000 loops per second. If I had to pick today, > I'd say 400Hz. If you don't get too close to 1000 loops per second, you shouldn't have any problem running that on non-real-time Linux. 2.5ms response time should prove easy. Even 1ms wouldn't push it too much. Just run the control loop as a real-time thread with high priority. On the other hand, if you need to actually send data to the actuators that fast, and get data from the sensors that fast, we need to do some careful thinking about USB. > In that time, we need to be able to perform several 12x12 matrix > multiplies, a few martix-vector multiplies, matrix add and subtract > operations, and one or two 12x12 inversions (this is pretty typical > of an optimal control scheme). Or, in other words, a bit of straight-line code whose execution time we could roughly round to 0 on modern processors. ;) - Josh Triplett ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
Quoting Doug Ausmus : Have you calculated the sampling/control intervals yet? If so, what are the fastest ones or most critical ones that must absolutely be deterministic? No, but we have them bounded. There is no need to run the control loop faster than 1000Hz (which is a 25-50Hz *control* bandwidth) as we proved when considering actuator force would destroy the fins, yet I think I can easily make the case that it must be faster than 10Hz (which is a 0.25-0.50Hz *control* bandwidth) due to the fast roll axis dynamics. So, between 10 and 1000 loops per second. If I had to pick today, I'd say 400Hz. In that time, we need to be able to perform several 12x12 matrix multiplies, a few martix-vector multiplies, matrix add and subtract operations, and one or two 12x12 inversions (this is pretty typical of an optimal control scheme). btw, '25Hz *control* bandwidth' means the rocket will follow a 25Hz sine wave 'point in this direction' command of +- 10 degree amplitude with at least +- 7 degree response and less than 90 degrees of phase lag. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
Have you calculated the sampling/control intervals yet? If so, what are the fastest ones or most critical ones that must absolutely be deterministic? On Thu, Feb 25, 2010 at 9:12 PM, I wrote: > Quoting Josh Triplett : > >> >>> http://www.osadl.org/?id=99 >>> >> >> Yeah, a huge amount of -rt has made it into mainline Linux. >> >> The question remains, what do we actually need? >> > > This is a good question, and IMHO the answer is fairly straight forward. > > -We need the ability to run one or two critical control algorithms at > regular intervals. > > -We have to be able to guarantee that they will run on-time if they are > responsible for sampling data. > > -We must guarantee that they will be completed in one control cycle. > > Since the sampling is done by the sensor nodes, and the BPF / LQG / NN / > whatever estimator will determine the state and decimate the data, we only > need to 1) be as 'on-time' as the control cycle and 2) keep up with the > data. > > Our control loop could run like this: > Get data inputs (speed, position, etc.) from BPF. > Run control algo (LQR, MPC, PID, whatever) > Send outputs to the latest values. > Yield until next control cycle. > > As long as this happens within the control cycle period, we win. If it > doesn't, the math that makes it work breaks down and we 'could' crash. To > make this guarantee, industry practice is to build run time metrics that > measure processor load (instant, min, max, running average) based on idle > time. As you build the control system, you watch the metrics. I don't let > systems into 1st production with more than 70% loading. The last one I did > shipped at less than 20% loading (fairly simple system). > > If the control task runs over (takes more than one cycle to complete) we > want to log the event so we can make sure we don't see it, and recover > gracefully if we ever do. > > That's really all that's needed for real time control. > > Thoughts? Challenges? > > > > > > > ___ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics > ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
Quoting Josh Triplett : http://www.osadl.org/?id=99 Yeah, a huge amount of -rt has made it into mainline Linux. The question remains, what do we actually need? This is a good question, and IMHO the answer is fairly straight forward. -We need the ability to run one or two critical control algorithms at regular intervals. -We have to be able to guarantee that they will run on-time if they are responsible for sampling data. -We must guarantee that they will be completed in one control cycle. Since the sampling is done by the sensor nodes, and the BPF / LQG / NN / whatever estimator will determine the state and decimate the data, we only need to 1) be as 'on-time' as the control cycle and 2) keep up with the data. Our control loop could run like this: Get data inputs (speed, position, etc.) from BPF. Run control algo (LQR, MPC, PID, whatever) Send outputs to the latest values. Yield until next control cycle. As long as this happens within the control cycle period, we win. If it doesn't, the math that makes it work breaks down and we 'could' crash. To make this guarantee, industry practice is to build run time metrics that measure processor load (instant, min, max, running average) based on idle time. As you build the control system, you watch the metrics. I don't let systems into 1st production with more than 70% loading. The last one I did shipped at less than 20% loading (fairly simple system). If the control task runs over (takes more than one cycle to complete) we want to log the event so we can make sure we don't see it, and recover gracefully if we ever do. That's really all that's needed for real time control. Thoughts? Challenges? ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
On Wed, Feb 24, 2010 at 10:16:19PM -0800, Andrew Greenberg wrote: > 2. Real time linux patch set > > This looked pretty interesting: > > http://www.osadl.org/?id=99 Yeah, a huge amount of -rt has made it into mainline Linux. The question remains, what do we actually need? - Josh Triplett ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
