why not do as in the cnc? fast forward until you press the limit switch, back a few millimeters and forward slowly to be more precise … more or less 
Well yes, more ideas then time always is the case. The newer way is just to follow the line only creating curves at start and end. No moving at all so the way it is is “good enough” for now.
Is it that you are back to the other end of the field before the turn completes?
Ah yes. Correct.
Wonder why it won’t work in the teensy then without the cast? i could see it not working if it was the other way around, but if you move 8 bits into a 32 bit int and move it over 8, OR the next 8 bits you should end up with the same number except half the number is zero’s.
PS, if you make teensy code or specific code it can be added to the Package in the release so other people can use it specifically for that processor. Then you can write it the best way for that chip rather then limiting it because of the AVR.
I haven’t tried on the pitch yet but only on the simulator, and it happened to me by creating a small field
I am sure a Teensy version is here to stay, also the ability to crunch doubles is sure to become an asset.
Plus all the Teensy Tiny Little programming jokes that can be made.
This morning is looking awful white outside, so coding is the way to spend the day.
It’s the negative numbers that don’t work. So based in my late night debugging 
what happens is related to the way integer is stored as two’s complement. In 16 bit everything over 32768 is negatives, but when Teensy spits out 32 bit integer that’s not the case and when you have say -10 as the value in 16 bit you have 65526 in the 32 bit int.
And regarding the serial.read() output, it does return the value of a byte but the return value is int type, just using 8 bits out of 16. Afaik you can’t overload functions in C based on return type so if it’s returning a -1 in case buffer is empty, it has to be an int always.
So the easy solution is cast it.
Contour can be really frustrating… Hopefully this will help.
4 Likes
YES!!! 
Frustrating but extremely useful!!
Can you replace all occurences of int with int16_t, unsigned int with uint16_t etc? Or are there other problems when casting to floats?
Thanks Brian that is a very handy fix!!
We go couple years and one just drives around field (or draws it on xxx-maps), and aog then creates optimal routes using some AI… 
It asks then if driver has cup of coffee with him, is answer yes, it makes less sharp turns etc…
Anyway, I’ve been reading couple of hours on totally this forum, everywhere everybody talks about roll.
I’m not farmer, but don’t you go up / down hills?
Doesn’t tilt mean anything in guidance?
I knew there was a better way, I’d suggest expanding this to locking the AB and Curve. Nice work.
More or less yes, then it should be explicitly defined. However, you still need to cast as serial.read() is returning a 32 bit int in a 32 bit system.
Just checked if it’s a Mac thing (shouldn’t be by any means…) and tried compiling the code in Win10 tablet with same results.
Surely then this …
steerAngleSetPoint = ((float)(Serial.read() | Serial.read() << 8 )) * 0.01;
shouldn’t work on an ESP32 or a Teensy?
…but it does.
Or have I got it wrong?
That’s my big dilemma, it doesn’t on my Teensy 4.0 but looks like it’s working on your 4.1 board for example?
steerValue is a float.
setCurve is an int16_t
steerValue = (steerAngleSetPoint*800);
setCurve = (int16_t) steerValue;
This conversion works on mine.
because if you drive straight forward the antenna is on the line in uphill and downhill, but if you drive on the side of a hill, the antenna is a bit left or right of the line, you have roll. and thats you need to compensate.
What is yours doing with it?
As I said in our conversation, I’m having similar problems but with another concept that I can’t use because of it.