No thank you. Nor a pressure pad or a foot button, or remote deletion or a flux capacitor. Let’s not go full circle please.
6 Likes
i think @Jamie42 created almost the perfect mode, dont know if he shared it or something though.
3 Likes
woah woah woah… the VX1 has cruise control???
2 Likes
yep!
tiny bit of power on CC goes a long way.
1 Like
5 Likes
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:
From. quick glance , I’m unsure
and it works like so:
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.
From looking at this receiver.cpp file he takes any speed above 23km/h as downhill
and applies a braking force of 127 / 5 * 0.1 to the throttle until it’s stopped
I have to look more into it but this mode doesn’t seem like a 1:1 endless ride implementation that I’m going for.
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.
@Jamie42 any insight into your implementation?
3 Likes
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
4 Likes
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)
2 Likes
Can anyone else with a Mellow Drive speak on this. If the Mellow Drive Actually works like what’s described below then it changes a bit:
2 Likes
Wow, I think thats the smallest sub-group of NYC Eboarding ive ever seen.
1 Like
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.
1 Like
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 
1 Like
Yeah according to his words it’s more so:
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.
3 Likes
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.
1 Like
Indeed. Going to think about what exactly is needed that suits the VESC
I’m bit confused here ,are you referring to the ERPM threshold?
@Jc06505n Yeah you did some nice stalking lol
So, you were pretty right until here:
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.
4 Likes
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like