Should we provide a Math.h?

[cmaglie]

I think that EulerAngles, Quaternion and any other math structure should be moved into a specific Math.h file.

I imagine that maintaining a Math.h file may quickly become a project on his own if we try to support all the possible mathematical constructs... maybe we should consider adopting an already existing library? Or extract a subset of an existing library?

[PaulStoffregen]

These probably want to become C++ classes rather than C structs if math operations are to be supported. Then we can use C++ operators to make the syntax very intuitive. That could become quite a project, but it could grow slowly as needed (or as people contribute). At the very least, we could start with assignment operators to convert Quaternion to EulerAngles and vise versa. Things really start to get interesting when/if there's a class for representing a 3D vector....

I really don't have much opinion about whether to put these into same file or a different file. If these are brought in by Arduino.h, then it hardly seems to matter.

But if another file is used, clashes with C library header file names should be avoided. I'd definitely recommend against "Math.h" because it will conflict on Windows and Mac with "math.h" where filenames are case insensitive.

[damellis]

This feels like a lot of stuff to add to the core (as Paul points out, it's probably about the same whether they are directly in Arduino.h or in another header file it includes). What are they for?

[PaulStoffregen]

Gyroscope, Accelerometer, & Magnetometer are similar to the networking Client, Server, & UDP classes. They're meant to allow motion sensors libraries to provide their capabilities in a uniform format, much like how the networking base classes allow programs to work with the Ethernet shield or Wifi shield or other networking hardware which inherits from those base classes.

Sometimes motion is fed to a filter algorithm. EulerAngles & Quaternion are data types meant to represent the output of those filters.

[PaulStoffregen]

Here's a sketch for Arduino101's motion sensors and the Madgwick filter, using the existing APIs.

https://github.com/arduino-libraries/MadgwickAHRS/blob/master/examples/Visualize101/Visualize101.ino

[damellis]

Thanks! I realize I commented without really have much background; sorry about that.

So the idea is to provide common data types in the core, allowing different libraries (providing different filters, etc.) to interoperate? That makes sense. The math-intensive calculations / filters themselves wouldn't be in the core, would they?

[PaulStoffregen]

My understanding is Madgwick, Mahony, FreeIMU and others will remain separate libraries.

If EulerAngles & Quaternion become C++ classes with assignment operators, or if they remain C structs but conversion functions are provided, commonly used code which converts between these formats would probably become part of the core. Maybe?

[mbanzi]

I think it might be useful to have them as C++ classes as opposed to just structs.

On 26 Mar 2016, at 07:13, Paul Stoffregen notifications@github.com wrote:

My understanding is Madgwick, Mahony, FreeIMU and others will remain separate libraries.

If EulerAngles & Quaternion become C++ classes with assignment operators, or if they remain C structs but conversion functions are provided, commonly used code which converts between these formats would probably become part of the core. Maybe?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/arduino/ArduinoCore-API/issues/2#issuecomment-201764880

[PaulStoffregen]

Can I have permission to copy the last part of MotionSense.h into the public Madgwick library?

This is the portion I'd like to put into MadgwickAHRS.h:

#ifndef ARDUINO_MOTION_SENSE_H
// EulerAngles represents a rotation in the most commonly accepted
// NED (North, East, Down) right hand rule, with:
//   yaw   from    0 to 360 degrees
//   pitch from  -90 to  90 degrees
//   roll  from -180 to 180 degrees
struct EulerAngles {
  float yaw;
  float pitch;
  float roll;
};

struct Quaternion {
  union {
    float q[4];
    struct {
      float w;
      float x;
      float y;
      float z;
    };
  };
};
#endif

Doing this now will allow adding functions that return these data types, and let me fix the open issue requesting quaternion output.

[PaulStoffregen]

Oh, opps, if they're going to become C++ classes, maybe we really need to at least get the basics defined before any APIs are published.