From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3025dd6d917b499c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.84.234 with SMTP id c10mr3124853wiz.4.1350352657439; Mon, 15 Oct 2012 18:57:37 -0700 (PDT) MIME-Version: 1.0 Path: q11ni134324884wiw.1!nntp.google.com!feeder2.cambriumusenet.nl!feeder1.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.11.MISMATCH!feed.xsnews.nl!border-1.ams.xsnews.nl!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Ada, the best language with the not-so-best tool chain Date: Wed, 10 Oct 2012 13:13:40 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <38af7fb8-b0a4-4a31-87aa-b7b698cc89c3@googlegroups.com> <3ca0ffd0-1764-484b-8fab-17c0d2dd9463@googlegroups.com> <1f645050-cf4c-40bf-a797-9687b69e4a54@googlegroups.com> <18ats2960nsvm$.kfufsnul13aq$.dlg@40tude.net> <5072c9ae$0$6562$9b4e6d93@newsspool4.arcor-online.net> <4keoa6epdxt7.1nnwxy7v7ar90.dlg@40tude.net> <5072dc68$0$6554$9b4e6d93@newsspool4.arcor-online.net> <1f7cmfp1l65w1.1deog8cfxbs0u$.dlg@40tude.net> <5072e37a$0$6556$9b4e6d93@newsspool4.arcor-online.net> <1kg5574txbj9s.tjfsf4bdpyge$.dlg@40tude.net> Injection-Date: Wed, 10 Oct 2012 13:13:40 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="e298f3c034f630fa7d024371528fc2e1"; logging-data="28653"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IzVd55g3tYHWjZeQ3Ig+3zYOsv6pasEk=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:g485gP68ljuBM2GcR7/I/a6CmZc= Date: 2012-10-10T13:13:40+00:00 List-Id: On 2012-10-10, Dmitry A. Kazakov wrote: > On Tue, 9 Oct 2012 23:23:11 +0000 (UTC), Simon Clubley wrote: > >> Let's make this discussion more tangible by using a specific example. >> >> The scenario: a hobbyist/academic researcher/whoever is building a >> small computer controlled model aircraft, in the order of up to about >> a metre in length for the fuselage. > > I have no idea about controlling an aircraft. Can one do it without a > multitude of analogue inputs and outputs, rotary encoders etc? > [Remember we are talking about model aircraft here, not large human carrying multi-million dollar/euro/pound aircraft.] The interface problem is actually two sub-problems: (1) gathering sensor data and (2) commanding the aircraft to move as a result of processing the sensor data. The input sensors are generally (but not always) digital these days. For example, the low cost gyros and accelerometers you would typically use usually have a SPI or I2C interface. Commanding a model aircraft to move is done in exactly one way: by sending command pulses to a standard R/C aircraft servo. The following explains how these servos work: http://en.wikipedia.org/wiki/Servo_%28radio_control%29 The length of the pulse determines the position of the servo. Electronic speed controllers (the controller used to regulate power to the electric motor driving the propeller) work in the same way; pulses are sent along a command line. These pulses are digital in nature; driven to logic 1 for a period of time and then driven to logic 0 to end the pulse. They are ideally suited to be connected to a GPIO line in output mode. >> Question 1: if you could not use GPIO lines to control commodity >> R/C components, how would you have the onboard computer control the >> engine and flight control surfaces ? > > ARM boards look very much like a compromise. That rarely pays off. Likely > there exist better solutions for a model aircraft, but I cannot judge that. > I would welcome suggestions as I cannot currently think of any viable alternatives to a small and low power general purpose onboard computer. >> To make this on topic for this newsgroup, this seems to be a common >> hobbyist or researcher project in a number of circles, and is _exactly_ >> the type of project for which Ada would be very well suited indeed. > > How many people spend their time building model aircrafts? Could rail > transport modeling be a better candidate? > When you look around, it seems a surprising amount of people do (or at least they consider it). Compared to making a aircraft fly through the air, rail transport modeling seems kind of boring in comparison. :-) > Anyway, if you need an altimeter instrument for the ground control system, > let me know. I maintain an instrumentation library in Ada. > >> Question 2: how would you put the idea of using Ada for this project >> into someone's head and what changes to the Ada ecosystem would be >> needed to make it viable for people with different ranges of embedded >> experience to actually use Ada in this case ? > > I would tell him that he could use the same software during modeling and > deployment phases, basically, doing much of the work in doors rather than > in field. > The answer would need to be more specific than that; there already exist testing environments which allow you to do some work on your control systems indoors. For example, have a look at Flightgear: http://www.flightgear.org/ Quite a few people use it for developing parts of their system within a simulated environment. A person would generally need to be using arguments along the lines of suggesting that Ada based development would result in more robust and/or quicker to develop code. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world