search

emmebrusa / TSDZ2-Smart-EBike-1

TSDZ2 Open Source Firmware adapted to VLCD5-VLCD6-XH18 displays
GNU General Public License v3.0
131 stars 35 forks source link

Speed limit not controlled smoothly #71

Open dzid26 opened 11 months ago

dzid26 commented 11 months ago

My impression is that ui16_wheel_speed_x10 changes slowly and one of the side effects is that 25kph speed limit control is not smooth around the limit. (Especially with Field Weakening enabled)

Additionally, after coming to a stop the old speed is stored for a 1s (judged based on the display), instead of decaying with the procession of time.
This causes interpolations to calculate inappropriate values during that time.

dzid26 commented 11 months ago

Additionally, impressive high numbers can be observed when the sensor is overlapping the magnet at a standstill.

I replaced the magic values with a calculation:

// Wheel speed sensor
#define MAX_PLAUSIBLE_WHEEL_SPEED                               80U
#define MIN_PLAUSIBLE_WHEEL_SPEED                               4U
#define WHEEL_SPEED_SENSOR_TICKS_COUNTER_MAX                    ((uint16_t)((uint32_t)WHEEL_PERIMETER * (HSE_VALUE / 420 /2) / MAX_PLAUSIBLE_WHEEL_SPEED * 60 / 1000 * 60 / 1000))
#define WHEEL_SPEED_SENSOR_TICKS_COUNTER_MIN                    ((uint16_t)((uint32_t)WHEEL_PERIMETER * (HSE_VALUE / 420 /2) / MIN_PLAUSIBLE_WHEEL_SPEED * 60 / 1000 * 60 / 1000))

So that evaluates to 1774 and 35485 respectively (for 26" wheel). This is more proper, but of course that is not solving the issue.

emmebrusa commented 11 months ago

The update time of ui16_wheel_speed_x10, is the time the wheel completes one revolution. The min and max limits are already defined for ui16_wheel_speed_sensor_ticks: WHEEL_SPEED_SENSOR_TICKS_COUNTER_MAX WHEEL_SPEED_SENSOR_TICKS_COUNTER_MIN

dzid26 commented 10 months ago

So that's 300ms update time at 25kph. 2.050/(25*1000/60/60). So it's relatively slow to react for speed changes.

I think it will be better if speed started to automatically decay according to v=∆s/∆t if upcoming tick ∆t is larger than previous one.

I will see if I can improve it.

dzid26 commented 8 months ago

24fe1ba makes the torque ramping around the speed limit smoother, since that speed jumps a little less and so when speed drops the torque is applied sooner and gradually.

Maybe adding a rate limit on torque changes would eliminate any leftover jerk. It could also eliminate a feeling of sudden load when accelerating through the speed limit.

emmebrusa commented 8 months ago

I resumed development after the summer break, but the priority is for the 860C, the version for standard displays will then follow, with all your suggestions.

dzid26 commented 8 months ago

I resumed development after the summer break, but the priority is for the 860C, the version for standard displays will then follow, with all your suggestions.

Wouldn't be worth it to spend some effort on merging two repositores? How hard can it be :)

emmebrusa commented 8 months ago

Before doing the merge I would like to try, the problem is that on the bike I use I have 860C, I have to change the display. Don't think of it as neglect, I will definitely do it soon.

dzid26 commented 8 months ago

That's fine. :) However, I was asking if it would be viable to unite 860C and VLCDx codebases.

emmebrusa commented 8 months ago

My versions have a common basis regarding the motor and torque sensor code, v20beta1 from buba/casainho. I then tried to integrate some very interesting changes, developed by mspider65. The intention was to keep the two versions aligned, stock display and 860C, at least as regards the motor code and torque sensor. Unfortunately, there were some problems with the version for standard displays (burnt MOSFETs). That's why the two versions are very different. This is the situation:

So first job I have to complete the version for 860C, then understand why the MOSFETs burn in the stock versions > v2.