I’be been trying to get the Autosteer code to run on the ESP32. My intention was to keep the code as original as possible and I seem to be having issues that I just can’t pin down. They may be related to the speed of the ESP32, I’m not sure.
I’m not going to post the code (or a link to it) on the forum in case it is mistaken for working code by someone, but if a better coder than I is interested in giving me a pointer or two as to what is wrong I’d be grateful and will send you a github link.
I’ve modified my arduino code for the BNO085 and that is working just fine.
It would probably have been easier to start again with my own code.
I realise the impending AOG updates may make this partly futile but once it is working I will be fine. I just can’t pin down what is wrong.
What’s your problem? I have a modified, yet incomplete, Coffeetrac Autosteer_ESP version for AOG v4.3.10. I only updated it for the IBT_2 driver, but I plan on testing it for the cytron md13s shortly.
Most of my problems came from me over complicating things I think. I was struggling with data sizes and EEPROM. Not sure if it’s an Arduino vs ESP32 thing or just me but in the nano an int() is 2 bytes, in the esp32 it’s 4. So EEP_Ident was being partly overwritten by WAS_ZERO. I didn’t realise and was looking in completely the wrong areas so basically made myself a huge job out of potentially nothing.
I thought the BNO085 wasn’t working with the ESP32 but that issue was linked to the EEPROM issue.
Glad to hear you got it working. I had similar issues with overriding eeprom and printed everything out thru serial output each time I saved eeprom and when restarting the esp. Thats where I discovered the byte differences. I also had an issue with calculating the wheel angle from the udp message from AOG. Here is the autosteer_UDP_4.3.10.ino code:
The difference with these two is that the esp32 code wasn’t compiling the same and instead of the bitwise left shift storing it as a signed 16 bit integer, it was unsigned, meaning it was always positive. So, when a -1 degree value was expected, it would calculate the angle set point to +654.36 degrees instead, nearly throwing me out of the seat of the tractor. Anyway, after that change it successfully drilled cover crops without an incident.
Ah, thank you, and sorry I missed your reply. I have found a steer issue so may have the same problem. All works in drive mode but when steering to the line it closes in on the line reasonably steadily but then goes full opposite lock and keeps straining once it gets there. I’m struggling with testing time at the moment. Conditions are very wet here and I’ve a reasonably heavy paperwork load to complete.
[edit]
Reading your reply again I’m pretty certain I’ve got the same issue.
I’m not 100% sure, but I believe the absolute value of distanceFromCurrentLine is what gets sent from AOG to the board. I forgot to mention I made the same typecasting for distanceFromLine as I did for the steerAngleSetPoint:
