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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.230.168 with SMTP id sz8mr12961244obc.9.1392056316813; Mon, 10 Feb 2014 10:18:36 -0800 (PST) X-Received: by 10.140.95.144 with SMTP id i16mr655892qge.1.1392056316769; Mon, 10 Feb 2014 10:18:36 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!c10no15842151igq.0!news-out.google.com!y18ni7488qap.1!nntp.google.com!f11no16167652qae.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 10 Feb 2014 10:18:36 -0800 (PST) In-Reply-To: <854n4a1004.fsf@stephe-leake.org> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=189.77.226.1; posting-account=TRgI1QoAAABSsYi-ox3Pi6N-JEKKU0cu NNTP-Posting-Host: 189.77.226.1 References: <5e8fad3a-94e6-4517-af54-db8b4146803e@googlegroups.com> <858uto3cj3.fsf@stephe-leake.org> <85d2iz1g48.fsf@stephe-leake.org> <854n4a1004.fsf@stephe-leake.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Raspberry Pi, Real-Time and Ada From: "Rego, P." Injection-Date: Mon, 10 Feb 2014 18:18:36 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3907 X-Received-Body-CRC: 610271774 Xref: news.eternal-september.org comp.lang.ada:18476 Date: 2014-02-10T10:18:36-08:00 List-Id: On Saturday, February 8, 2014 5:28:43 AM UTC-3, Stephen Leake wrote: > I don't understand; the timing for "soft RT" is stricter than the timing > for "hard RT". What do "soft" and "hard" mean here? > Hmm. Perhaps they just mean "hardware" and "software"; I don't see why > that's a useful distinction. Well... I meant soft real-time and hard real-time; but that's all pure acad= emic. > But you are optimizing prematurely again; these are times for small > parts of the overall control cycle. You need to start from the top. I did not understand. > How fast does the overal control cycle need to run? Once every second? > 1000 times a second? I think this would give a good response; but for the entire control cycle. > For spacecraft, this is based on a stability and pointing accuracy > analysis; if the control cycle were slower, the spacecraft would not be > stable, or would not point accurately enough. 10 Hz is usually adequate.= =20 > What does the control cycle in a drone do? I suspect the plane is > basically stable by the design of the wings and tail, and the control > system is just running the steering. > Based on what analysis? Actually it depends highly on your design. My perception is that as smaller= is the drone, faster you should be able to control it. For example, wonder= a quadcopter 10m high, falling down, maybe because you (controller) lost c= ommunication. An autonomous recover-to-ground algorithm should in 1s: 1) id= entify communication is lost; 2) assume override; 3) read sensors (as alway= s); 4) calculate the best landing; 4) command devices and land. Using a com= plete model you would need to solve some conditions for a 12-dimensions mod= el. With 10Hz I would have only 100 iterations in 1s. And all this should h= appen before the human sense realizes (so 1s is quite fast for us). > If the drone is teleoperated, the requirement is the human sensing time; > you push the joystick, you want the plane to respond "quickly". Which > gives control cycle times of 0.1 seconds =3D 10 Hz. Although 1 second > would be tolerable. > If the drone is autonomous, that analysis does not apply. If the drone's > mission is to take pictures of targets, you can derive timing requirement= s > from the speed of the drone in flight and the speed of the camera. That > also gives location and pointing accuracy requirements; do you have GPS > on the drone? How does it know where the camera is pointed? No camera for now. But it should be able to have one. Regards.