Respectfully,
You need to start with a spreadsheet that translate requirements, priorities, 1st choice sensor, 2nd choice sensor, Voltage, current,calculated Watts/power, comm protocol, etc.
Power dissipation is important for sensors in the environment as the heat must be neutralized.
Protocol may be anything from DC to SPI to I2C to Rs232 to serial TTL, etc.
Two schools of thought:
- every sensor buffered and protocol translated before assimilation
- connection to main uC/MPU and translated internally
Consider that sensors drive input to the PID algorithm, my preference is that every sensor be independent and addressable. Selecting this approach leads to a black-box traditional design effort, allows building "working spares" and simplifies troubleshooting.
Most Arduinos are 8-bit machines and while they may easily handle a few sensors, they have internal limitations in SRAM; for example, UNO only has 2K total RAM. Most utilize software floating point, the ARM based DUE being the exception.
The most minimum Arduino is the single uC, a $2 Atmel328P. Running at 8MHz on internal oscillator, it can easily handle any single sensor... Serial, I2C, SPI.... Yes, it could handle many sensors, but Arduino supports no threading model w/o using a RTOS and if one wished to use an Arduino as a "hub device" then I would design around an RTOS.
For aggregating the sensors, I would move away from Arduino an suggest a RaspberryPi or other computer on a board. An Arduino Due is hardware capable but an RPi is better supported and runs Linux which will make interfacing to the Apple OSX easier. RPi can easily thread so running the PID algorithms is a natural. Ideally, using a MacBook would even be better! But, RPi is inexpensive and less likely to grow legs and run away.
Good luck, sounds like a fun project. Get the spreadsheet started.
Ray