Date: Fri, 12 Jun 1998 05:38:33 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: jb@cimlogic.com.au, mike@smith.net.au, current@FreeBSD.ORG Subject: Re: floating point usage within the kernel - howto ? Message-ID: <199806120938.FAA28604@hda.hda.com> In-Reply-To: <199806110745.JAA22102@labinfo.iet.unipi.it> from Luigi Rizzo at "Jun 11, 98 09:45:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > Luigi Rizzo wrote: > > > they want to run a P-I-D controller (and more generic controllers > > > if this goes well) to control a few motors, for didactical purposes. > > > > What update rate do they need that requires the code to run in the kernel? > > whenever i ask this question the answer is invariably "as fast as > possible". You have to get a better answer from them than that - they must know the bandwidth of the controllers and the number of control laws. The analog signal conditioning should match the design bandwidth. Alsi, in addition to the implementation of the control laws, the loading on the system has to be such that it can continue to run. The "as fast as possible" answer may mean the more horsepower the more complicated controllers they'll attempt, but it can mean ignoring the digitization aspects of the digital controller and not doing the analog filtering properly, not worrying about amplifying noise in the digital derivative in the D term, etc. > In any case, we don't have a real target application, it is just > a framework that must be adapted to different apps, so i would > expect a max rate of 1 KHz to cover all practical purposes, with > 100Hz being sufficient in many cases. I've done this in the 386BSD days by treating the PID controller like an embedded system not using any OS services, speeding up the clock tick by a factor of N, and calling the controller on each tick and the system every N ticks. You communicate between this controller and a kernel device driver through a mail box or queue scheme. I did it with fixed point controllers and avoided the floating point issue. In addition to implementing two control laws it was microstepping a digital throttle through the printer port, and you could telnet to it. This might look like a klooj compared to speeding up HZ, but it has its advantages. The controller is ready to move to an embedded system or board. You have a single point where you can save/restore floating point without worrying about other kernel facilities using floating point. The code that has to be validated for safety and that you must be sure is running properly is outside of the kernel, and you could potentially map and unmap it to avoid being stepped on, etc. > (and, last not least, robotics people tend to have a > lot of money just because their hardware costs so much :) Purchase orders for a contract cheerfully accepted at the e-mail address below. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806120938.FAA28604>