Beginning of an Automatic Climate Control System, all juiced up on Fusion - Page 5

drk · 04-22-2008, 01:03 PM

Quote: Originally Posted by h3rk

Yep, I'm working on this. But there has been a delay based on Fusion software development. The delay is also related to Analog output availability. If push comes to shove, I will try something else, but I hope analog output is coming down the pike. I want servo too, but I want analog out first.

Oh and my vehicle changed (completely different HVAC setup), so I had to come up with another shell (physical connections, and software methods to make the core of my control scheme perform the same functions IRL).

I should also be getting some really good HVAC info from a recognized OEM expert in the field. I'm even planning to go to one of his seminars later this year (Unfortunately I couldn't make the one that is going on this very moment).

But for right now, I'm beta testing the new MDX software, working with the developer so that it works well enough that I won't need to have my own software written at this point. FusionControlCenter software should be generic and powerful enough once completed and polish to handle this. There are a few functions I hope can be added down the line, like the ability to save variables that were calculated during runtime.

That's great to hear you are in touch with an OEM technical expert!

The thermodynamics itself isn't all that bad, but the lack of fan curves, heat transfer, and sunload functions makes this process very difficult. If he can give you some insight into how the OEMs do the calculations, it could greatly simplify your work. If you had a general idea of how they do things from the factory, the initial calibration might not be needed. Simply use the general approximation of the constants based off vehicle type (I'm sure the OEM's have general numbers in mind when they start the process too) and then fine-tune them by checking to see if the the temperature reached in a set period of time is lower or higher than what is predicted by energy balance.

You could even make it dynamic, fine-tuning the constants for a time interval based off the energy balance performance of the last interval. This would make the accuracy of the constants themselves nearly irrelevant. As you know, with multiple constants you are trying to solve for, there will be multiple sets of constants that will give the same solution, at least in the short term. By changing them dynamically, calculating the actual constants for the vehicle won't matter, because you have a solution, a set of constants, that will work for at least the next 5 minutes.

It's similar to how Solver in Excel works. Often, when using Solver in conjunction with least-squares regression to match complicated model functions to data, the constants you get are not physically possible (in the case of using Excel to model phsyical reality). Even with that in mind, the resulting solution does match the data over the range given. Eventually, the model will no longer match the data, but in the short term, it will match it very well, without actually knowing the constants.

Depending on what the mathematical equations of each function are (exponential, power-law, hyperbolic, etc... ), all you need is a model using that sort of function (or even the whole series of functions for all the thermodynamics inputs and outputs) and the energy balance data from the past 5 or 10 minutes. Then use Solver-methodology (I forget the numerical method used, I'll look it up in my numerical method book tonight, though it'll be much later) to tweak the constants so that the model match very closely to the constants in the past interval and apply those constants to the next interval.

Now that I think about it, an even shorter interval might be useful, to take into account varying sunloads, doors opening/closing, windows being down, stop and go traffic, and the adding/subtracting additional passengers. Possibly 1 minute intervals?

I'm a Petroleum Engineering student, and while we are often warned about not allowing constants to range outside their phsyical boundaries when using regression with Solver in Excel, that is because we are attempting to extrapolate trends 30 or more years past the end of the data for our reserve calculations, so the model must be technically sound, sometimes at the expense of model-data correlation. In the context of an automatic HVAC system, there is no need to extrapolate very far in the future, because you can simply take another measurement and do some quick calculations.

I've been reading all your threads on the topic, and I think you've been doing great work!

Quote: Originally Posted by greenman100

The biggest issue is interfacing our board with your truck.

It's like writing a book in english, and trying to get the rest of the world to read it.... you need a translator, and pretty much every car speaks a different language.

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

Thanks for all the hard work guys, you've been an inspiration!

greenman100 · 04-22-2008, 01:09 PM

Quote: Originally Posted by drk

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

The plan for analog outputs is the following:

A 64-step digital pot, connected to a variable low LDO regulator rated at 5 amps. It would take up 3 digital outputs and 1 analog input for feedback.

the next stage would be PWM capable of 30 amps or better

also, check that car - my car uses a resistorpack for the blower motor, but the vent doors are all cable-actuated, so I'd have to retrofit servos.

h3rk · 04-22-2008, 01:16 PM

Quote: Originally Posted by drk

That's great to hear you are in touch with an OEM technical expert!

The thermodynamics itself isn't all that bad, but the lack of fan curves, heat transfer, and sunload functions makes this process very difficult. If he can give you some insight into how the OEMs do the calculations, it could greatly simplify your work. If you had a general idea of how they do things from the factory, the initial calibration might not be needed. Simply use the general approximation of the constants based off vehicle type (I'm sure the OEM's have general numbers in mind when they start the process too) and then fine-tune them by checking to see if the the temperature reached in a set period of time is lower or higher than what is predicted by energy balance.

You could even make it dynamic, fine-tuning the constants for a time interval based off the energy balance performance of the last interval. This would make the accuracy of the constants themselves nearly irrelevant. As you know, with multiple constants you are trying to solve for, there will be multiple sets of constants that will give the same solution, at least in the short term. By changing them dynamically, calculating the actual constants for the vehicle won't matter, because you have a solution, a set of constants, that will work for at least the next 5 minutes.

It's similar to how Solver in Excel works. Often, when using Solver in conjunction with least-squares regression to match complicated model functions to data, the constants you get are not physically possible (in the case of using Excel to model phsyical reality). Even with that in mind, the resulting solution does match the data over the range given. Eventually, the model will no longer match the data, but in the short term, it will match it very well, without actually knowing the constants.

Depending on what the mathematical equations of each function are (exponential, power-law, hyperbolic, etc... ), all you need is a model using that sort of function (or even the whole series of functions for all the thermodynamics inputs and outputs) and the energy balance data from the past 5 or 10 minutes. Then use Solver-methodology (I forget the numerical method used, I'll look it up in my numerical method book tonight, though it'll be much later) to tweak the constants so that the model match very closely to the constants in the past interval and apply those constants to the next interval.

Now that I think about it, an even shorter interval might be useful, to take into account varying sunloads, doors opening/closing, windows being down, stop and go traffic, and the adding/subtracting additional passengers. Possibly 1 minute intervals?

I'm a Petroleum Engineering student, and while we are often warned about not allowing constants to range outside their phsyical boundaries when using regression with Solver in Excel, that is because we are attempting to extrapolate trends 30 or more years past the end of the data for our reserve calculations, so the model must be technically sound, sometimes at the expense of model-data correlation. In the context of an automatic HVAC system, there is no need to extrapolate very far in the future, because you can simply take another measurement and do some quick calculations.

I've been reading all your threads on the topic, and I think you've been doing great work!

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

Thanks for all the hard work guys, you've been an inspiration!

Thanks for the encouragement. Yeah, we're pretty much on the same page with the short term testing method of solving the multiple-solution-to-the-equation problem.

I'm pretty sure I already have basic, industry standard values for starting points, but I'm going to keep verifying and tuning them.

I hope to have something substantial done by the end of the year. I'm sorry so slow, but it is a hobby, I want to allow myself to use the training I'll get, and stuff takes time.

I think one of the great things about solving for constants on a continual basis, and not starting with "exact" values, is that it takes into account the changes and even though the total square inches of aluminum in the heater core is unknown, we will have a variable that represents it and others over time, and over time it will more closely represent the actual value.(quite optimistic point of view though)

drk · 04-22-2008, 01:26 PM

Wow, now that I think about this, you could possibly even do this without any sort of thermodynamic calculations

Though it wouldn't be applicable to every vehicle like the dynamic approach.

I'll have to wait until I have my new truck with a CarPC with a FB and sensors installed, but I think I can come up with a model (specific to my vehicle). I'll simply gather a large amount of data, with varying outside temperatures, desired inside temperature, blower speed, hot/cold door position, and possibly humidity. I'll probably set it to record data points every 15s or so for the 1st ten minutes I drive, every time I drive, for a few months.

Then I'll use a software package created by a world-renowned professor of mine in the field of numerical methods and correlations (Dr. Peter Valko) to create a model based off just those variables measured. The true constants will be built into the data gathered and his software package comes up with amazingly complicated correlations and models. If I gather enough data points, the model will match my truck's thermodynamic behavior very well. Then I'll just have to plug my current interior temperature, current exterior temperature, desired temperature, and humidity, and it will spit out a fan speed and hot/cold position.

I'll just set it to constantly update the speed and position based off the variable data being gathered. The model itself will take into account energy balance to maintain temperature once the desired temperature is reached.

I think I would prefer this to the thermodynamic method, instead of matching the theoretical model the to the data you are using a model derived directly from the data. The nice thing about this method is that it will take into account any "hidden" variables that the thermodynamic equations do not account for. You are operating based on the behavior of the vehicle, not the thermodynamic theory, which may be imperfect.

Unfortunately, this method would not be dynamic. So it's a trade-off. More accurate in predicting real-world performance, but less adaptable to change (would be different with passengers, tint, etc... )

h3rk · 04-22-2008, 01:31 PM

I've thought a lot about that. And perhaps I may use similar method, but still constrain it with boundaries based on thermodynamics. I really want whatever I do to be fully portable. Great ideas.

drk · 04-22-2008, 01:40 PM

Quote: Originally Posted by h3rk

I've thought a lot about that. And perhaps I may use similar method, but still constrain it with boundaries based on thermodynamics. I really want whatever I do to be fully portable. Great ideas.

Have you ever thought of combining the two methods? Develop a data-derived model using all the input variables, but still have it vary the constants based off the the past interval's actual performance?

That might be the best of both worlds, a model derived directly from the data that takes into account all variables and constants, known and unknown, and then you tweak the constants in the model using the dynamic method based off energy balance performance.

Though the only way I can think that would work would be to develop a general model based off data from multiple types of cars. Gathering data would be an issue, because I don't think there's too many people aside from you and me who would be willing to install multiple sensors and gather months worth of data in order to improve the general model.

If I was an OEM with all kinds of R&D money, that's what I'd do. Of course, that's probably what the OEM guys have already done

h3rk · 04-22-2008, 01:45 PM

My plan is that the tests are developed such that, despite the make or size of the vehicle, the model is the same.
There is very little data I think the user will have to manually enter... if everything goes as planned.
It doesn't really matter what the initial values are, if they tune in over time.

drk · 04-22-2008, 02:09 PM

Quote: Originally Posted by h3rk

My plan is that the tests are developed such that, despite the make or size of the vehicle, the model is the same.
There is very little data I think the user will have to manually enter... if everything goes as planned.
It doesn't really matter what the initial values are, if they tune in over time.

I just meant the data that would need to be gathered to develop the model, the end user wouldn't need to input much of anything except desired temperature.

How are you planning to have the value update? Will it be an average over time (possibly the past x hours/days)? Or will the values for the last interval recorded simply over-ride the previous values? I can see how both would be of value. Maybe both? Track the previous interval, factor it into the overall average, and then make a weight average of the two, with the previous interval being more heavily weighted?

I don't know if I'd want the last 5 minutes solely determining the performance for the next 5 minutes, because things can change rapidly and I'd prefer a better overall average performance. Then again, I also don't want the overall average for the past x hours/day solely determining the next 5 minutes of performance if my current conditions aren't average. Something like a 70/30 past interval/time average weighted average maybe?

Hmmm, plenty of questions, no easy answers

h3rk · 04-22-2008, 02:15 PM

I think I have a post in here where I went through updating...

it was a half-step method where the constant was an average of the last X stored values while thowing out the ones that didn't fit the trendline within a tolerance. Then as a new test is satisfied, the new constant canidate is averaged with the currently used average constant value. That watered down average of current and recent becomes a new value in the array of X stored values (the oldest is bumped out).
The evolution of the constant would be very slow and conservative that way, I think.

drk · 04-22-2008, 02:16 PM

Quote: Originally Posted by h3rk

I think I have a post in here where I went through updating...

it was a half-step method where the constant was an average of the last X stored values while thowing out the ones that didn't fit the trendline within a tolerance. Then as a new test is satisfied, the new constant canidate is averaged with the currently used average constant value. That watered down average of current and recent becomes a new value in the array of X stored values (the oldest is bumped out).
The evolution of the constant would be very slow and conservative that way, I think.

Very nice, I musta missed that post!

It looks like servo control and analog outputs for the Brain should be along shortly, making this project much closer to a reality!

greenman100 · 04-22-2008, 02:23 PM

Quote: Originally Posted by drk

I just meant the data that would need to be gathered to develop the model, the end user wouldn't need to input much of anything except desired temperature.

How are you planning to have the value update? Will it be an average over time (possibly the past x hours/days)? Or will the values for the last interval recorded simply over-ride the previous values? I can see how both would be of value. Maybe both? Track the previous interval, factor it into the overall average, and then make a weight average of the two, with the previous interval being more heavily weighted?

I don't know if I'd want the last 5 minutes solely determining the performance for the next 5 minutes, because things can change rapidly and I'd prefer a better overall average performance. Then again, I also don't want the overall average for the past x hours/day solely determining the next 5 minutes of performance if my current conditions aren't average. Something like a 70/30 past interval/time average weighted average maybe?

Hmmm, plenty of questions, no easy answers

You can do all this with the MDX version, using mathematical functions, variables, and IF/THEN statements. All we need to add is the ability to save variables long-term in some file.

drk · 04-22-2008, 08:35 PM

Quote: Originally Posted by greenman100

You can do all this with the MDX version, using mathematical functions, variables, and IF/THEN statements. All we need to add is the ability to save variables long-term in some file.

It looks like the hardware capabilities should be available to make this soon.

After that, I'm sure there will be plenty of coding to do.

Once I have my new vehicle, I'll get to work right away on getting my carputer into it so I can begin recording data. It'll be interesting to see how H3rk's approach and mine play out. I will play to my strengths and stick to mainly dealing with modeling and correlating, basically using what I talked about above, completely ignoring the thermodynamic functions involved, and develop a completely novel model using my professor's software, based only off the input variables of cabin temp, outside temp, desired temp, and possibly humidity (I'd rather not use humidity, but I think it has enough of an impact to make it worth accounting for, at least in the data gathering stage). By it's nature it will account for the thermodynamic processes involved, but I highly doubt the model generated will match anything the OEM's use, as it will be unique to my vehicle and I very much doubt the auto industry uses the oil-industry correlation-generating software that I will be. When generating the model, I'll solve both with and without the humidity data and see how well the models work out.

I think the upside to this method would be a minimized number of constants needed due to the novel nature of the model versus the combination of multiple thermodynamic models as used in H3rk's method.

From there, I'd use a similar approach to H3rk's, with a rolling array for each constant (though the constants themselves would be different because of the different models) of the past x iterations to calculate an average constant to be used for the next iteration.

From what I understand, H3rk's approach will use previously established thermodynamic models, starting from approximate constants and fine-tuning over the life of the system. The nice thing about this method is that it is based on established thermodynamic models that are currently used by the OEM's.

The simultaneous upside/downside of both our methods is the necessity of using a numerical method to find a solution for fan speed and door position, the upside being that you don't actually need to know the constants (though if fairly simple numerical methods are to be used, you need a reasonable approximation as a starting point; if more complicated methods are to be used, you don't even need reasonable starting points, just start all the constants at 1 and let her rip!

).

The flip side of that coin is that by not actually knowing the constants and instead solving them iteratively, you don't get a unique solution. Multiple solutions will exist for the same set of data, and most of the results will likely not make sense when viewed from a physical reality context. H3rk, you will likely find that if you attempt to set realistic boundaries for the constants, one or more of the constants will quickly go to the max/min of your realistic range and won't shift from those values, no matter the number of iterations. Much of this will depend on the level of sophistication of the numerical method you use to find the solutions and the starting point you are solving from, but it will likely present itself.

It'll be interesting to see how both the models work out. I'll have to see how adaptable my model will be to a new vehicle. I have a feeling it will be slightly more touchy, especially if it reduces the necessary number of constants needing refinement, as the variance between vehicles will have to accounted for with less variables to tune with. Once again there is a flip side to this, as less variables/constants means less possible solutions and an increased likelihood of reaching the correct (or close enough to correct) solution.

Like I said, should be interesting

greenman100 · 04-22-2008, 09:07 PM

Quote: Originally Posted by drk

It looks like the hardware capabilities should be available to make this soon.

After that, I'm sure there will be plenty of coding to do.

The "coding" shouldn't be bad, it's all logic-block based

h3rk · 04-22-2008, 10:04 PM

And as always, beyond the core control scheme, and even for those happy without automatic, there are a few different ways the physical connections can be done, categorically speaking. Most will be happy with simulating button presses and knob turns, thus interfacing with the stock control head as a robotic controls manipulator, some will want to fully tear out the control head and hand over the low level controls to the computer, and some will want to retain both.

I was originally signing up myself for the middle version, but being that each of my servos are controlled by a (what appears to be) 1wire bus, where locally the servos decode the message (if it's meant for that servo) and adjust the servo to the position rrequired by it's packet of data, and then it sends a 'done' message to the control head. I know that FB can't do this, and I don't want to gut the servos so I am going to interface with the factory control head. I wanted to make it so that I can still use the factory controls as inputs to the brain, where the display will keep up on the status, but then the physical controls would turn by servo if I changed the setting with the touchsreen... but looking at the setup, I'm not so sure it's remotely possible... but that's just fancy extra stuff.

drk · 04-23-2008, 01:46 AM

Quote: Originally Posted by h3rk

And as always, beyond the core control scheme, and even for those happy without automatic, there are a few different ways the physical connections can be done, categorically speaking. Most will be happy with simulating button presses and knob turns, thus interfacing with the stock control head as a robotic controls manipulator, some will want to fully tear out the control head and hand over the low level controls to the computer, and some will want to retain both.

I was originally signing up myself for the middle version, but being that each of my servos are controlled by a (what appears to be) 1wire bus, where locally the servos decode the message (if it's meant for that servo) and adjust the servo to the position rrequired by it's packet of data, and then it sends a 'done' message to the control head. I know that FB can't do this, and I don't want to gut the servos so I am going to interface with the factory control head. I wanted to make it so that I can still use the factory controls as inputs to the brain, where the display will keep up on the status, but then the physical controls would turn by servo if I changed the setting with the touchsreen... but looking at the setup, I'm not so sure it's remotely possible... but that's just fancy extra stuff.

I was actually looking into something similar earlier today. What I found was motorized potentiometers. All the ones I found weren't too expensive (something like $4/unit), and seemed fairly simple to adapt into use with an FB. The motor controls the potentiometer, or it can be adjusted manually with a knob.

The motor turns anytime it recieves anywhere between 3-12V DC and turns in reverse when the voltage is reversed. Would it be possible to control this with the new FB's servo controls or analog out?

You'd need to be able to reverse the polarity of the charge to go in reverse. The potentiometer itself would basically be a feedback loop for the FB, hooked to an analog input to monitor knob position (in the case it has been changed while the system is off or booting).

Then you could rig up one of the motorized potentiometers behind each of your current A/C knobs and be able to use your A/C when the PC power is on AND off. I'd probably relocate my factory A/C controls to the glove comparment or inside the center console, just as a backup when the PC is down.

You could even mount the controls out in the open and watch the knobs turn on their own when you change the settings on the PC or the automatic system adjusts itself!

EDIT: Maybe you can use a digital output to control a smaller scale version of this.....
http://www.adc9001.com/index.php?src...current-MOSFET in conjunction with a relay that blocks the circuit. So when nothing is being changed, polary is normal and the relay is closed. When you want to turn the motor clockwise, the FB just opens the relay, when you want to turn counter-clockwise, it reverses the voltage and then opens the relay. This may be outside the realm of possibility, but I'm just brainstorming. It's probably easier to find a motorized potentiometer that operates without a polarity reversal.

2nd EDIT: http://www.specsensors.com/custom.asp#motor If you go there and scroll down to the motorized potentiometers, they have a compact .674" designed to be used in aircraft cockpits. It might be right up your alley, though it doesn't mention the input voltages necessary to turn the motor either direction. That would be much simpler than what I just mentioned above, just using a single analog output and input on the FB. Output to control movement, input to read current position.

The problem then remains of keeping the factory controls. You could possibly use 2 of those motorized potentiometers, one attached to the AC control board, the other to the factory knob mounted somewhere, and have them sync with each other in the FB software, using 2 analog inputs and outputs per A/C control knob.