2017-05-23, 16:10
Just approaching 4000 miles and over 1 year with automatic shifting. Here’s another update on how I’ve made it perform even better with an improvement to the code. It’s come a long way since the day I first upload the what now seems like basic code that made it automatic.
![[Image: OqQz8U.jpg]](http://imageshack.com/a/img924/8452/OqQz8U.jpg)
Whilst I have the ability to log the servos exact position I thought it would be interesting to got a accurate estimation of ratio against servo position. Its a different thing measuring it out on the road when the hub is under load. The graph shows that the ratio is lower than expected but this is probably due to how the hub interface is installed. If I took it off and moved it round by a notch I could increase the ratio. I’m not sure why the graph is that shape could be to do with the hub interface or slack in the system due to wear or both. With the reconfigured way I’m now calculating the servo position this can easily be compensated for in the code.
After some spreadsheet work I got these graphs of servo position against speed. The ideal is with minimal load and the other from real world data. With this is plotted the calculated servo position in normal and city mode. Neither of them are very good over the entire speed range. City mode shifts the ratio high early for acceleration. Normal mode is about right at low speed and at a higher speed but in-between its not so accurate.![[Image: Qrxh1I.jpg]](http://imageshack.com/a/img924/5343/Qrxh1I.jpg)
![[Image: EArwDI.jpg]](http://imageshack.com/a/img922/6003/EArwDI.jpg)
What I found was that changing the multiplier instead of the offset works much better at calculating the correct servo position for each cadence setting. The other great thing about it is that cadence correction works far better changing the multiplier instead of an offset. This is because an offset has the most effect when speed is low which is when things happen quicker and oscillations can start. Changing the multiplier means it applies more correction the higher the speed and has very little affect at low speeds. This means a simpler code and smoother operation as I’ve been able to got rid of the 7 second delay. I need to upload the latest version of the code as the last upload only includes the beginnings of this new method of calculation.
I experimented briefly with an offset that responds to acceleration but so far it hasn't been much success. The idea was to get rid of the different modes like city if it can tell the difference between acceleration and going slow up a hill.
Whilst I have the ability to log the servos exact position I thought it would be interesting to got a accurate estimation of ratio against servo position. Its a different thing measuring it out on the road when the hub is under load. The graph shows that the ratio is lower than expected but this is probably due to how the hub interface is installed. If I took it off and moved it round by a notch I could increase the ratio. I’m not sure why the graph is that shape could be to do with the hub interface or slack in the system due to wear or both. With the reconfigured way I’m now calculating the servo position this can easily be compensated for in the code.
After some spreadsheet work I got these graphs of servo position against speed. The ideal is with minimal load and the other from real world data. With this is plotted the calculated servo position in normal and city mode. Neither of them are very good over the entire speed range. City mode shifts the ratio high early for acceleration. Normal mode is about right at low speed and at a higher speed but in-between its not so accurate.
What I found was that changing the multiplier instead of the offset works much better at calculating the correct servo position for each cadence setting. The other great thing about it is that cadence correction works far better changing the multiplier instead of an offset. This is because an offset has the most effect when speed is low which is when things happen quicker and oscillations can start. Changing the multiplier means it applies more correction the higher the speed and has very little affect at low speeds. This means a simpler code and smoother operation as I’ve been able to got rid of the 7 second delay. I need to upload the latest version of the code as the last upload only includes the beginnings of this new method of calculation.
I experimented briefly with an offset that responds to acceleration but so far it hasn't been much success. The idea was to get rid of the different modes like city if it can tell the difference between acceleration and going slow up a hill.
- Oran