While Disabling S_PID_ALLOW_BRAKING might stop the VESC from applying a braking current to stay below the MAX ERPM, it introduces this issue it seems: https://vesc-project.com/comment/1594#comment-1594
Problem here is that the PID controller isn’t involved because the limit is max ERPM and not the PID speed.
Both wheels work independent when it comes to max speed.
To solve the problem they would need the information about the other controllers
speed to adjust itself compared to the average speed of all motors.
Sounds doable for 2 motors but will get tricky for more motors like 4wd. And without a PID it could result in a jerky ride when one of the wheels slip because each motors speed influences the power output of all other motors instantly. A max offset might help in that case.
Definitely a interesting topic
There’s also the issue of carving being picked up as DECELERATING…
I’ll have to see into this later. Hopefully my subconscious mind thinks of something. I not then maybe I should only enter the DECELERATE stage upon the timer expiring. By doing this I at least don’t have to worry about about carving , uphills, or downhills caring a deceleration
Will the deceleration section be a linear reduction in erpm or will it start to decay slowly then get quicker?
I’m thinking that a linear reduction you can set in erpm/second is probably easiest to implement.
Thinking about the speed control PID loop here, D is derivative which reacts to the rate of change of feedback relative to the set point.
My thinking is that if you start to go down a hill this is very gradual, you will be above the target speed but the integral will build up and slow you down to maintain the set speed. At no point here should there be a large delta between the current erpm and the set point.
Now if you push the board there will be a sudden jump in erpm without time for the integral to react. In this case you will see a spike in the derivative. Maybe crossing a threshold on the derivative could be used to detect a push rather than just an increase in erpm.
Lol I literally had a Draft post debating if I should do this. But I think your right. Mellow’s implementation doesn’t seem to care about outside forces trying to stop the board other than the brakes, so this implementation shouldn’t either KISS.
I was going to set it at their rate (30 RPM/s) and the tweak it based on how it felt from there. My brain is fried right now but I think this is a linear reduction right?
I’m going to have to get back to this in the morning (or Wednesday, I’m a little behind in some other work) but that seems to be what @Deodand (hope it’s the same Jeff) was implying here right?: https://vesc-project.com/comment/2158#comment-2158
The key here is oing to be properly tuning the PID controller for speed. You are going to need a damped speed controller that has no overshoot in order to achieve what you want. Increasing the derivative term or decreasing the P and I terms will achieve this.
Jeff
What I’m getting the feeling is your proposal will have us do something similar to app_balance.c which messes with the control terms independently. In our case we would be detecting a push by creating a set value (the threshold you mentioned) and comparing that the current derivative?
(which is longer terms is just comparing the last proportional to the current one and if it’s big enough, we have a push?)
Thank you so much man. Your past two post connected something in my mind and allowed me to understand this much better:
I think I have a better understanding of what needs to be done.
For Morning me:
Replace any detection dependent on if the sampling Accel changes in RPM to detection based on if PID’s derivative passes an value
Look at app_balance.c to see how they’re dealing with the PID values. See if you can implement @Deodand’s idea of
[recording] the input output data [of a quick test ride] in the app and use this to characterize the system. From there it would select an appropriate/efficiemt speed controller for the endless ride feature.
I want to stay away from the need of extra components for the time being until it’s absolutely necessary. Shit I wish @Lee_Wright did a mellow break down to make sure they’re not using some sort of accelerometer to pull it off.
The very worst case is this feature will only support the VESC 6, Unity and StormCore since they have populated 3-axis accelerometer and 3-axis gyro (which is used really nicely in the VESCT TOOL Logging from what I’ve seen).
After doing so stalking (just went to the old forum and see which GitHub he forked I found this:
His explanation of how it works for future reference:
Seems like he made some strides towards endless mode recently:
Endless ride - when remote is off and speed is over 12 km/h for 3 seconds,
cruise control will be activated when speed drops below 12 km/h.
Slide the board backwards while standing on it or foot brake
to produce a spike in the current and stop the board.
It’s a nice implementation of the timed cruise control concept me and @Brenternet where thinking of earlier. Any thoughts on his implementation? Auto Braking should only occur in the PUSHING state that can only be entered into if the current speed is past a certain RPM. If it’s within an okay region (past the pushing state threshold but under the pushing state speed limit) and the throttle aint being messed with, then the ENDLESS MODE state will start its timed cruise control. After a certain amount of time passes (or if the throttle is messed with) it will enter the Coasting state until it reaches back under the pushing speed threshold.
One thing though is I don’t get how a user will be able to push during the coasting state. It seems that the user will have to wait until the Coasting state goes back to the normal state to have their pushing accepted. Also instead of pulling back the speed to the max push speed, it opts for braking, which I guess can work if you set a high enough limit but can get annoying if the limit is low and brakes while you’re trying to push on flat land.
For me, it comes down to how it handles 5 scenarios:
cruising flat ground
going up a hill
going down a hill
braking
pushing
From my understanding of mellow videos, descriptions, and feedback:
mellow reaches pushing speed (not sure if there is max it sets, maybe 25 kmh?) and slows you down after about a minute (timeout) at a rate of 30 revolutions per second. I’m not sure if I’d rather it actively slow me down gradually or just let friction slow me down like a manual board would.
no clue how they do uphills. Not sure if they maintain speed up an incline or if it slows your roll.
It appears mellow handles down hill by setting that as the new kick push coasting speed (4:30 in the mellow mode video). Seems sketchy if you downhill too fast but I’m cool with that because you have the remote ultimately for braking.
remote brakes for you as it should and cancels cruise mode. Still questioning why they intentionally slow you down instead of free coasting to a stop.
pushing resets the set cruise speed. I don’t know if it has any cool down period for reactivation. I don’t think it does since they mention going downhill will hold your speed.
Electric kick boost ftw. Glad to see this brainstorming continuing
Might be a dumb idea, but coupled to an inclinometer maybe all we need to differentiate a push from a incline.
Any sudden acceleration (=> motor rpm increase) without incline change could be interpreted as a push.
It might be fun to have an endless mode that handle the same given any incline. (maybe except for the auto slowdown on downhill, but sill, top speed handled by how fast you can push it)
Yeah I think it’s due to how priced the mellow board was + it’s delays, issues, and then unable to break into the US market even with it’s “cheaper” (non waterproofed software locked) Mellow S Drive. Had it priced at $500, have bigger sleeve options, and still had it’s Mellow USA Branch, I think it would have done well in this post-Boosted time with the Wowgo 3x being it’s biggest competitor price wise.
That’s very interesting that he feels like there is no cruise control at all. Video dude explicitly says it holds your speed for about a minute before the deceleration
. Really appreciate your efforts
