next topic »

[Reply #45 on:]

Beep for the last BIT.

Have to sleep now......

Paco

[Reply #46 on:]

Working on some other programming inside the project to add the suggestions.
Let you know when I get stuck again......

Paco

[Reply #47 on:]

So I got stuck again and after a few hours of experimenting I gave up.

Current code which have to work first correctly before I can add the curve section and debug that with all the requires settings of gamma start and gamma final.

Code:

//     +++++++++++++++ regular speed - brake mode +++++++++++++++
      //speedstartValue= constrain (speedstartValue,0,255);
      //speedcurveValue= constrain (speedcurveValue,0,255);
      //brakeNValue= constrain (brakeNValue,0,255);
      //modelNumber= constrain (modelNumber,1,10);
      
      // control the outputs with output cross block function to prevent speed and brake to be ON together
      sensorValue = analogRead(sensorspeedPin); // read the raw value from the linear hall sensor:
      sensorValue = map(sensorValue, sensorMin, sensorMax, 0, 255);// apply the calibration to the sensor reading from the hall sensor
      sensormappedValue = constrain (sensorValue,0,255); // keep value in range
      speedValue = map(sensormappedValue, 0, 255, speedstartValue, 255); // can be switched off later stage when curve section works.
      
      //  ++++  curve section  +++++++
      //if (sensormappedValue < 128)
      //  speedValue = (int) ( 0.5  +  speedstartValue + pow(sensormappedValue/127.0, gammaStart) * ((speedfinalValue - speedstartValue) / 2.0) );
      //else
      //  speedValue = (int) (0.5  +  speedfinalValue  -  pow((255 - sensormappedValue)/127.0, gammaFinal) * ((speedfinalValue  - speedstartValue) / 2.0));    
      //  ++++  curve section  +++++++
      
      speedfinalValue = speedValue;
      
      if (sensormappedValue > deathbandValue){analogWrite(pwmoutspeedPin, speedfinalValue); analogWrite(pwmoutbrakePin, 0); digitalWrite(led13Pin, LOW);}
       else {analogWrite(pwmoutspeedPin, 0); (speedfinalValue, 0);analogWrite(pwmoutbrakePin, brakeNValue);digitalWrite (led13Pin,HIGH);} // startspeed and curve included
      
      if (speedfinalValue < (speedfinalValueold-regenHyValue)){analogWrite(pwmoutspeedPin, 0); analogWrite(pwmoutbrakePin, brakeRValue);digitalWrite (led13Pin,HIGH);} // regenenrative breaking
      
      //if (regbrakeState == 1) then if (speedfinalValue < (speedfinalValueold-regenHyValue)){analogWrite(pwmoutspeedPin, 0); analogWrite(pwmoutbrakePin, brakeRValue);digitalWrite (led13Pin,HIGH);}

The last line that is commented is not working.
For the readability I added VB words.
When regbrakeState is active all behind it should be excecuted like the line above.
If not activated it should should not taken care of.

I know it is bacis coding but I did not see the light at the end  of the tunnel sofar.

Paco

[Reply #48 on:]

Remove the "then".    It is implied and not part of the language.     :-)

[Reply #49 on:]

Paco,

in the IDE you can press CTRL-T which does an auto-layout of the source code. More readable code is easier to modify.

Do you use some kind of version control? (just making a zip of the working version is OK).

[Reply #50 on:]

Techylah,

Whow, from all that I tried today the past few hours this was not what I suspected to work. But it does.........
It was so simple.......as usual, Thanks

Rob, did not knew that but if I perform CTRL + T, I get an error message.
Auto format canceled. Too many right parentheses.

Paco

[Reply #51 on:]

Rob, did not knew that but if I perform CTRL + T, I get an error message.
Auto format canceled. Too many right parentheses.

That means your {} and () and [] are not balanced, so the code will not compile either. Very difficult to see now where the error is,

This is why keeping the indentation style correct is so important.

a line like this

Code:

if (speedfinalValue < (speedfinalValueold-regenHyValue)){analogWrite(pwmoutspeedPin, 0); analogWrite(pwmoutbrakePin, brakeRValue);digitalWrite (led13Pin,HIGH);} // regenenrative breaking

should be written like

Code:

// regenenrative breaking
if (speedfinalValue < (speedfinalValueold-regenHyValue))
{
  analogWrite(pwmoutspeedPin, 0);
  analogWrite(pwmoutbrakePin, brakeRValue);
  digitalWrite (led13Pin,HIGH);
}

If you have notepad++, it can do autoindent too, maybe it helps you better to find the missing {[( brackets... than the arduino IDE

[Reply #52 on:]

Paco,
I am truly happy to help and to be on this forum.

That last line also has the mismatched parenthesis, preventing reformat.

Change it to:     (only 1 right paren before the curly open braces)

if (regbrakeState == 1) if (speedfinalValue < (speedfinalValueold-regenHyValue) {analogWrite(pwmoutspeedPin, 0); analogWrite(pwmoutbrakePin, brakeRValue);digitalWrite (led13Pin,HIGH);}

[Reply #53 on:]

Techylah,

I see what you mean and changed it.
Still same problem. Will go through it tonight again to check all brackets and curlys......

Thanks, Paco

[Reply #54 on:]

Rob,

I have sorted out the bracket and curly thing with CTRl+T.

Techylah,

I have talked to 2 different slot race guys last wednessday evening.
If I ask which curve they like to use they can not tell as nobody knows currently what exact curves they are using on their controllers as the are no EXACT numbers to be seen
Once again they say it is all about feeling and turning some knobs without fixed positions.
Every time they change lanes and cars they just start to turn the knobs to FEEL what is going to happen.

Regarding the curve drawn on paper they favored for a 75% linear line with a last 25% to be curved in the upper direction.
I think I have to start somewhere and try to get some rusty FEELINGS out of their hands and first try this curve.

One of the drivers which is competing at high level liked my suggestion for logging all data to recall after the race.
Also the option to alter by wireless Blue Tooth from a smartphone the settings of the controller while driving by an other person was highly welcomed. it is not available yet on an controller so no rulebook that can forbid it. 

But those two things are of a later concern.

I do run in some simple (as usual) code problems for setting same variables by push buttons and trough MENWIZ menu structure and save them to EEPROM after the last change was made the past three seconds.
Should I post it here or create a new question?

Cheers, Paco

[Reply #55 on:]

they favored for a 75% linear line with a last 25% to be curved in the upper direction.

Excellent research, Paco.
This means they still want "flooring it" to give them 100%, but they want to approach it with more control, so it takes more than just a little nudge to make it too fast.

I'm curious, now.  What would the experts think of making a real, dynamically changing throttle control?

Physically it would spring to a center-Neutral position, like the right-left control of a simple R/C car, but oriented in the front/back direction.
It would be in a handgrip with the following, hardly visible change.  Your middle three fingers would fit into an oval ring so, like a pair of scissors, you can easily spread open (to brake) as well as squeeze together (to accelerate).  It would have a digital readout of current speed (or actuation, really), but just to help the learning and understanding of it.

At any speed, leaving your fingers in the middle position keeps the speed the same.
Squeezing accelerates upward linearly, but with the last remaining 25% always curved to 100%.
Spreading accomplishes beaking linearly, but with the last 25% always curved to 0%.
Middle position always maintains and remembers the new current speed.

Benefits:  
1.  At any speed you get precise control right around your current speed.
2.  You can relax your hand in the middle position for any constant speed straightaways or demonstrations
3.  Full squeeze always gives you max speed.
4.  Full spread always gives you full brake.
5.  The middle of the controller position is always in a "sweet spot" centered around your current speed,
giving you the most control when making subtle changes when passing or finessing around another car.
6.  It would demo really cool. ("I am now going around the track at a constant safe and respectable pace. The controller maintains this speed in mid grip position.  See I can even put the controller down.   Now if I need to immediately pass, I squeeze.   If I need to immediately slow, I spread.  Note how I can at any time squeeze full to burn rubber or spread full to maximum brake to full stop")

It would feel like a quality variable speed drill, which provides excellent control at low speed, curving up to full speed at max squeeze.
The symmetric, deceleration part the drill doesn't have. (and doesn't need).

I think newbies could learn to drive this much easier than traditional, static controllers.  They could ratchet up their speed with a series of squeezes as they get comfortable to a new and higher current speed.  To come to an abrupt stop, they simply do a full spread and release.
Experts would benefit from the always more precise midrange speed control for tricks, passing, faking out, etc...
  

[Reply #56 on:]

Techylah,

Your correct that is how RC cars work except for the fact they do not keep speed at neutral position. They coast.
For the current project I think we first have to get the rusty slotters to a comfort zone where they understand that the FEELING is now visible.
So I want to start with the linear and last 25 % curve adjustment and see what the drivers think of it.
We later can add all electronic software tricks we can think of like the dynamic controlling you mentioned.

I stumbled like said in something simple of which I think it should work.
When values of variable are in or decremented I like to store them in the eeprom.
Read them is no problem.
But I do not want to save by each value in or decrement because if some one goes from 0 to 255 that means 255 writings.
My idea was to perform the saving after 3 seconds of the last in or decrement to extend eeprom life expectancy.

Would this code do the trick?

Code:

long tempMillis;

if (speedstartValue != speedstartValueold)
{
tempMillis = millis + 3000
}
if (millis > tempMillis)
{
EEPROM.write(2,speedstartValue);
speedstartValueold = speedstartValue;
}

So every value change will raise the 3 second time further until both times are the same then write once the value to the eeprom.

Paco

[Reply #57 on:]

Yes, essentially.  You need to add something that makes sure after writing the EEPROM, you don't keep writing it!
I'd slightly change it this way:

Code:

long tempMillis = 0;       // In the init code, not the loop()
....//....
if (speedstartValue != speedstartValueold)
     tempMillis = millis() + 3000;

if (tempMillis != 0  &&  millis() > tempMillis)
{
     EEPROM.write(2,speedstartValue);
     speedstartValueold = speedstartValue;
     tempMillis = 0;
}

Ok about the coasting. I think that means very gradually slow down, like a real vehicle, right?

[Reply #58 on:]

Techylah,

Correct coasting is just no power applied to the motor and no breaking so freewheeling as a normal car.

Yes the long needs to be in the top declaration (init loop).
Just put it there in case you say I forgot to declare it.  as it is just snippet code.

Correct too we do not want to keep flooding the EEPROM if not needed as it has an expected lifecycle of 100.000 or so.

Thanks,

Paco from a sunny garden 25+ degrees celsius.

[Reply #59 on:]

Techylah,

I added the led debug option to see if delay wroked as writing to memory is invisible.
I uploaded the sketch.
The led is direct on which according to the code should not happen as there is no key pressed at start up or afterwards.
If I press the key I see incremention of the value on display and key press confirmation.

Code:

void loop()
{

if (speedstartValue != speedstartValueold) //start timer
     tempMillis = millis() + 3000;
     digitalWrite(led11Pin,HIGH);
if (tempMillis != 0  &&  millis() > tempMillis)  //at end of timer
{
     //EEPROM.write(2,speedstartValue);
     speedstartValueold = speedstartValue;
     tempMillis = 0;
     digitalWrite(led11Pin,LOW);
}

speedstartValueold = speedstartValue; //control for value change

}  // end void loop()

Paco