Push and then maybe the board detects a push by via comparing the derivative to a derivative threshold like @ducktaperules said earlier and if so then adjust the pid_rpm to assist the user.
If the board reaches a certain RPM then it will decelerate for a longer than usual time (the 1 minute).
Illustration Of what I think is happnening according to him (someone correct me if I’m wrong):
I think the best means of seeing if it’s the way the video is describing or Kevin’s description is by having someone test Endless Mode on an hill or incline.
If the board tries to accelerate on a hill then that means that endless Mode is, at the very least, implementing Cruise Control using PID Control
If the board doesn’t accelerate but instead decelerates then at the very least cruise control is not acting here since CC via PID Control would try to accelerate the board on a hill in order to keep the set speed by a push.
Another way could by to push the board and the pick it up and see if the RPM runs at weird speed (my line of thinking here is that a decelerating system will noticeably decelerating while a system using a timed cruise control will noticeably change it’s RPM’s to hold the set speed AND THEN decelerate.
Maybe rather than working out what mellow are doing we could work out what’s best?
I think adding the constant erpm section makes sense if it’s configurable. Setting to 0 would easily disable this if the user does not want this behaviour.
Because this code is really in development (I mean it works, but I’m a little lazy with cleaning up), this is an old comment from DroidSector. He made a truly ‘endless’ mode for when your remote battery is dead, but my opinion is that it’s totally unsade to ride without full control of your brakes.
So I made it like you quoted me from that other topic. (Somewhat) All values for speed and time are configurable, this just makes it that you have to do some pushing, you will cruise control for a bit and then slow down till below the pushing speed and then you push again.
I really like your drawing btw! Let me add some things
Autobrakes on a max speed, are gonna go, as you can brake with your remote.
You have to set the mode to Push Assist, this changes some command behaviour, first off, if you pull the throttle up (so above default_throttle), it will programmatically stay in the default position. Second, SET_CRUISE is sent to verify for the board that the user is pressing the kill switch (which you only need to press to START, you don’t have to keep pressing once you are in Cruise Control)
So, just to be clear, you can’t get power to the motors other than for braking and CC in Push mode.
If the throttle moves below default (<127) then it goes back to normal mode and you can brake.
Important: Both remote and board have to know which mode is active, this is sent with each acknowledgement packet.
You are right about that last thing. Pushing isn’t accepted in the coasting state and only when your speed has dropped below your pushing speed (the activation speed), the state will go back to normal and you can then push again. Straight out of pushing would also be possible.
Now here comes the fun idea (that I didn’t do yet):
Currently, I use ADC + UART for this remote (UART only is also possible, but I use an UART splitter and then that ain’t safe), with ADC on the VESC, ADC1 acts as throttle input and the servo signal pin as a cruise control switch. This means I have the exact same functionality as with UART only.
My idea was, what if I apply a quickly switching ON/OFF signal to the cruise control (servo) pin of the VESC, while in push mode. Something like PWM, but with a way lower frequency. In theory, that would mean that cc is for example off for 40% of the time, and it should lower it’s speed, but also give the possibility to kick and get a higher speed, as it’s continually updating it’s PID speed control speed.
Thing is, @Brenternet did offer me a shitty 4.12 to test, but I only have one board (my precious Evo) which is now equipped with a og FOCBOX, and I don’t feel like changing the speed controller there because it’s all really tight and soldered to the anti-spark. But I am also NOT testing this with my og FOCBOX, because I don’t know what the hell will happen in practice.
Now seeing the way mellow does it. It would actually be possible (with UART only) to first go into cruise control with a constant speed, and then go into coasting where we apply a little less current than cruise needed, but that doesn’t sound very safe, with hills and all.
Why the need for it apply slightly less current? Would free roll (no current) in coasting mode suffice? I feel it would be more natural, especially on hills.
There may be a jolt effect at cruise control time out though so maybe a quick/smooth ramp down of current to 0.
AH I was confused when I saw that yet the codebase ensured that a remote connection was needed to stay in the mode.
Any thoughts on using app_nunchuk’s Cruise Control? It seems like a better implementation then ADC since it ensures that the previous current from the PID Control Loop is saved for the ramping time calc. I haven’t tested it out but it seems better than ADC’s implementation.
Got anyway you can illustrate this I’m a bit of a visual learner and having a hard time understanding what this changes. Are you going to implement another PID control when cruise control is disengaged?
Right now I’m still trying to see the REAL way Mellow does it (thought can’t until someone test it out for me). Right now it seems the common conception is that Mellow’s implementation is what you’re describing: Timed Cruise Control Triggered By User Push As Input/Trigger
What the guy I was conversing with in the screenshots above seems to be indicating is that this is not the case and instead it’s more so: You give a push as an input and the motors will help in kind, which sounds like to me a similar to Pedal Assist PAS (Though for us it would be called (True) Push Assist). If it’s like the latter though, I’m not seeing a way, in my limited capabilities, for VESC’s to do this.
Moreso, I don’t know how a user push can translate to input speed for PID Control (this is where my weakness in anything beyond immediate visible physics start to fail me). I’m trying to visualize it in my head but maybe I’m not capture it exactly. what would the desired point be from a user push and how would I capture that from a push? It should be: A User Pushes and if that push goes beyond a limit value the motor responds with additional appropriate torque.
Maybe I need to go back to just the basics of Skateboarding Physics and work up from there with the main goal in mind: Can the we detect Torque From a Push without sensors.
But anyway that’s just a part of me thinking of how that kind of Push Assist would work for us. Though it’s looking like sensors might be needed for such an implementation.
For right now I’m still trying to see what exactly kind of mode I want to pursue that works for our use case. The next post will be about compiling all the different "Push Assist’ and Endless Mode deviates I’ve stumbled upon and broke down into one post, evaluate their use case. differences, and implementation and determine which one works best for us.
I believe the nunchink’s cc implementation migrates this by saving the previous current and when PID Control is exited that previous current is still used in the ramping time. At least that’s what I think it does. PPM and ADC doesn’t use it so I’m still investigating why only nunchuck does.
I think free roll does suffice, but many people feel like having the mellow approach (as seen in the video).
It’s used when you set it to UART only mode as that sets the nunchuck values through UART for controlling cruise control and throttle. I didn’t know the cruise control implementation was different, maybe Benjamin forgot to change it?
Well, maybe I should buy an Apple Pencil lol. I tried to illustrate. Time is not equal here for the two graphs of speed and signal, signal should have a lot more on/offs in the time that the speed reduces this amount (like really a lot). My general theory is that, because the cruise control is switched on/off an X amount of times per second (and it is more on than off), it should slow down, because it’s not applying power 100% of the time. You should also be able to kick as it is constantly updating it’s speed, but it’s all theory.
After doing some research, I came across three types of “Push Assist”/Endless Mode: True Push Assist (Motor Assist), Endless Ride ( Mellow’s Implementation), and Times Cruise Control. These “definitions” are what I came to understanding after reading up and asking around. If I have any misconceptions please let me know. I’m still iffy on what Endless Mode truly is.
Motor Assist (True Push Assist):
Upon a “push’ , the board provides proportional power. This is basically Pedal Assist but for boards instead of Pedelecs. This paper was very insightful on the subject. I’m more than likely going to spend my grad thesis on this since I find it the most interesting.
In regards to implementation on the VESC, I’m not seeing a clear way to do this without additional accessories. I’m having issues seeing how the board will be able to determine the appropriate powers to deliver to assist the user. It’s easier on pedal assists since they have sensors and it seems a lot of manufactures have a predetermined constant assistance power. If anyone has any ideas please let me know.
Endless Mode:
Upon a “push” board decelerates at a set rate over a length of time. If the board reaches a certain speed × it decelerates slower than it would at slower speeds.
In regards to implementation, it’s more possible than Motor Assists, but I’m still on the hang up of if this is what Endless Mode actually is. I’m getting answers from Mellow Users that contradict what Mellow say is being done in the video. I need to ask more People but I won’t really know until I have a mellow drive in my hands. It wouldn’t be too wild if what Mellow is doing is actually a combination of both Motor Assist and This which makes me wonder how they;re doing it without sensors.
Timed Cruise Control:
Upon a “push” and the board holds the speed it accelerated to for X seconds and then coast.
In regards to implementation this is the easiest to implementation but I don’t think it’s what we actually want. I feel as though a type of listeners needs to be implemented in case the user pushes during cruise state (or maybe just a check in the cruise state for sudden acceleration).
I believe time cruise control is a nice feature and the most natural one. No extra gear needed. Just push and your board will hold the momentum for you.
Next would be motor assist if you manage to know how to time exactly your push with your boost. Needs refined throttle because you might end up with your board flying without you if you miss.
In comparison, after seeing your definition of endless mode in last post, I don’t see the benefit…
Agreed. I think I’ll tackle this first. Motor Assist can be added to it as a complimentary to it.
Yeah I’m going to read up on some papers on Pedal Assist since they similar features. Does anyone know of any Scooter with Push Assist ? Been searching around but haven’t found any.
For motor assist the biggest hurdles seems to be:
How to determine a setpoint from a “push”
How much power should be delivered to help achieve that set point
One thing I’m thinking is that this is going to need a user config setup since different drivetrain configurations will affect how much power is needed.
The thought of anything decelerating without my input is terrifying. Motor assist or timed cruise control both don’t have that and get my votes.
It comes down to handling of hills and the transitions into and out of them:
Motor Assist
going into a hill - Seems the most natural for pushing on flat ground and hitting an uphill. Hopefully would make a slight hill feel like flat ground pushing.
coming down a hill - might accelerate you a bit more than you’re comfortable with but would free roll out eventually. How does the system differentiate between a push and a downhill though? Derivative of measured velocity would have to be set up very well.
Timed cruise control
going into a hill - Might suck if cruising uphill and cruise control times out. I imagine you’d get a small jerk but better than braking for you.
coming down a hill - wouldn’t accelerate you more downhill. May register downhill speed as new cruise control speed though.
Agreed. While it’s a constant deceleration it’s still worries me a bit. I’ll have to see how -30 RPM/s feels while kick pushing.
Yeah trying to illustrate in my mind how it would work. Going to talk to the context of Timed Cruise Control:
User provides a “push” Input.
If the push input surpasses a set minimum ERPM, the board holds the highest speed caused by the acceleration and a timer is set for X seconds.
During this state, the board watches for sudden acceleration ( that surpasses a set minimum acceleration threshold).
a. If the sudden acceleration occurs, the board enters a “Watch State” where the timer resets and the new speed is held.
After the timer expires, the board enters a coasting state where it watches for sudden acceleration. If the board goes below the set minimum ERPM, then it no longer watches for sudden acceleration.
In the context of the three states of the road:
Flat:
Should work regularly. If it works
Uphill:
During Cruise Control, it should attempt to speed up while on the hill due to PID control. I might be able to differentiate between a kick push and the PID’s acceleration via the derivative part.
If the timer expires on the hill…well then it expires on the hill. You should just coast down like a regular skateboard/longboard/monsterboard/mountatinboard/k00kboard unless you kick push. I’m unsure of how much a user can kick push on a hill or two safe it is. Need more research.
Downhill:
This is…tricky. As far as I can see, there’s no way to differentiate downhill form kick pushing without the use of gyro’s and I’m not sure if all VESC’s have or have accurate gyros. This is why I insist on a user having a remote to brake. The board will just keep accelerating as normal and once you’re not accelerating anymore it’s just going to maintain the speed it acquired due to going downhill.
Motor Assist can be implemented during the standby state if it works well (and be disabled if nearing cutoff to save battery)
Side Note: Please throw scenarios that I’m not thinking of above so I can think of how to deal with them.
You seem stuck on requiring it to be an exact copy of whatever mellow is doing, even though we’re getting feedback from users that the implementation feels different than the video you link.
Would you prefer the board brakes for you? Or what is the hangup with the other modes of control?
Without a mellow board in my hands to do some testing the most I can do is guesswork. Especially since I’m getting some people saying it’s not like in the video and others saying it’s exactly like in the video.
Right now timed cruise control is the closest to what’s being described , with motor assists just being a backdrop.
Oh wow I can’t believe in all of my wall of text I didn’t make this correction , yeah not a check box but instead a control type. Only thing I don’t like is that I have to implement it to each relevant application.
I’m a bit of a visual learner and having a hard time understanding what this changes. Are you going to implement another PID control when cruise control is disengaged?
