Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Attempt at cheap homemade version of Harmony
#41
Hi Michael
Great to have an update I was wondering how you were getting on. So you’ve finally been able to bring Arduino, Android app and NuVinci hub together. I remember how exciting it was when I uploaded the first automatic shifting code and the first test ride. I’d been riding the bike for weeks before using the potentiometer to shift manually. Interesting to see photos off your setup and the smartphone app. The up and down buttons I assume are for increasing and decreasing cadence. I’ve yet to explore the world of app design. You're using this instead of a potentiometer like I have? Like the old bike with all the electronics, its the way I like to do things as well.

I like the challenge of making things reliable, its often more difficult than making something that works but doesn't last. I want it to be as reliable as a manual cable shifter. I need two Arduinos due to the number of timers and they are connected in parallel so thought redundancy would be a nice feature but have yet to write the code.

My goal is constant cadence in that I want it to as closely as possible maintain the cadence that I ask it to. Obviously the ideal cadence depends on power output. For me automatic adjustment of cadence depending on power is a challenge for the future as it is the ultimate automatic shifter. I find that on longer distance rides maintaining a fairly constant power output is a nice, efficient way to ride but it relies on the cadence being maintained with high accuracy. I think I’ve maybe become ultra sensitive to cadence due to years of CVT riding, ±5 rpm makes me feel like I’m in the wrong ratio.

I’ve now learnt that the different modes I created were really just compensating for it not being able to maintain a cadence with sufficient accuracy. The hilly road one for example helped it to down shift as the bike slowed on hills. I could now in theory have the quick shifting of city mode and sufficient down shifting on steep hills because the cadence correction would keep it right.

Monitoring the servo was something I had considered as well, comparing the set position to the actual position but never went any further with it. I was concerned about over stressing the servo and reducing its life. When it comes to forcing the hub to shift and doing damage I’m not aware of any evidence this happens. However it is worth considering such things and will be interesting to hear about your results from monitoring the servo. Its obviously true that a hub will only shift through half of it’s range when the wheel is stationary. I did have a hub that would stick when down shifting even when the bike was still moving, up shifting a bit would unstick it.

What I find with the auto shifting is the however hard I brake the servo still has enough time to shift the hub more than half way. Once its done that if the bike has stopped it can still complete the shift into full underdrive. That works because the servo position is mostly determined by the speed. There’s only one situation I’m aware of when the servo has been unable to shift to were it’s been told to. That was when the reed switch code would give a high value due to the magnet stopping next to the switch. A modification to the code has removed this problem.

The times when the servo is under most stress and likely to lag is when the hub is under a lot of torque and shifting is required. Most noticeably during the initial part of hard acceleration from a stop and during a change of speed when climbing a steep hill slowly. I chose a high torque (20kg/ cm) servo because I wanted it to keep up during acceleration. So far after 2500 miles I’m not aware of any damage to the hub due to this. Damage I am aware of and I’ve done it to another hub as well years ago is a slight roughness in underdrive. I think its due to too high a torque when the hub is stationary and the resulting slippage. I have a habit of starting acceleration with the front wheel almost off the ground.

Nice to hear you’re starting to enjoy the benefits of automatic shifting. I think riding around town with traffic lights and junctions is when auto shifting is most useful. Although I enjoy mine most riding in the country side on quiet roads and not too hilly.
- Oran
Répondre
#42
The nano data logger shield has arrived, it works OK apart from the I2C pins for communication with the real time clock. However designed the circuit board thought that digital pins 4 and 5 were SDA & SCL instead of analog 4 & 5. There is a software fix for this but at the moment a couple of wire links fixes it for now. I can’t really complain when it only cost a couple of pounds. A few years ago I would have considered spending £150 for a logger to do the same thing.

I’ve just about fixed the oscillation problem with the cadence correction. I did a recalculation of the amount of offset applied per rpm of cadence error. Discovered that it was out by quite a bit, should have been a multiplier of 17 instead of 28. If the cadence was 10 rpm to low it would provide the equivalent of plus 16 rpm of correction. That would take it to a cadence of about 5 rpm too high and a correction of minis 8 would result. However I’ve also proved that my incorrect multiplier turns out to provide by far the most accurate cadence. This is because at small cadence errors the correction slightly overshoots the 0, for example an error of 1rpm results in a correction of 1.7 rpm. This must be counteracting for things like cable slack.

What I needed was an offset represented by a curve as the multiplier needs to decrease with increasing error in cadence values. After some experimenting with numbers it turned out that part of a sine wave can create this curve. The offset equation now looks like this offSet = (sin((Cadence - 68)*0.15))*170

[Image: jJVYis.jpg][Image: 5TM2Gw.jpg]

Next is to get the I2C communication sorted between the two Arduinos and the RTC on the data logger. At the moment Arduino 1 the master and servo controller requests just the cadence value from Arduino 2 the slave. Arduino 2 is also communicating via I2C to the RTC. Sometimes there is an error in the clock value which I think its due to a clash in the communications on the I2C wires. I want Arduino 1 to get the most up to date cadence value when it needs it. I also want some values sent from Arduino 1 to Arduino 2 for data logging. So which one should be master and which one the slave that’s the next puzzle. There’s also the back up servo control code on Arduino 2 so that it reverts to this if Arduino 1 failed.
- Oran
Répondre
#43
Whilst I've been back home on the island and had my own workshop I thought I would make the original shifter electronic. I didn't wan't to try and fit a potentiometer into the shifter itself as combining two parts that could need replacing isn't ideal. I also had a load of reasonable quality audio slide pots I got for free. Would rather use them than a tiny pot squeezed into the shifter. I'd considered buttons but decided waterproofing them could be a challenge and I like the robustness of a standard shifter.


Next challenge was applying a pull to the cable to simulate the derailleur and so the shifter works correctly. Taking up 27mm of pull with a spring without a massive change in tension wasn't easy. I eventually choose a chain tensioner spring off an old derailleur. Its got a good length spring, the change in tension is noticeable but not a problem.

[Image: G3F0hS.jpg] A radius of 17mm gives a 90° rotation on the derailleur spring.


The slide pot has a length of 60mm which is a common size. I was going to amplify the cable pull to make full use of this. However it was far simpler to make a cable grip and fit the pot in parallel to the cable. With a total of 1023 values for the full 60mm length it still works out at 60 between each shifter position when using just half the length. Its also nice to have spare room at each end.

[Image: 7PYOfu.jpg] The cable grip which fits the potentiometer on right of pic.

The code writing for it required a little bit of thought. I wanted to include some deadband as the shifter overshoots a bit although once shifted it settles to a pretty consistent value. Too much deadband made the range per cadence settings so small it would sometimes get missed. A deadband of 10 seems to be about right with a range of 60 between each setting.

[Image: x92ffm.jpg]

Its big and heavy for what it does but should be reliable and easy to fix. As it can be used with any type of shifter that pulls a cable making any bike automatic is a bit easier, could be useful. Its an experiment to see if there is a use for such a thing.
- Oran
Répondre
#44
[Image: MGDjlD.jpg]
The cable to electronic shifter is working very nicely and makes a big difference being able to easily and predictably choose the correct cadence. With 9 settings I have chosen 50, 60, 65, 68, 72, 75, 80, 90 and 100rpm.

[Image: xi7SRN.jpg]

This is a graph of the frequency of potentiometer positions provided by the indexing on the shifter. The code is looking for a range of values including a deadband. As well as this the shifters indexing ensures the values are well within the range and the result is a very reliable electronic shifter.

Whilst I was writing the code I couldn't resist putting in a manual or stimulated derailleur mode. I calculated the servo positions for the ratios of a 9 speed 12 - 36t cassette. Very nice having what feels like derailleur gears but without the possibility of messing up a gear shift. However I soon get bored of shifting gear when I know its perfectly capable of doing it by itself and without the steps in ratio.

The following graphs are logs of the same length of road done once with the simulated gears and again with automatic shifting. The difference in cadence is very noticeable and the amount of shifting necessary when using gears.

[Image: SEToip.jpg]
[Image: ipBK06.jpg]
[Image: J1D7xa.jpg]


Adding automatic cadence adaptation to power output, the next challenge.

This homemade power meter http://www.instructables.com/id/Homemade...owermeter/ was mentioned on the GCN show and apparently costs $55. Its based around 2 Arduino Nano's so can't resist having a go at making something similar when I have time. If I could get a measurement of the amount of torque I could feed this into the servo position equation. The result would be the ultimate automatic shifter as it could alter cadence depending on power output. The shifter could then became a selector for the amount of pressure I want to apply to the pedals. That is where it would have to stop as getting it to read my mind is a step too far for me at the moment.
- Oran
Répondre
#45
Attached are the 2 Arduino codes. I couldn't attach ino files but pretty sure if the file extension is changed back to .ino they should open with Arduino IDE.

I've been a little reluctant to post the Arduino code because its been constantly evolving as I make improvements and find mistakes. I know very little about coding and know there will be a better way of writing it. Anyone's welcome to use it but I would suggest making you own modifications to it to make it suitable for your situation.

I currently use two Arduino's the second was at first for data logging but has now become the cadence measuring Arduino as well. Arduino 2 is not really necessary as the cadence measurement only helps to improve the accuracy. Data logging can be done via the Bluetooth connected to Arduino 1. You my not even want data logging I find it useful for developing the code.

The code of Arduino 1 can be simplified considerably. I'm considering getting rid of the mode selection by Bluetooth but it could be used for cadence selection instead. If you have a favourite cadence then there isn't a need for the shifter either. Or you could just use a simple switch instead for two settings.
The servo control is done by timer2 because at the time I didn't know how to make the reed switch timer code work on timer2. I now have a reed switch timer code working on timer2 on Arduino 2 which could be adapted to calculate wheel. This would allow the servo library to be used.

The I2C needs to be able to transfer more values to Arduino 2 so I can free up one of the timers for a back up servo control code. Always more to be done but at the moment the basics of this code works very well.


Pièces jointes
.txt   Arduino1_Code_V6.4.1.txt (Taille : 23.85 Ko / Téléchargements : 14)
.txt   Arduino2_Code_V6.4.1.txt (Taille : 8.37 Ko / Téléchargements : 11)
- Oran
Répondre
#46
Had a few issues recently with my N380 its done over 3000 miles about the distance most hubs start to give me trouble. I noticed a bit of play in the wheel and an oil leak. I investigated the bearings which are all fine just the small driveside one is slack on the axle. The leak seems to have been significantly reduced by simply cleaning the seal to remove any particles. Of more concern was a noticeable increase in the amount of rotation of the shift driver. It's about another 1cm of cable pull to get the full range. I tracked down the problem to badly worn plastic bushings supporting the eccentric gears. Easy to replace with unworn ones from another old hub and no other wear has occurred on the shifter mechanism so its back to normal.

The question is why are they so worn out. I'm using considerably less torque than Fallbrooks own Harmony can generate. Too much torque from the pedals in overdrive is a possible culprit. The real question is what's different about the N380. Since I started writing this I've done a few hundred miles and the hub has settled back into normal operation, oil leak has stopped.

Thinking about servo torque reminded me of what Michael said about monitoring servo position and comparing it to set position to avoid overstressing anything. I realized that the servo already has a potentiometer built in so its just a case of connecting the Arduino to it and monitoring the voltage. Now I know my servo is under specified on torque I'm more interested in finding out when the servo is unable to shift. Its always struggled to keep up with shifting during rapid acceleration, I would like to find out how much is the Arduino updating too slowly and how much is insufficient servo torque.

[Image: PVBMhf.jpg]
Example of data logged showing proof that the fault was code based and wasn't the servo being unable to shift.

According to the data I have logged it seems like the servo is perfectly capable of keeping up with the shifting. However a new problem started to develop. I was beginning to notice that the there were times when it wasn't shifting. A study of the data revealed that it was not the servo to blame but the code freezing up. I started to blame the I2C communication I'd set up to transfer the servo position from Arduino 1 to Arduino 2. I reverted back to an earlier version of the code and no difference, tried manual mode and it was unreliable at shifting. I began to notice a pattern and that the shifter had something to do with it. Turns out that during use the cable had lost its adjustment by about half the length of the distance between settings. The result is that it was falling in the deadband and due to the lack of an else statement it didn't know what to do. The else is simply a mid range cadence with a 0 for the setting so I can see it in the data. I'm sure its possible to write some code that would automatically adapt to the cable adjustment.

I was going to investigate the oscillation occurring with cadence correction in more depth and look at a PID (Proportional-Integral-Derivative) function. I had this interesting oscillation during a 6 minute hill climb. However now I have discovered how much slack there was on the shifter and there hasn't been any significant oscillation since I would mostly blame it on that.

[Image: SoNxyR.jpg]
- Oran
Répondre
#47
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]

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]
[Image: 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.
- Oran
Répondre
#48
At the moment I’m delaying uploading any updated code as I’m now aware of how worn out my hub really is and how I’ve adapted the code to compensate. I’m unable to continue perfecting the code with the shifting from underdrive being so unpredictable.

I’ve been struggling to rid of a big lag in upshifting during acceleration and sometimes a ratio that is too low on slow hill climbs. There’s a very noticeable period just as the ratio suddenly increases when the hub feels very squishy during this transition. Like it’s trying to get to a higher ratio but doesn’t quite manage it and oscillates under the load until the servo shifts up enough. There have been times when I’ve felt like I’m getting stuck at about 10 – 12 mph. My cadence goes so high I can’t get the power to make the bike speed up enough to get the servo shift up for the hub to engage in a proper up shift.


[Image: Zk9WKe.jpg]

(Changed the graph as I logged some more data without a delay on the servo position this time. Also recorded speed to 2 decimal places instead of an integer.)

As I’m data logging the servos real position via its internal potentiometer and the hubs ratio, calculatable from speed and cadence, I analyzed some of the data to see what’s going on. The graph proved exactly what I’m experiencing, an inability of the hub to shift into a higher ratio despite the servo being in the correct position. From what I can tell it seems that the problem occurs when the hub is under load and upshifting.

When I think about it the problem has occurred after changing the plastic bushings on the eccentric gears. Worn bushings increased the amount of travel on the shifter to got the full range. The worn stator has the opposite affect all the shifting is occurring in two thirds of the available range. In a way I’d be better off with the worn bushings as the two types of wear cancel each other out. Maybe its time to ask for another hub.
- Oran
Répondre
#49
I am a neophyte.

I remember a year ago when Normand tried to educate and help me understand the PID . Ouf poor guy... he is patient, let me tell you this. (For an number of other reasons...)

He was quoting Ziegler-Nichols method as it is easy to understand and showed me a graph of a typical curve. I know on my old bicycle I need to overshoot to change gear. Cable rub/strech, worn out bushing etc...

Thanks for sharing.
[Image: 115771155117.png]
Répondre
#50
I have a question;

Have you think going on stmicro or else (silab,etc) chip instead of atmega. I am thinking of the F1 series with a SPI bus. They have 4 lane.


One of my friend suggest I should invest time in C and C++... I couldn't agree more.
[Image: 115771155117.png]
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)