Last month I had the idea to create a "physics.h" which is a (sub)set of different physics formulas one can use. Recall what "math.h" is for math formulas.

The rationale was that while I was making a library for the DHT (temp/humidity) sensor I thought the dewPoint() formula should not be part of the sensor library as it is useful for any temp/humid sensor combination.

So physics.h doesn't do sensors, actuators or I/O, just formulas. For now I have a simple first version with a few temperature related macro's and functions.

The architecture / structure I have in mind has 2 levels, at top is "physics.h" which just includes the more specific areas => To have multiple files one can tweak physics.h to include/exclude subsets very easily. Drawback is that some formulas will fit in multiple subsections.....

The following questions: (high level)1) What do you think of this idea? why?2) What do you think of the architecture? other ideas? why?3) other remarks? why?

(low level)4) what subsections should exist? (mechanics, electro, radiation, ...?5) which formulas in which subsection?6) sources for good formulas?

About subsets... well, you could do a mechanical one with calculation of speed based on two positions, torque limiting (if there's current feedback) and even directions if you feed two encoder signals to the object, also you could make it with the possibility of a gear. So you could, for example, feed encoder counts and based on the configuration of the encoder signal and gear, get the speed, torque, etc... on the other side of the gear. This would be quite generic and could be used both in a robot, or for example a winch. (of course that, for the direction, you'd need to configure your system as a two motor on a fixed axis.

Density, based on two pressures.

Torque based on current?

Power measurements coming from current and voltage measurement...

There's plenty of ideas. Some simpler to be made others not so simple because of all the hardware involved. :\

Edit:

Position based on speed and angle, in the extreme case of having two encoders...

You could also add a formula to convert resistance to temperature for a thermistor. It's a bit intimidating to some newbies. Formula is here for simple thermistor curves. I'm sure some more accurate thermistors has more than three constants, R1, T1, and B.

I think the idea has merit, but I am not too keen on the name; perhaps it should be named "algorithms.h" or something similar...? When I think "physics", I think about things like motion and such, but not temperature and humidity - though I suppose there's a lot of overlap.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

I think the idea has merit, but I am not too keen on the name; perhaps it should be named "algorithms.h" or something similar...? When I think "physics", I think about things like motion and such, but not temperature and humidity - though I suppose there's a lot of overlap.

I think temperature/humidity was the beginning of the idea. It could be easy to add more subsets for different things. Although, for simpleness, I think it should concentrate on things that can be measured by "standard" sensors to make facilitate it's use. :\