Control library for Nuttx

[raiden00pl]

Hi,
I'm working on a BLDC/PMSM motor driver based on Nuttx and I would like to put it on Nuttx upstream soon.
At this point it is designed to work with STM32F334 (Nucleo board) and X-NUCLEO-IHM08M1 board, but most of the control logic is universal and can be easy ported to other hardware (PID controllers, space vector modulation, FOC current regulator, etc).

So here is my question: is there any place in Nuttx source where I can put control logic code which is reusable?
Gregory, what do you think about creating something like 'control' directory in libc and include/control.h?

Regards

[patacongo]

It depends upon what the user interface is.  Does an application interface with this?  If so, then it must follow standard POSIX interface rules.  it must be a device driver and, hence, should reside with all other device drivers, perhaps at drivers/control?

If it is a application interface that does not conform to a standard, POSIX device interface then it cannot be permitted in the repository at all.

Or is it an internal OS library.  In the sense that, say, wireless is.  In that case it would only be used by board level code and by other device drivers and a location like control/ does make sense.

Greg

[raiden00pl]

OK, thanks for the answer.
I think the third option is the most suitable one.
The control logic is highly dependent on the board hardware and most control algorithms will work based on high-priority interrupts which, I understand should be implemented as board level code.

[patacongo]

The control logic is highly dependent on the board hardware and most control algorithms will work based on high-priority interrupts which, I understand should be implemented as board level code.

Only ARMv7-M supports high priority interrupts.  If it depends on the nature of the interrupts or any other specific board interfaces, then it cannot be used in any general way.

[raiden00pl]

No, it is fully independent of architecture/board set of math operations nicely packed in functions and structures. At this moment it works with floats, but I plan to add fixed-point math support sometime.

[lee chen]

Greg,

I used to build some application specific (not architecture specific) libraries for some projects using Nuttx. (Unfortunately I was not allowed to make it open source.) I created a folder "apps/extralibs" for them so the apps can link to them. If the control algorithms can be built as a library, maybe we can permanently create a similar folder like "apps/extralibs" in the upstram for things like that? I believe it is a nice addition to the Nuttx.

Thanks.

-Lee

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avg.com

[Alan Carvalho de Assis]

Hi Mateusz,

Do you think it is possible to move these math functions to apps/ like
a library?

Greg, what to you think about the idea of creating a directory to
include libraries and applications to use for control and automation?
Like apps/automation/ ?

This kind of features are important to use NuttX for Industrial applications.

BR,

Alan

[patacongo]

Do you think it is possible to move these math functions to apps/ like
a library?

My understanding is that this is an OS component, not an application library.

Perhaps that needs to be clarified.

[Alan Carvalho de Assis]

Hi Greg,

Yes, you are right! He developed it as an OS component:

https://bitbucket.org/raiden00/nuttx/src/motor_driver/

BR,

Alan

[raiden00pl]

I think that control functions can be useful in both OS and application code. Something like let's say <math.h>.

In my case (power electronics stuff) I use them in board-level code during lower-half driver implementation.
We can control motor from application code through upper-half driver which define common motor operation (for example START, STOP, set parameters) but all control magic happens in lower-half driver.

[patacongo]

Code that is shared by applications cannot go in nuttx/control or in apps/extlib.  It would have to go in nuttx/lib/control.

There a few awkward rules about make code that is usable both by the OS in all configurations and by applications.  I can help with that.

Greg

[raiden00pl]

Hello again,
I separated most of the reusable functionality from my PMSM motor driver and put it to the libc directory.
For now I decided to change name from "control library" to "dsp library".

You can find it here:
   1. https://bitbucket.org/raiden00/nuttx/src/motor_driver/include/dsp.h
   2. https://bitbucket.org/raiden00/nuttx/src/motor_driver/libc/dsp/

What do you think about it ?

[patacongo]

For now I decided to change name from "control library" to "dsp library".

There are many, many different kinds of DSPs.  This is still focused primariy on control.  Does it really make sense to think of this as a generic DSP library?  It isn't.  The naming seems a little broad for your more focused interest.

You can find it here:
   1. https://bitbucket.org/raiden00/nuttx/src/motor_driver/include/dsp.h
   2. https://bitbucket.org/raiden00/nuttx/src/motor_driver/libc/dsp/

I am wondering about it being a part of libc. There are already some pretty crazy things in 'libc' but the content of libc is really governed by standards (OpenGroup.org).  I wonder if it might not be better to put it in its own library, libdsp or whatever we end up calling it.

Things go into libraries if they are shared by both applications and by OS internals.  When we talked before, my understanding was that this was an OS internal "library" in which case it should not go in libc but in nuttx/dsp (or nuttx/control as we talked about before).  Does it use only standard application interfaces?  Is it can be a library.  If is uses internal OS interfaces, it cannot be.

I have not reviewed the code but I would have to reject (at least in that location) if is uses any internal OS interfaces!

What do you think about it ?

I skimmed through the code.  I would have to spend a lot more time to have any technical understand.  The coding style looks good.  Thanks for that.  If I were to review the code more closely I would have to bring the code onto a branch upstream.

What do you think about that?  Can I bring it onto a branch?  Are to ready to do the last steps to prepare to merge to master.  Are you ready for detailed review?  So so, it will need to be on an upstream branch.

Greg

[patacongo]

 

....  When we talked before, my understanding was that this was an OS internal "library" in which case it should not go in libc but in nuttx/dsp (or nuttx/control as we talked about before). ...

 I think that a DSP support library is too specif to be at the level of nuttx/dsp.  If it is not in libc or libdsp, it probably should be in driver/dsp.  There are other OS internal libraries under drivers/ as well (mostly mixed in with functionally related things).

[raiden00pl]

This is still focused primariy on control.  Does it really make sense to think of this as a generic DSP library?

I agree that name 'DSP library" is broad and I will not insist on it. I wanted to create a place where in the future some other DSP stuff can go.

 I think that a DSP support library is too specif to be at the level of nuttx/dsp.  If it is not in libc or libdsp, it probably should be in driver/dsp.  There are other OS internal libraries under drivers/ as well (mostly mixed in with functionally related things).

 
It doesn't use any internal OS interface, only math. The idea was that it could be used in both application code and OS code. In this case, as I understand it should be in nuttx/libdsp.

What do you think about that?  Can I bring it onto a branch?  Are to ready to do the last steps to prepare to merge to master.  Are you ready for detailed review? 

I just need to add/update some comments, move it to the correct location (nuttx/libdsp?) and I will prepare pull-request.

[patacongo]

This is still focused primariy on control.  Does it really make sense to think of this as a generic DSP library?

I agree that name 'DSP library" is broad and I will not insist on it. I wanted to create a place where in the future some other DSP stuff can go.

We can always change the name in the future.  Most of my DSP, for example, has been with video so it seems an odd name to me because I automatically equate DSP with video.  It will mean something different to others as well.

 I think that a DSP support library is too specif to be at the level of nuttx/dsp.  If it is not in libc or libdsp, it probably should be in driver/dsp.  There are other OS internal libraries under drivers/ as well (mostly mixed in with functionally related things).

 
It doesn't use any internal OS interface, only math. The idea was that it could be used in both application code and OS code. In this case, as I understand it should be in nuttx/libdsp.

Then that is an appropriate place for it.

What do you think about that?  Can I bring it onto a branch?  Are to ready to do the last steps to prepare to merge to master.  Are you ready for detailed review? 

I just need to add/update some comments, move it to the correct location (nuttx/libdsp?) and I will prepare pull-request.

The build system for FLAT, PROTECTED, and KERNEL builds are different and complex.  That may be more than you want or care about doing.  That is where I could help you (notice that the libraries all have bin/, ubin/ and kbin/ directories.).

Greg

[lor...@px4.io]

I would advise against integrating use-case specific libraries with the OS. It violates the basic principle of separation of concerns and likely leads to not very well maintained code because the library will only be used by a fraction of the users of the OS and many parties will bring their own math code (or use a standard general-purpose library).

For anyone needing a math library: The PX4 math library is 100% unit tested, BSD licensed, optimized for high performance and actively maintained by a large community. I still think that its too application specific to be contributed to an operating system.

https://github.com/px4/matrix

Others might want to use the very popular Eigen math library with NuttX (we've done it in the past).

[Alan Carvalho de Assis]

Hi Lorenz,

Currently NuttX is used for many applications like robotics and motor control. Then we need a good library integrated on it.

An advantage of the NuttX over other RTOSes is because it has many features integrated, you don't need to speed time integrating and debugging it.

I agree that it could mean more code to maintain, but it is important to bring more users and developers to NuttX.

BR,

Alan

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

[Fabio Balzano]

Hello,

I agree with Lorenz on the separation of concerns. I follow this mailing list since few months, I read all the emails and sometime I am surprised about the level of knowledge of some here. Gregory and few more here always demonstrate good architecture decisions, when I read them I always remember the professors and the books I got at the university time. This mailing list is a real pleasure to read but this time I agree with Lorenz ( I do read their mailing list as well..). Such library would need a big community behind because all the required tests and heads thinking and testing. I believe we are not yet at that point with the Nuttx community despite the high knowledgeable and skilled members. I also believe that Nuttx should not provide application level tools because its purpose is to solve the OS implementation. I hope it makes sense. Thank you all for this great project.

Fabio

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Alan Carvalho de Assis]

Hi Fabio,

Mateusz is working on this library for a long time (more than one
year), then it is hopefully mature enough to be integrated on NuttX.
But doesn't mean that we will not find BUGs on it.

Also the fact of the NuttX having an integrated motor/dsp control
library will not prevent people from using their our custom/tailored
library.

Just my two cents!

BR,

Alan

[patacongo]

I think I agree with all points in this discussion and, hence, don't have such a strong opinion.

I think the root cause of the problems is that currently, shareable "library" code is contained with the OS repository.  That tradition is because (1) once the code base was tiny and it made just sense, and (2) libc is so tightly coupled with the OS.

On one hand, I agree that application specific code should not be part of the OS.  But on the other hand, I would like people to contribute share-able libraries that can be re-used ... some of which do require access both both from the OS and from applications and some of which will be application specific.

Currently such share-able libraries are part of the OS repository, identified only because they begin with the prefix lib.  They are conflated! I would like to see all such libraries moved into a separate repository, perhaps 'libs' and there I would, indeed, like to see application specific libraries.

When I look at the OS, I don't think of any of the directories beginning with lib as truly a part of the OS.  They are there only for convenience; they have nowhere else to be.  I think that some could be moved to apps/. because they are never used within the OS (libnx, libc/wqueue, etc.)  I am not sure if I am ready to move them out yet (perhaps next release, 7.25 which will happen next week).

[patacongo]

When I look at the OS, I don't think of any of the directories beginning with lib as truly a part of the OS.  They are there only for convenience; they have nowhere else to be.  I think that some could be moved to apps/. because they are never used within the OS (libnx, libc/wqueue, etc.)  I am not sure if I am ready to move them out yet (perhaps next release, 7.25 which will happen next week).

Currently there are top-level libc. libnx, and libxx.  We are talking about adding a libdsp.  That is a lot of clutter at the top level.  One stop gap option might be to moved them all under a common directory libs/ like:

  libs

   |-libc

   |-libnx

   |-libxx

   `-libdsp

At least these would not be so in-your-face.

Look at the Linux souce tree for a comparison of how a mature OS is organized: https://elixir.bootlin.com/linux/latest/source

There are no application-specific directories anywhere.  It is pure GPOS.  There is a libs/ directory but it does not hold application specific code.

I think in Linux-land, you would accomplish this use Linux kernel modules.  NuttX also supports kernel modules, but this is probably not a general embedded solution due to the higher memory usage.  So I think the NuttX will need an original solution in the long run.

Greg

[raiden00pl]

I've not seen any external library that provides power electronics control functions (or generally speaking control functions). Matrix from PX4 and Eigen provide different functionality.

I'm not an expert in control-stuff but if the initial part of the work is done, it may encourage more people to contribute.
If the library is available in an easy way and provides with some usage examples, maybe someone will choose Nuttx for their application.
Of course there may be bugs in the code and this is normal. But like ESR put it: "given enough eyeballs, all bugs are shallow" ;)

Moving share-able libraries to a separate repository (or /libs directory for now) sounds good for me.

[patacongo]

Moving share-able libraries to a separate repository (or /libs directory for now) sounds good for me.

A separate repository would architecturally be the cleanest.  However, it is also very convenient to have the OS libraries coupled with the OS since they are required to work together.

So, at least for the time being, I have moved all of the libraries to a new libs/ directory.  I like the way this cleans up the top-level directories.  And I also think that application specific logic gets less concerning the deeper you go into the directory tree.  So lets leave things in libs/ for awhile.

You will have to make some adjustments to your libdsp code.  You need to move it to libs/libdsp.  This should effect only the paths in in the make system (and at the top of each file).  Each  reference to libsp as a path needs to change to libs/libdsp.  Pretty easy.

Currently libcxx is broken for this reason too.  It needs to have all occurrences of libxx changed to libs/libxx.  Alan says he can work on that this weekend.  But, if it is like uClibc++, the change was trivial:  libxx->libs/libxx and nothing more.  If you are using libcxx and can't wait until this weekend, please make that change and post the verified patch here.

Thanks,

Greg