Robotic platform that I am playing with.

Here I will list some robotic platforms that I have played with.

1. UAV (unmanned aerial vehicle)
a) Penelope equipped with Intel Atom board, stereo vision system, GPS, and INS. Work with Michael Warren.

b) Robin system (worked with Michael Warren and Michael Sheil)

c) Phoenix  equipped with autopilot control board.

d) Quadcopter developed by Inkyu Sa.

header file with suffix like ".h",".hpp", ".inl"

http://stackoverflow.com/questions/1208028/significance-of-a-inl-file-in-c

.inl files are never mandatory and have no special significance to the compiler. It's just a way of structuring your code that provides a hint to the humans that might read it.

I use .inl files in two cases:

• For definitions of inline functions.
• For definitions of function templates.

In both cases, I put the declarations of the functions in a header file, which is included by other files, then I #include the .inl file at the bottom of the header file.

I like it because it separates the interface from the implementation and makes the header file a little easier to read. If you care about the implementation details, you can open the .inl file and read it. If you don't, you don't have to.

The compiler doesn't care about the extension of the file you're including, so things like ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc", etc. are a simple convention, to make it clear what the files is supposed to contain.

The best example is the STL header files which have no extension whatsoever.

Usually, ".inl" files do contain inline code (hence the ".inl" extension).

Those files ".inl" files are a necessity when you have a dependency cycle between header code.

For example:

// A.hpp
struct A{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(B & b)
    {
       b.doSomethingElse() ;
    }
} ;

And:

// B.hpp
struct B{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(A & a)
    {
       a.doSomethingElse() ;
    }
} ;

There's no way you'll have it compile, including using forward declaration.

The solution is then to break down definition and implementation into two kind of header files:

• hpp for header declaration/definition
• inl for header implementation

Which breaks down into the following example:

// A.hpp
struct B ;
struct A{
    void doSomethingElse() ;
    void doSomething(B & b) ;
} ;

And:

// A.inl
#include <A.hpp>
#include <B.hpp>
inline void A::doSomethingElse()
{
   // Etc.
}
inline void A::doSomething(B & b)
{
   b.doSomethingElse() ;
}

And:

// B.hpp
struct A ;
struct B{
    void doSomethingElse() ;
    void doSomething(A & a) ;
} ;

And:

// B.INL
#include <B.hpp>
#include <A.hpp>
inline void B::doSomethingElse()
{
   // Etc.
}
inline void B::doSomething(A & a)
{
   a.doSomethingElse() ;
}

This way, you can include whatever ".inl" file you need in your own source, and it will work.

Again, the suffix names of included files are not really important, only their uses.