Re: Ada, the best language with the not-so-best tool chain

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2012-10-10, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> 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