Posts: 2,182
Threads: 20
Joined: Jun 2016
Reputation:
64
I"m looking at integrating these changes but a few basic impressions:
1) Using AnalogWrite instead of hardware or timer isr pwm. Doesn't this give a much lower and audible working frequency?
2) Using steinhart temp sensing... Does this make significantly more accurate readings? Isn't the use of software floaing point functions like log too expensive here?
3) watchdog... the protocol doesn't care if the arduino resets
4) adc filtering and not using adc isr is going to give less utilization of the adc and therefore lower sampling accuracy
Posts: 44
Threads: 6
Joined: Nov 2019
Reputation:
4
2020-02-06, 06:54 PM
(This post was last modified: 2020-02-06, 06:59 PM by McNugget.)
Hey guys,
Ues, I can hear my servo clearly. However, for me it’s more like a notification that it still works rather than an annoyance. 1khz is definitely in the audible range! However, this makes using all the other standard libraries possible. For a sail boat this might still be too loud, depending on your setup.
Steinert seems to be pretty expensive, yes. I eye balled the milliseconds per cycle in my first experiments and realized that Steinert causes an overrun such that I was forced to increase the loop time. I implemented Steinert only because that’s what I knew was working with the temp sensors I had sitting around. I bought them for a different project. Plus, I didn’t understand your code completely with respect to which value to change when using different resistances than yours. Having said that, I tested both algorithms and they seem to come to very similar results. So if you could confirm what values to change in your code, we can continue to use your temp code.
Watchdog: Yeah, I just don’t like seeing my uC resetting with me not knowing why. That’s all.
ADC filtering is good here because it untangles the code and it’s a simple fix for potentially noisy signals. Each channel has it’s own filter coefficient.
Yes, I’m running at 97% flash. That’s kinda insane and I haven’t found a good reason why, so far. Commenting the display out, doesn’t help. So it should be something else.
A huge optimization would be to implement Steinert or anything else computationally expensive using a lookup table. That would eliminate most computations. We just need to provide a script that spits put the lookup table for any given sensor and hardware implementation. ADC to temperature mapping is that a matter of a linear scale between two of the LUT values
Posts: 2,182
Threads: 20
Joined: Jun 2016
Reputation:
64
My version of the temperature calculation is fairly accurate and uses only integer math so it's faster and smaller.
If you don't run adc off the isr, you won't get the same resolution of measurements because there are less samples to average.
I suggest that in a potential merge we keep the above with both versions using #define ?
Posts: 44
Threads: 6
Joined: Nov 2019
Reputation:
4
2020-02-07, 05:26 PM
(This post was last modified: 2020-02-07, 05:34 PM by McNugget.)
Can we debate the reason for the accuracy for a moment?
This was part of my confusion when trying to understand how you structured the code and your design decisions.
I really don’t see the need for this accuracy when measuring temperatures between 0 (freezing and may cause issues with lubrication) and 80 (motor and h-bridge burning hot and should be shut off immediately). Why is accuracy a concern? The reason for the measurement is added safety. Not a laboratory test. My current, naive implementation has about 0.5C - 1C resolution (from my memory, but even at +-2C it shouldn't be an issue). For the above use case that seems plenty to me.
What are your thoughts?
Posts: 2,182
Threads: 20
Joined: Jun 2016
Reputation:
64
2020-02-08, 09:03 PM
(This post was last modified: 2020-02-08, 09:14 PM by seandepagnier.)
The accuracy for temperature is not important. Voltage is not so important. The accuracy for current and rudder feedback matters a lot more. To give fast reactions to over current with noisy data. Also better resolution will improve the learning pilot since it uses these signals for training. For the regular pilot the accuracy is less important since it only uses rudder and current feedback for end stops, but better resolution can trigger over current at lower currents more reliably which stresses the drive less.
So basically if you have end of travel switches or rudder feedback with the regular pilot it won't really matter at this stage.
Posts: 44
Threads: 6
Joined: Nov 2019
Reputation:
4
2020-02-11, 11:34 PM
(This post was last modified: 2020-02-11, 11:36 PM by McNugget.)
I understand your point. Have you done some studies to verify the improved precision (my guess is 1.5bits or so) actually makes a difference?
I’m reading my rudder through a simple potentiometer. The cable is unshielded and about 4 meters long until it is plugged into the motor controller. The H-Bridge is next to the motor controller and the cable is very short.
I definitely see a decrease in signal quality on my rudder sensor signal based on the cable alone. But not nearly bad enough that I would consider the signal too noisy, especially after I added a bit of filtering on the controller side.
Currently, Pypilot moves the rudder about every seven seconds. I would like to decrease that time to about 1-2 seconds for my power boat or tune it to the right value I need.
It’a just my feeling and I don’t have enough empirical data but I don’t think it’s worth the hassle, not even for the current measurement.
I much rather make the code smarter to react for the pypilot instead of waiting for the pilot to tell me to stop steering.
I would concentrate on: Complete sanity checking of commands vs current controller state as well as smarter responses when hitting predefined software endstops.
