Software Engineering
-
Joan Murt wrote:
Speeds of up to 10 m/s. (in one axis the TCP can reach 30 m/s).
30? that is only 58knots, that is slow. Are you driving rather than flying? or running miniatures? of course that is fast for our tanks, but we do hold the land-speed record for remote controlled full-scale trucks. :rolleyes:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
Are you driving rather than flying? or running miniatures?
No! :-O we are not making anything related to vehicles neither planes, my comment started inside a plane a couple of weeks ago, and my question was about being curious. We make special machine prototypes, this last month we have had an article in an electronic magazine about our job. so if you want, I could send you the link, but again it has nothing to do with planes or vehicles. It's completely different. I was telling you that we are used to those other value ranges because our job needs that and that the most important thing here is to get it as precise as possible 100 micrometers would be nice. But again, this has nothing to do with vehicles (flying, driving or going under water) (but I can promise you that sometimes I would drive far away from here in order to kick a machine in order to make it fly and then leave it fall into the see). Regards.
-
ednrgc wrote:
Taking off in an F16 isn't a problem. Landing one needs to be (almost) pinpoint exact.
About ten years ago, I remember an F16 running out of fuel. The pilot had to glide it in. There was a camera onboard the plane. CNN played the film along with the sound of the pilot's voice as he brought it in. You could tell he was pretty scared by the heavy breathing in his voice, but he stuck with it and brought it in safely instead of bailing. Never forget watching that.
-
I take it you find computer games boring after that :laugh:
Trollslayer wrote:
I take it you find computer games boring after that
only flight simulation. I prefer ancient fantasy, or futuristic Sci-Fi types, far away from the real world. WWII and army sims are too close to day-to-day work, so I go for the outlandish, martial arts games (providing they have a good story), sci-fi games (sometimes even if they don't have a good story), and magic. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I would stay in my unconfortable seat, order a stiff drink, and fall asleep.
Maximilien Lincourt Your Head A Splode - Strong Bad
:laugh: Same here :rolleyes:
-
Joan Murt wrote:
We finally decided that fuzzy logic and neural networks should do the trick, we arrived at that decision because we believed that PID's wouldn't be the right choice as the environment is changing constantly (wind, air pressures, ...).
hehehe, you are making it very difficult. Drop back to the simple idea. When a plane is in the air, you only need to report its position, control should be based on immediate effects without respect to anything else. If the plane position is dropping, pitch up, if rising, pitch down. Give a little leeway so that you are not "always" adjusting position due to error in position calculation and keep things steady. The times you care most for "accuracy" is landing and take off. Add additional position correction for pinpoint accuracy, and apply the same logic above with greater accuracy and control.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
Drop back to the simple idea. When a plane is in the air, you only need to report its position, control should be based on immediate effects without respect to anything else. If the plane position is dropping, pitch up, if rising, pitch down. Give a little leeway so that you are not "always" adjusting position due to error in position calculation and keep things steady.
Yes!
-
Hmm. If it was an F-16 (not exactly an airliner), I would board immediately. I used to work for a company that did independent verification and validation testing for an experimental version of the F-16 flight control software. We built an emulator of the flight control system from the original design documents. During our tests, we uncovered one minor design flaw, and a couple of minor performance issues. None of these problems affected normal flight or pilot survivability.
Software Zen:
delete this;Exactly ! I think you can by no means compare the development process of "normal" software with the development process of Software where the life of humans could be at stake, if an error occurs. I myself worked for a few years for a company that is a well known supplier for motormanagement systems and Software for Diesel engines in cars. And I can say that beginning with design, coding rules, use of a huge number of predefined and well tested macros (instead using your own stuff), code review by at least 3 persons for every single piece of software you write, testing the software on system simulators, after this, testing the software on real engines, exact documentation of the outcome of testcases, etc... it's a VERY well defined process that minimizes the risk of failures. A process that is lightyears ahead of the processes used in non-critical software. (As far as I have found out till now). Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
-
Exactly ! I think you can by no means compare the development process of "normal" software with the development process of Software where the life of humans could be at stake, if an error occurs. I myself worked for a few years for a company that is a well known supplier for motormanagement systems and Software for Diesel engines in cars. And I can say that beginning with design, coding rules, use of a huge number of predefined and well tested macros (instead using your own stuff), code review by at least 3 persons for every single piece of software you write, testing the software on system simulators, after this, testing the software on real engines, exact documentation of the outcome of testcases, etc... it's a VERY well defined process that minimizes the risk of failures. A process that is lightyears ahead of the processes used in non-critical software. (As far as I have found out till now). Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
marius_romanus wrote:
I myself worked for a few years for a company that is a well known supplier for motormanagement systems and Software for Diesel engines in cars. And I can say that beginning with design, coding rules, use of a huge number of predefined and well tested macros (instead using your own stuff), code review by at least 3 persons for every single piece of software you write, testing the software on system simulators, after this, testing the software on real engines, exact documentation of the outcome of testcases, etc... it's a VERY well defined process that minimizes the risk of failures. A process that is lightyears ahead of the processes used in non-critical software. (As far as I have found out till now).
...and calender years more time consuming, which is why normal software development doesn't use anything like it.
-- Rules of thumb should not be taken for the whole hand.
-
marius_romanus wrote:
I myself worked for a few years for a company that is a well known supplier for motormanagement systems and Software for Diesel engines in cars. And I can say that beginning with design, coding rules, use of a huge number of predefined and well tested macros (instead using your own stuff), code review by at least 3 persons for every single piece of software you write, testing the software on system simulators, after this, testing the software on real engines, exact documentation of the outcome of testcases, etc... it's a VERY well defined process that minimizes the risk of failures. A process that is lightyears ahead of the processes used in non-critical software. (As far as I have found out till now).
...and calender years more time consuming, which is why normal software development doesn't use anything like it.
-- Rules of thumb should not be taken for the whole hand.
dan neely wrote:
...and calender years more time consuming, which
Of course that is true ! But in this area the customers are willing to pay for it ! I only came up with this because of the initial post that leaves me thinking that people who won't board a plane if their developers wrote the software for it, do not know what the standards for writing security relevant software are. Marius
--------------------------------------------------------- Complete freedom is a state without context ---------------------------------------------------------
-
At a recent computer software engineering course, the participants were given an awkward question to answer: "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" Among the ensuing forest of raised hands only one man sat motionless. When asked what he would do, he replied that he would be quite content to stay aboard. With his team's software, he said, the plane was unlikely to even taxi as far as the runway, let alone take off.
Regards, Satips.
Having spent 5 years writing air traffic control software, I nonetheless continue to board planes, since I tend to fly in a somewhat well lubricated state anyway. It's the people that know me who are nervous. :-D
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
At a recent computer software engineering course, the participants were given an awkward question to answer: "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" Among the ensuing forest of raised hands only one man sat motionless. When asked what he would do, he replied that he would be quite content to stay aboard. With his team's software, he said, the plane was unlikely to even taxi as far as the runway, let alone take off.
Regards, Satips.
-
Satips wrote:
"If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?"
No. I would not disembark. In fact we have F4 flying falcon Phantom's remote flown via software regularly. So yes, we fly planes via software all the time, and they fly and land. -- modified at 10:40 Friday 29th December, 2006 (I claim as an excuse, lack of coffee and distraction from girlfriend in town. ;) )
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
distraction from girlfriend in town
Think of the poor guys who have this all the time :cool:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
:laugh:
WM. What about weapons of mass-construction? "You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
Well, a significant proportion of modern airliners have several parts tested on machines my company makes and I write the software for.... And they wonder why I wanted a USB Ice maker for my morning whisky.... OK, I'm kidding about the drinking at work, and other people do put my stuff through tests, but the responsilbility does occasionally blow me away when I think about it. And as my customers are all around the world, I fly on those planes too. Even if I don't care about *your* life, I care about my own! Iain. [I'm sure I replied to the main message of this thread. ah well... I'll blame shog!]
-
Jeffry J. Brickley wrote:
Drop back to the simple idea. When a plane is in the air, you only need to report its position, control should be based on immediate effects without respect to anything else. If the plane position is dropping, pitch up, if rising, pitch down. Give a little leeway so that you are not "always" adjusting position due to error in position calculation and keep things steady.
Yes!
I never said your reasons were wrong, only your conclusions. Simplification can never replace accuracy and in many situations speed. In the example above, you know where you need accuracy, landing and take off, and increase accuracy to the sub-foot. In air, accuracy is based on mission need, which in some cases may be more than you can imagine, but the ultimate accuracy is based on preservation of the craft which means altitude and smooth flight (a rough flight puts more effort on the control structures). What you ignore is that some of us have a great deal of experience in putting accuracy where it is needed. When we tell you we need more accuracy than you want to give people, you throw a hissy fit saying all of us don't know what we are talking about, quote some idiotic irrelevant paper and quote your math education. The world is larger than what you imagine, and accuracy is very important in some places. I, for one, would not want to pilot a UAV at low-altitude through a canyon using your ideas on math. Of course, the good news, it wouldn't be much effort, since the vehicle would crash rapidly and your job would be done.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Jeffry J. Brickley wrote:
distraction from girlfriend in town
Think of the poor guys who have this all the time :cool:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!peterchen wrote:
Think of the poor guys who have this all the time
Eventually I hope to be one of them. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I never said your reasons were wrong, only your conclusions. Simplification can never replace accuracy and in many situations speed. In the example above, you know where you need accuracy, landing and take off, and increase accuracy to the sub-foot. In air, accuracy is based on mission need, which in some cases may be more than you can imagine, but the ultimate accuracy is based on preservation of the craft which means altitude and smooth flight (a rough flight puts more effort on the control structures). What you ignore is that some of us have a great deal of experience in putting accuracy where it is needed. When we tell you we need more accuracy than you want to give people, you throw a hissy fit saying all of us don't know what we are talking about, quote some idiotic irrelevant paper and quote your math education. The world is larger than what you imagine, and accuracy is very important in some places. I, for one, would not want to pilot a UAV at low-altitude through a canyon using your ideas on math. Of course, the good news, it wouldn't be much effort, since the vehicle would crash rapidly and your job would be done.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
Simplification can never replace accuracy and in many situations speed.
Of course not. But simplification can increase reliability and usually does speed things up.
Jeffry J. Brickley wrote:
When we tell you we need more accuracy than you want to give people...
But I place absolutely no restrictions on accuracy - except, of course, necessity. Whatever degree of accuracy is necessary is not only fine with me, but is exactly what I would recommend. No more, no less.
Jeffry J. Brickley wrote:
I, for one, would not want to pilot a UAV at low-altitude through a canyon using your ideas on math.
I'm not so sure, because I think, in the end, we'd do it essentially the same way. Too far to the left, go right; too far to the right, go left. With a bit of hysteresis, of course. I know I wouldn't, and I don't think you would try to "calculate" the required path in its entirety; that sort of thing just doesn't work in real life - even with extreme precision. The place, I think, where we would differ is that I would ultimately choose to work with integers or fixed-point numbers representing a sufficiently small unit of measure on one or more trivial, dedicated (but networked) stack machines, while you would prefer (I think) to work with floating point numbers on a multi-tasking, multi-core, parallel processing CISC computer. But that's a difference in technique, not essence, because my "collection" of stack machines, taken as a whole, is a multi-tasking, multi-core parallel processing system; it's just more loosely coupled and is based on a simpler architecture and a smaller instruction set.
-
Jeffry J. Brickley wrote:
Simplification can never replace accuracy and in many situations speed.
Of course not. But simplification can increase reliability and usually does speed things up.
Jeffry J. Brickley wrote:
When we tell you we need more accuracy than you want to give people...
But I place absolutely no restrictions on accuracy - except, of course, necessity. Whatever degree of accuracy is necessary is not only fine with me, but is exactly what I would recommend. No more, no less.
Jeffry J. Brickley wrote:
I, for one, would not want to pilot a UAV at low-altitude through a canyon using your ideas on math.
I'm not so sure, because I think, in the end, we'd do it essentially the same way. Too far to the left, go right; too far to the right, go left. With a bit of hysteresis, of course. I know I wouldn't, and I don't think you would try to "calculate" the required path in its entirety; that sort of thing just doesn't work in real life - even with extreme precision. The place, I think, where we would differ is that I would ultimately choose to work with integers or fixed-point numbers representing a sufficiently small unit of measure on one or more trivial, dedicated (but networked) stack machines, while you would prefer (I think) to work with floating point numbers on a multi-tasking, multi-core, parallel processing CISC computer. But that's a difference in technique, not essence, because my "collection" of stack machines, taken as a whole, is a multi-tasking, multi-core parallel processing system; it's just more loosely coupled and is based on a simpler architecture and a smaller instruction set.
The Grand Negus wrote:
The place, I think, where we would differ is that I would ultimately choose to work with integers or fixed-point numbers representing a sufficiently small unit of measure on one or more trivial
which is EXACTLY where you loose accuracy. You are so hot on the idea that you can simply achieve "accuracy" by using an integer to represent an accurate measurement by saying the unit is a centimeter. BUT you forget the errors in multiplication and division when you have round-off errors. The result can be loss of meters in resolution due to multiplication round off, even when you return the final result to centemeter, and down goes the craft. Integers cannot replace floating point numbers, no matter what you "call" the accuracy, you cannot have it. floating point numbers are more accurate because of preservation of the round-off bits.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)