search

KentuckySolarCar / Telemetry-GUI

This code will run on a desktop machine, and display the data the solar car sends from an rs 232 connection
8 stars 1 forks source link

More Calculations #2

Open egtoney opened 9 years ago

egtoney commented 9 years ago

After going through this code. I found that this program requires all of the individual temperatures of each battery cell. This is a problem because the program on the car only sends average temperature and voltage over telemetry. This information is still being logged on the car just not sent over telemetry to reduce the amount of information going over telemetry. I just wanted to make sure this got cleared up before I went in and did the necessary updates.

dcambron commented 9 years ago

Personally, I like not having each individual voltage and temp over telemetry. 99% of the time, we're only interested in the stats. I suggest you modify the gui to match what you already have coming over telemetry. An added feature though could be the ability to query specific pieces of 8nfo if we needed it. On Jun 7, 2015 11:25 PM, "Ethan Toney" notifications@github.com wrote:

After going through this code. I found that this program requires all of the individual temperatures of each battery cell. This is a problem because the program on the car only sends average temperature and voltage over telemetry. This information is still being logged on the car just not sent over telemetry to reduce the amount of information going over telemetry. I just wanted to make sure this got cleared up before I went in and did the necessary updates.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2.

egtoney commented 9 years ago

Here are my proposed edits to the GUI. To help explain I am only discussing changing the two large boxes on the left side that hold all of the battery red/blue temperature meters. Number 1 below contains my proposed changes for Batman's rectangle (the far left one) and number 2 has the changes for Robin's rectangle (to the right of Batman). I want your opinions on what should be added in this new found empty space. Here is what the GUI currently looks like to help.

Screenshot

// Monday 06/08/15 at 11:31PM - 1 files in 0.01 secs

TODO (2)

  1. Telemetry-GUI/telemetry.py:320 (Ethan) Replace Batman display with a real time log and a command line at the bottom to send commands to the car.
  2. Telemetry-GUI/telemetry.py:337 (Ethan) Replace Robin display with two of the battery displays for each battery box. Or possibly something else. Suggestions wanted.
cheintz commented 9 years ago

Ethan,

Both of those sound like good options.

Please also add min, max, avg. temperature to the battery summary to the right.

If you have room, I would request the following (probably at the expense of the Robin display):

The following on a 60 second moving average:

Battery Charge Remaining (This is a hard one): watt*hours / watt hours

Solar Energy Remaining In Day:

Please also alter the graphs to the right as follows:

I am currently in the process of making the tables

It would be SWEET if the output of these predictive-ish results were logged, so after a day, we can see how well they correlated to the actual values. There is no such thing as too much data, until we run out of storage space or bandwidth.

Also note that I believe that the battery log still only captures either batman or robin, but not both.

Thanks, Chris

On Mon, Jun 8, 2015 at 11:38 PM, Ethan Toney notifications@github.com wrote:

Here are my proposed edits to the GUI. To help explain I am only discussing changing the two large boxes on the left side that hold all of the battery red/blue temperature meters. Number 1 below contains my proposed changes for Batman's rectangle (the far left one) and number 2 has the changes for Robin's rectangle (to the right of Batman). I want your opinions on what should be added in this new found empty space. Here is what the GUI currently looks like to help.

[image: Screenshot] https://github.com/KentuckySolarCar/Telemetry-GUI/blob/master/img/screenshot.png

// Monday 06/08/15 at 11:31PM - 1 files in 0.01 secs TODO (2)

  1. Telemetry-GUI/telemetry.py:320 (Ethan) Replace Batman display with a real time log and a command line at the bottom to send commands to the car.
  2. Telemetry-GUI/telemetry.py:337 (Ethan) Replace Robin display with two of the battery displays for each battery box. Or possibly something else. Suggestions wanted.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110214471 .

uksolarcar commented 9 years ago

Ethan,

I like Chris' suggestions. It looks like we have a fair amount of coding to do.

If you don't mind, i'll take care of implementing the State of Charge (SOC) function. This is what Chris was talking about concerning all of those look-up tables and estimating the 'fuel' remaining in the battery pack.

Please let me know if you need me to help explain some of these calculations. They would definitely be nice to have for the race.

University of Kentucky Solar Car Team solarcar@engr.uky.edu http://www.engr.uky.edu/solarcar/

On Tue, Jun 9, 2015 at 8:03 PM, cheintz notifications@github.com wrote:

Ethan,

Both of those sound like good options.

Please also add min, max, avg. temperature to the battery summary to the right.

If you have room, I would request the following (probably at the expense of the Robin display):

  • Array Power (since the MPPTS do not currently work over telemetry, this would be calculated as Battery Voltage * (Motor Current - Battery Current). (This should be fairly un-smothed)(resettable with button):
  • The following, resettable with a button:
  • Gross Watt*hours used (computed by the Motor Controller's watt hours at current minus that at start
  • Net Watt_hours used (Computed as above, but account for the average array power(above)_time
  • Average speed (use odometer divided by time, for accuracy
  • Average Gross power (gross watt*hours, divided by time)
  • Average Net Power (net watt*hours, divided by time)

The following on a 60 second moving average:

  • Gross Average Power (watts)
  • Gross Average watt hour/mile/mile (averaged using 60 second moving average), using motor controller DC bus current, motor DC bus voltage, and vehicle velocity
  • Battery only Run-time Remaing (h:mm) (using the current average power and battery pack charge, see below)
  • Battery Only Range (using current gross average watt*hour/mile and battery SoC (below)
  • Battery and Solar Run-time (h:mm) _ same as Battery only, but with remaining energy based on time of day (below)
  • Battery and Solar Distance

Battery Charge Remaining (This is a hard one): watt*hours / watt hours

  • Based on the module voltage (and 2 tables table) Compute the following for each module: amp*hours remaining, amp hours fully charged
  • Look up amp hours remaining in a third table to get watt hours remaining for the WHOLE PACK at that voltage That is the charge remaining
  • Compute AH remaining - AH total. Take the minimum, look it up in a fourth table, and that is the effective capacity of the pack in W*h

Solar Energy Remaining In Day:

  • Based on a time-averaged array power, the current time, and (ideally) longitude and latitude)
  • exact formula to follow, or your discretion. The goal is to account for the sun going up/down, and also current weather/array conditions with the average.

Please also alter the graphs to the right as follows:

  • Leave the speed graph
  • Gross Instant Power (computed as above, but without the 60 second average)
  • Array Power (as computed above)
  • Leave pack voltage
  • If possible, add a graph for Battery Charge Remaining (above)

I am currently in the process of making the tables

It would be SWEET if the output of these predictive-ish results were logged, so after a day, we can see how well they correlated to the actual values. There is no such thing as too much data, until we run out of storage space or bandwidth.

Also note that I believe that the battery log still only captures either batman or robin, but not both.

Thanks, Chris

On Mon, Jun 8, 2015 at 11:38 PM, Ethan Toney notifications@github.com wrote:

Here are my proposed edits to the GUI. To help explain I am only discussing changing the two large boxes on the left side that hold all of the battery red/blue temperature meters. Number 1 below contains my proposed changes for Batman's rectangle (the far left one) and number 2 has the changes for Robin's rectangle (to the right of Batman). I want your opinions on what should be added in this new found empty space. Here is what the GUI currently looks like to help.

[image: Screenshot] < https://github.com/KentuckySolarCar/Telemetry-GUI/blob/master/img/screenshot.png

// Monday 06/08/15 at 11:31PM - 1 files in 0.01 secs TODO (2)

  1. Telemetry-GUI/telemetry.py:320 (Ethan) Replace Batman display with a real time log and a command line at the bottom to send commands to the car.
  2. Telemetry-GUI/telemetry.py:337 (Ethan) Replace Robin display with two of the battery displays for each battery box. Or possibly something else. Suggestions wanted.

— Reply to this email directly or view it on GitHub < https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110214471

.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110538916 .

cheintz commented 9 years ago

Yes, I just talked with Daniel and it seems SoC is an even more difficult subject than I though.

Some other things that should be "resettable" with the button:

That should let us advise the driver on their performance within a lap (doing better or worse than last time, like split time, but with energy)

Chris

On Tue, Jun 9, 2015 at 8:32 PM, University of Kentucky Solar Car Team < notifications@github.com> wrote:

Ethan,

I like Chris' suggestions. It looks like we have a fair amount of coding to do.

If you don't mind, i'll take care of implementing the State of Charge (SOC) function. This is what Chris was talking about concerning all of those look-up tables and estimating the 'fuel' remaining in the battery pack.

Please let me know if you need me to help explain some of these calculations. They would definitely be nice to have for the race.

University of Kentucky Solar Car Team solarcar@engr.uky.edu http://www.engr.uky.edu/solarcar/

On Tue, Jun 9, 2015 at 8:03 PM, cheintz notifications@github.com wrote:

Ethan,

Both of those sound like good options.

Please also add min, max, avg. temperature to the battery summary to the right.

If you have room, I would request the following (probably at the expense of the Robin display):

  • Array Power (since the MPPTS do not currently work over telemetry, this would be calculated as Battery Voltage * (Motor Current - Battery Current). (This should be fairly un-smothed)(resettable with button):
  • The following, resettable with a button:
  • Gross Watt*hours used (computed by the Motor Controller's watt hours at current minus that at start
  • Net Watt_hours used (Computed as above, but account for the average array power(above)_time
  • Average speed (use odometer divided by time, for accuracy
  • Average Gross power (gross watt*hours, divided by time)
  • Average Net Power (net watt*hours, divided by time)

The following on a 60 second moving average:

  • Gross Average Power (watts)
  • Gross Average watt hour/mile/mile (averaged using 60 second moving average), using motor controller DC bus current, motor DC bus voltage, and vehicle velocity
  • Battery only Run-time Remaing (h:mm) (using the current average power and battery pack charge, see below)
  • Battery Only Range (using current gross average watt*hour/mile and battery SoC (below)
  • Battery and Solar Run-time (h:mm) _ same as Battery only, but with remaining energy based on time of day (below)
  • Battery and Solar Distance

Battery Charge Remaining (This is a hard one): watt*hours / watt hours

  • Based on the module voltage (and 2 tables table) Compute the following for each module: amp*hours remaining, amp hours fully charged
  • Look up amp hours remaining in a third table to get watt hours remaining for the WHOLE PACK at that voltage That is the charge remaining
  • Compute AH remaining - AH total. Take the minimum, look it up in a fourth table, and that is the effective capacity of the pack in W*h

Solar Energy Remaining In Day:

  • Based on a time-averaged array power, the current time, and (ideally) longitude and latitude)
  • exact formula to follow, or your discretion. The goal is to account for the sun going up/down, and also current weather/array conditions with the average.

Please also alter the graphs to the right as follows:

  • Leave the speed graph
  • Gross Instant Power (computed as above, but without the 60 second average)
  • Array Power (as computed above)
  • Leave pack voltage
  • If possible, add a graph for Battery Charge Remaining (above)

I am currently in the process of making the tables

It would be SWEET if the output of these predictive-ish results were logged, so after a day, we can see how well they correlated to the actual values. There is no such thing as too much data, until we run out of storage space or bandwidth.

Also note that I believe that the battery log still only captures either batman or robin, but not both.

Thanks, Chris

On Mon, Jun 8, 2015 at 11:38 PM, Ethan Toney notifications@github.com wrote:

Here are my proposed edits to the GUI. To help explain I am only discussing changing the two large boxes on the left side that hold all of the battery red/blue temperature meters. Number 1 below contains my proposed changes for Batman's rectangle (the far left one) and number 2 has the changes for Robin's rectangle (to the right of Batman). I want your opinions on what should be added in this new found empty space. Here is what the GUI currently looks like to help.

[image: Screenshot] <

https://github.com/KentuckySolarCar/Telemetry-GUI/blob/master/img/screenshot.png

// Monday 06/08/15 at 11:31PM - 1 files in 0.01 secs TODO (2)

  1. Telemetry-GUI/telemetry.py:320 (Ethan) Replace Batman display with a real time log and a command line at the bottom to send commands to the car.
  2. Telemetry-GUI/telemetry.py:337 (Ethan) Replace Robin display with two of the battery displays for each battery box. Or possibly something else. Suggestions wanted.

— Reply to this email directly or view it on GitHub <

https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110214471

.

— Reply to this email directly or view it on GitHub < https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110538916

.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110544079 .

egtoney commented 9 years ago

Okay! I'll get started on changing the GUI to hold all of that information. After the GUI is complete I'll work on implementing all of the calculations. So, you guys have time to work out all of the equations that would be required for this. When I get there I'll use the equations that Chris posted above unless different ones are given to me later. Hopefully I'll have most of the GUI done this weekend.

Also Chris, you mentioned that you would like all of these calculations logged. Just clarifying you want this logged on the computer running the Telemetry-GUI and not the car. Also, I'll look into the battery log problem on the car.

egtoney commented 9 years ago

Here is the new layout! Respond if you guys have any edits that need to be made. Also none of the functionality is implemented yet this is just the layout. Also let me know if I forgot something! Oh yeah also the B that you see in the 3rd column is going to be replaced with a refresh button.

telemetry_gui_new_layout

cheintz commented 9 years ago

Ethan,

That looks great!

Some things:

Please indicate which values are smoothed on the GUI

Should be "gross average watt hour/mile", not squared

Battery and Solar range, not distance (possibly my bad)

The MPPT section can go, as we don't have that data yet (and almost certainly won't by the race)

We also want min, max, average battery temperature

Add four inputs 4 inputs to allow for parametric model inputs into solar energy model, a,b,c,d

I don't think I was clear on the reset-able parameters: The following should all be reset by one button, and be in addition to other displays: Average speed since reset Average motor power since reset average motor - array power since reset distance since reset time since reset.

It would be amazing (and definitely require a high-res monitor on the laptop we use) if you could take that data and plot a new data series on vertically-aligned graph vs. distance (or time, by checkbox) of the following (mostly from above). The idea would be to graph each lap around the track concurrently and advise the driver on technique. Instantaneous speed (mph) Instant motor power (W Instant motor energy (watt*hours)since reset

The log should be written to the computer, and should contain, in a CSV format, the following

Current time, hh:mm:ss.ss (24 hour format preferred) Total battery voltage (V) Array Power (W) Motor Power (W) Battery Power (W) Battery only runtime (seconds) battery only range (miles) Battery+Solar runtime (seconds) battery+solar range (miles) Solar Energy Remaining (W*h) count of how many times the reset button has been pressed (what lap of the day we are on)

Thanks, Chris

On Wed, Jun 10, 2015 at 10:25 PM, Ethan Toney notifications@github.com wrote:

Here is the new layout! Respond if you guys have any edits that need to be made. Also none of the functionality is implemented yet this is just the layout. Also let me know if I forgot something!

[image: telemetry_gui_new_layout] https://cloud.githubusercontent.com/assets/8811242/8098536/5783461a-0fbf-11e5-93d6-02695b30be52.png

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-110972501 .

egtoney commented 9 years ago

Daniel, when you said that you only wanted the Speed, Current, and some M value from the motor controller, what was the M value suppose to be? Up to this point you have just had me set it to 0. Also, this will not be a problem and I can just remove it if we don’t need it for the calculations.

codemaestro3000 commented 9 years ago

For the array power equation it has 'battery voltage' and 'battery current'. Did you want array power for each battery?

dcambron commented 9 years ago

I believe M stood for the Array current that we were to be getting from the MPPTs. We don't have that data so we can use Array Current = Motor Current

On Thu, Jul 16, 2015 at 9:05 PM, Ethan Toney notifications@github.com wrote:

Daniel, when you said that you only wanted the Speed, Current, and some M value from the motor controller, what was the M value suppose to be? Up to this point you have just had me set it to 0. Also, this will not be a problem and I can just remove it if we don’t need it for the calculations.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122141287 .

uksolarcar commented 9 years ago

Array power is Array Current * total pack voltage, where total pack voltage is the sum of each battery voltage. So this will be a single value. If you don't have every battery voltage but you do have an average voltage, then Array power = Array Current * Avg Voltage * 40. Note that Array current equation was given in my previous comment.

On Thu, Jul 16, 2015 at 10:02 PM, crba233 notifications@github.com wrote:

For the array power equation it has 'battery voltage' and 'battery current'. Did you want array power for each battery?

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122149207 .

egtoney commented 9 years ago

When we use the battery values do you want us to just sum up the two individual battery’s values?

cheintz commented 9 years ago

Yes. Please use the average battery current for the array calculations.

Please also use the following expression so that sign conventions work nicely Array current = motor controller current - Battery Current

On Thu, Jul 16, 2015 at 10:22 PM, University of Kentucky Solar Car Team < notifications@github.com> wrote:

Array power is Array Current * total pack voltage, where total pack voltage is the sum of each battery voltage. So this will be a single value. If you don't have every battery voltage but you do have an average voltage, then Array power = Array Current * Avg Voltage * 40. Note that Array current equation was given in my previous comment.

On Thu, Jul 16, 2015 at 10:02 PM, crba233 notifications@github.com wrote:

For the array power equation it has 'battery voltage' and 'battery current'. Did you want array power for each battery?

— Reply to this email directly or view it on GitHub < https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122149207

.

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122151304 .

egtoney commented 9 years ago

To reduce errors in these calculations and to help Cody and my blood pressure could you guys please give us equations for all of the above values given the following inputs...

Battery (Robin) Battery (Batman) Motor
vAvg vAvg S (speed)
vMax vMax C (current)
vMin vMin M
BC BC
tMax tMax
tMin tMin
tAvg tAvg
dcambron commented 9 years ago

Current time, hh:mm:ss.ss (24 hour format preferred) = your timestamp Total battery voltage (V) = Robin.vAvg_20 + Batman.vAvg20 (assuming vAvg in units of volts) Array Power (W) Motor Power (W) = Motor.C * Total Battery Voltage as computed above Battery Power (W) = Total Battery Voltage * (Robin.BC + Batman.BC ) / 2.0 Battery only runtime (seconds) = SOCmodel.Capacity (in Coulombs) * 2 ( %SOC/100.0 ) / long term avg of (Robin.BC + Batman.BC ) / 2.0 battery only range (miles) = Battery only runtime * Motor.S (in mph) / 3600.0 Battery+Solar runtime (seconds) = Battery only runtime + solar runtime from chris' model battery+solar range (miles) = Battery only range + solar range from chris' model Solar Energy Remaining (W_h) = from Chris' model count of how many times the reset button has been pressed (what lap of the day we are on)

On Fri, Jul 17, 2015 at 7:04 PM, Ethan Toney notifications@github.com wrote:

To reduce errors in these calculations and to help Cody and my blood pressure could you guys please give us equations for all of the above values given the following inputs...

  • We already have array power

    Battery (Robin) Battery (Batman) Motor vAvg vAvg S (speed) vMax vMax C (current) vMin vMin M BC BC tMax tMax tMin tMin tAvg tAvg

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122440701 .

codemaestro3000 commented 9 years ago

How do we calculate the motor controller's watt hours? Or is that something we should be receiving from the motor controller itself?

dcambron commented 9 years ago

watt-hours is a measurement of energy. I assume we're looking for the running total of energy expended by the motor since the program started, provided we have an option to reset the running count of how much energy we've expended since the program started.

watt-hours is calculated by:

integral (Motor.C * Total battery voltage) dt / 3600

It is easiest to to a Riemann sum: keep a variable called "Motor.watt-hours" every time you get a new current and voltage measurement, run the following code:

Motor.watt-hours += Motor.C in amps * Total battery voltage in volts * elapsed time in milliseconds since the last time you ran this line of code / 3600000.0

It may be better to instead calculate watt-seconds and then just divide by 3600 whenever you need to display it to the user. Thus the line of code would be:

Motor.watt-sec += Motor.C in amps * Total battery voltage in volts * elapsed time in milliseconds since the last time you ran this line of code / 1000.0

Also, I think the motor controller reports a watt-hour measurement. It's kind of like an odometer. It keeps track of how many watt hours has gone through the motor controller since it was built and programmed. However, I doubt this measurement is precise enough to help us. I'm sure it's pretty accurate though.

On Fri, Jul 17, 2015 at 8:07 PM, crba233 notifications@github.com wrote:

How do we calculate the motor controller's watt hours? Or is that something we should be receiving from the motor controller itself?

— Reply to this email directly or view it on GitHub https://github.com/KentuckySolarCar/Telemetry-GUI/issues/2#issuecomment-122458643 .

cheintz commented 9 years ago

Motor Controller Amp hours is tracked by the motor controller. Not sure if you want to send that over telemetry (and change the Pi code), but that would be more accurate. You would multiply the amp-hours from the motor controller by the average DC bus voltage from the motor controller (or the average total battery pack voltage as per Daniel above, or (less preferred) do the Riemann sum with the motor controller currents).

Here is some psudocode for the array model. This is just the easiest way do define it.

double solarNoonInHours = 1.5 ;   //These are the 4 GUI program
parameters I requested
double directMaxPower=900 ;
double indirectMaxPower=100 ;
//int dayTypeCode

//Yeah, using global variables in psudocode. I know. I'm an ME ;)

double elevationAngle (timeInHours )
{
    double latitude = 30.136416 ; // these are in degrees, as are all
constants in the equations. You may convert to radians, but please do not
repalce these values
    double declination = 21.08;
    double outValue = arcsine(
                cos(
(timeInHours-solarNoonInHours)*15)*cos(declination)*cos(latitude) +
                sin(declination)*sin(latitude)   );

                return outValue;

}

double powerWhileCharging(double timeInHours, )

{
    double elevAngle=elevationAngle(currentTimeInHours);

    return directMaxPower * (abs(cos(90-elevAngle))^0.3) + indirectMaxPower;

}

double powerWhileDriving(double timeInHour)
{
    double elevAngle=elevationAngle(currentTimeInHours);

    return directMaxPower * (abs(cos(90-elevAngle))^1.3) + indirectMaxPower *
((180-elevAngle)/180);

}

double energyRemainingInDay(double currentTimeInHours, int dayTypeCode)
{
    dt = .05 //This is 3 minutes #goodenough
    double stopToChargeTime = 17 // 5:00 PM
    double stopChargingInEve = 20 // 8 PM
    double startChargeInMorning = 7 // 7 AM
    double startRacingInMorning =  9 // 9AM

    double energy = 0;

    for (double i = currentTimeInHours, i<stopChargingEveTime, i+=dt)
    {
        energy+= powerWhileDriving(i) * dt;
    }

    if( dayTypeCode== 0)
        return energy;
    else
    {
        for(double i = stopToChargeTime, i<stopChargingInEve i+=dt)
        {
        energy+=powerWhileCharging(i) * dt;
        }
        return energy;

        if(requestTypeCode==1)
            return energy;
        else //requestTypeCode = 2

        {
            for(double i = startChargeInMorning, i<startRacingInMorning i+=dt)
            {
                energy+=powerWhileCharging(i) * dt;
            }
            return energy;
        }
    }
}

If you have questions, just let me know,
Chris
codemaestro3000 commented 9 years ago

What is the model for solar runtime and solar range? It was said to refer to Chris's models but I can't seem to locate them. Thanks.

cheintz commented 9 years ago

So, solar runtime is (solarEnergyLeftInDay + battery state of charge (in watt*hours)) / {the the long-term averaged motor power (in watts)} . that gets you an answer in hours.

Range is the (solarEnergyLeftInDay + battery state of charge (in watt_hours) )/ {long-term average <watt_hour / mile> number} . that gets us miles.

codemaestro3000 commented 9 years ago

Okay, In the 'solar energy left in day' model when calling the 'elevationAngle' function in the 'powerWhileDriving' function you pass it two parameters. The second parameter is not mentioned in the actual 'elevationAngle' function. Is something missing?

Thanks

cheintz commented 9 years ago

Fixed it, sorry. It was originally passed, but then I thought about it and it makes more sense to have it in global scope.

codemaestro3000 commented 9 years ago

Okay I have another question. I have the line of pseudo-code in question followed by asterisks:

for (double i = currentTimeInHours, i<stopChargingEveTime, i+=dt)
{
    energy+= powerWhileDriving(i) * dt;
}

if( dayTypeCode== 0)
    return energy;
else
{
    for(double i = stopToChargeTime, i<stopChargingInEve i+=dt)
    {
    energy+=powerWhileCharging(i) * dt;
    }
    return energy;  ********The code following this return statement will never be ran********

    if(requestTypeCode==1)
        return energy;
    else //requestTypeCode = 2

    {
        for(double i = startChargeInMorning, i<startRacingInMorning i+=dt)
        {
            energy+=powerWhileCharging(i) * dt;
        }
        return energy;
    }
}

}

Were you wanting this?

for (double i = currentTimeInHours, i<stopChargingEveTime, i+=dt)
         energy+= powerWhileDriving(i) * dt;

if( dayTypeCode== 0 )
        return energy;

for(double i = stopToChargeTime, i<stopChargingInEve i+=dt)
        energy+=powerWhileCharging(i) * dt;

if( dayTypeCode==1 )
        return energy;

for(double i = startChargeInMorning, i<startRacingInMorning i+=dt)
        energy+=powerWhileCharging(i) * dt;

return energy;
codemaestro3000 commented 9 years ago

Also in the solar runtime and range model you mention using the battery state of charge in watthours. Daniels script provides it in percentage. Is there a conversion? Thanks

cheintz commented 9 years ago

Ethan, your assumption is correct. Man, that's some sloppy psudocode I wrote...

The rough conversion from battery % to w*h is to multiply the fraction by 5000.

So 50% is 2500 wh, 100% is 5000 wh

Sorry for the delay, I was driving and just got in to Lexington