So.... Endless ride, how we doing?

#41

I don’t even think you’d need to tap up to break the endless mode. In a car, the second you tap your brakes, even a little, it stops cruise control. I imagine you could just have a one way throttle for braking only at that point.

1 Like
#42

Yep. This mellow endless mode on a surf/carver settup would be great.

3 Likes
#43

I honestly want that too. I enjoy kick pushing but my problem comes down to how well the implemented artificial power (definitely not motors) handles without my control.

If you’re cruising up a hill on mellow mode and it’s timer shuts off, do you feel a noticeable kick back? I didn’t see it mentioned at the end of the video, it just shows it accelerating on its own. Hopefully it’s smooth enough to be gradual braking and not just a stop.

1 Like
#44

For the record, I am also in favor of this. If it worked exactly like it does in the Mellow video, I would be happy. My suggestion was just to try to strike a balance between what @Venom121212 was saying and what you were saying.

I suggested tapping up on the throttle so that there is a way to enter coasting without also decreasing speed or getting a noticable jolt when your breaks kick on. Just to try to keep everything as natural feeling as possible.

1 Like
#45

I have somewhat tried some of these suggestions. For example, with my FireFly Nano software, real endless till you want to coast worked just perfectly, didn’t even have to do a push forward to go to coasting, brakes don’t really engage when you just tap it out of cruise. (Because the VESC deadband is bigger than the remote deadband)

I am now working on that mellow implementation. I am thinking of applying a 10Hz (Higher/lower, idk something like that) 50% duty signal to the cruise control input of the vesc.

But all of these suggestions are possible really… I think it just comes down to personal preference.

4 Likes
#46

If endless were an implementation into the VESC FW, how do you think it should be activated? It seems to me that the simplest/easiest/most reliable way to implement it would be as a separate input type in the app config window. And if you want to switch in and out of it, you can use profiles.

(I have actually never used profiles before, despite Franks urging that they are awesome. Can you switch between different control modes in profiles? I.e. “current reverse with breaks” and “current smart reverse” etc?)

1 Like
#47

Thinking of doing This for a Grad Project. Would need to dive into Vedder’s code to understand how it would all work. But it seems the biggest hurdle is about implementation. Here’s how I’m imaging it:

VESC Tool has a setting Labeled “Push Assist” that can be checked or unchecked.

When checked it’ll have the following Fields

  • Max RPM Limit (this is the max RPM that a board will maintain for x amount of time)

  • Max Holding Limit (this is the amount of time that the board will hold the Max RPM Limit before ramping down)

  • Regular Holding Limit (this the the amount of time that the board will hold any speed below the Max RPM Limit before ramping down. )

Perhaps a field for setting the RPM Deceleration ? But since 30 RPM/s was good enough for mellow maybe not. Maybe it should be a set deceleration.

When the “Push Assist” setting is enabled. The remote can only be used for braking.

To switch to normal mode, you would just switch VESC profiles.

@Trampa can I assume that switching profiles is as easy as easy as just choosing a profile without further steps (I’m a bit tired at the time of writing this so I’m a bit too lazy to search for it)

Thoughts? I think this implementation allows for almost any configuration using VESC FW agnostic of the kind of remote you have and is a 1:1 of Mellow’s implementation in theory.

4 Likes
#48

Would be pretty awesome if you pulled it off. Ready to help where possible

2 Likes
#49

After reading the previous thread and what I think you wrote before in the past : this seems just like Timed Cruise Control. The timing settings just need to put there. It’ll be a while since none of my VESC’s or stuff is with me. But I strongly believe it comes down to having those four settings: Control Type: Push Assist, Max Push Assist ERPM, Max Push Assist Time Limit, Regular Push Assist Time Limit.

With a Rampdown of 30 RPM/s (is that 210 ERPM/s With our motors? )

The only caveat that mellow didn’t seem to tackle is Hills. Their boards seem to maintain the Hill Speed , so it’s up to the user to use the brakes on a hill. If the user decides to free roll then it’ll keep that free roll speed.

I’m unsure if their board is Maintaining that Max 25kph while going down the hill or just speeding up and going the max speed it can go and continuing that speed after. Can anyone with expertise with Cruise Control tell me what happens to your speed as you descend a hill?

2 Likes
#50

My biggest concern by far. Definitely following the progress on this. Also, what happens if you fall of your board while cruise control is implemented? Assuming you can’t immediately hit the remote brakes after falling :thinking:

1 Like
#51

When you go downhill you just use your brakes :man_shrugging:

1 Like
#52

Yeah… I get I can brake with a remote.

I mean what happens when you’re cruising downhill at a good speed and you exceed “max” speed? I don’t want a board cutting ANY power underneath me without my input, especially while on a hill. Also I like going over 25 kmh.

2 Likes
#53

Good point. It just needs to free roll until you brake I suppose, as it normally would.

1 Like
#54

https://vesc-project.com/node/407

Relevant Thread that came to the same conclusions we did.

Seems the biggest issue is dealing with overshoot:

One problem is overshoot, when setting the RPM the vesc uses a PID controller to set the current based on the rpm error. Now when someone jumps off the board for example the rpm will overshoot quickly causing the endless mode to continuously accelerate.

The other problem is about hills:

Another problem is discriminating between pushing and going down a hill for example, this can be ignored if the user brakes.

I don’t think is a large problem since we’re keeping the controller for braking purposes.

In regards to the overshoot issue is it the same occurrence as what’s happening here ? :

#55

Thanks to @DerelictRobot and @ducktaperules help and pointers,

I was able to make a “proto” logic for how it might be implemented as a State Machine:

STATES:

  • STANDBY
  • RUNNING
  • RUNNING_AT_MAX_ERPM
  • DECELERATION
  • ACCELERATION
  • BRAKE

The board would start in STANDBY Mode awaiting for an acceleration (push) that goes over a set Minimum Standby ERPM.

In STANDBY:

If the board somehow reaches a certain speed, the Maximum Push Assist ERPM, then the board enters the RUNNING_AT_MAX_ERPM state.

For any speed under (but above the Minimum Standby ERPM) it enters the RUNNING state.

Before entering either state, the timer starts ( with a longer timer for RUNNING_AT_MAX_ERPM).

IN RUNNING | RUNNING_AT_MAX_ERPM:

In the RUNNING | RUNNING_AT_MAX_ERPM states, the timer is constantly check to see if the set time has expired.

if the timer expires than the board will switch to will switch to the DECELERATION state

In the event that an acceleration (push) occurs during this state, then the board will enter the ACCELERATION state.

IN ACCELERATION:

While in the ACCELERATION state, the board will reconfirm that and acceleration was made, and check to see if the RPM resulted from the acceleration was greater or equal to the Maximum Push Assist ERPM. If so then the board will start the timer and enter the RUNNING_AT_MAX_ERPM state.

For any RPM resulted under the Maximum Push Assist ERPM, then it will start a shorter time and enter the RUNNING state.

IN DECELERATION:

While in the DECELERATION state, the board will first check if the current RPM is at 0 (board has stopped) if so then no deceleration will occur and the board will enter the STANDBY state.

If the board ERPM if greater than 0, then the board will decelerate by a set Push Assist Decelerate ERPM value ( but before doing so it will check if it will decelerate past 0.0 RPM and if it does it well just set the speed to 0.0 RPM).

If it detects an acceleration during this state, then the board will enter the ACCELERATION state.

IN BRAKING:

If braking is detected (servo_val < 0.0), the the board will enter the BRAKE state and brake until the rpm is 0.0

I would implement this in app_ppm.c since that’s the most popular app_config (and the remote that I’m using).

Thoughts? If you find any logical errors or situations that can go wrong with this please point them out as it would be very much appreciated. I’m limited by this being my first time doing robotics related work, messing with the VESC codebase, and having no board near me to test this on.

TLDR Visuals:

image
image2732×948 654 KB

EDIT: Changed DECELERATION state to only activate when the timer expires in RUNNING | RUNNING_AT_MAX_ERPM

7 Likes
#56

how does it differenciate a push from going downhill?

Is there a remote/foot sensor invoved in this?

2 Likes
#57

It doesn’t. :sweat_smile: I’m taking the closest implementation to Mellow’s (using how Vedder does Cruise Control ) so it will require a remote for downhill situations. As far as I looked, Mellow’s Endless Ride requires user to brake downhill or risk overshooting I think. Same case here kind of. Since it’s based on the Nunchuck’s implementation of Cruise Control , the same thing that happens to boards using Cruise Control downhill will happen here.

For a full accurate picture I would like it if someone with a VESC WAND could test CC going uphill and downhill so I know what behavior to expect

3 Likes
#58

If you are cruising and hit a small uphill, will it start to decelerate you?

Great work all around and beautiful explanation

1 Like
#59

To be determined right now (need to work out how I sample for acceleration in the first place) ideally it should do the same thing that Vedder’s Cruise Control does when it hits a hill but that all depends on how I approach this. Will come back to you once I work this out.

For future reference this is a crude explanation of how Vedder Does Cruise Control in app_nunchuck.c (if I got any steps wrong please let me know) (this is in a loop):

Nunchuck's Cruise Control Implementation in Crude Chunky English

I’ve linked the corresponding code lines with the plain English part.

Delay a bit

Get Current Filtered RPM

Check For Timeouts

Do some Configurations

Button Detection for c+z

Detection Stuff for Z button, control type settings, reverse ,etc (Lines 243-267)

Decode throttle input and run it through throttle curve filters

LED Logic

See if C button is being Pressed

If so:

Initialize the goal_rpm to 0

Check if cruise control is on

if it’s NOT then:

  1. Set the goal_rpm to the Current RPM

  2. Check if were in reverse mode AND the Current rpm is greater than 0.0 OR if reverse is not enabled AND the current RPM is less than 0
    A. If so: Make sure it’s not too high in the opposite direction (if it is cruise control will not engaged and we’ll LOOP BACK TO BEGINNING)
    B. If NOT then the goal_rpm will be set to 0.0 (board will try to stop I believe)

  3. Indicate we are now in Cruise Control

  4. The goal_rpm will be set as the PID Speed

  5. The same current will be sent to the other controllers connected over CNABUS

  6. Set the previous ramping current to not get a spike when releasing PID control and for smooth transition

  7. LOOP BACK TO BEGINNING

I got a but lazy here but this section is basically doing the same in each statement but takes into account for the mode that it’s in
if it IS on then:

  1. Check if in reverse Mode and ensure that the goal_rpm is not "reversing"

  2. Set goal_rpm based on user throttle input and the set Stick ERPM/s for cruise control over a stamped time period

  3. Check if the goal rpm is Greater Than (or Less than if in reverse mode) the Current Speed + Erpm/s

  4. if it IS then set the goal rpm to that Current Speed + Erpm/s (or Current Speed - Erpm/s if reverse) rpm

  5. If it’s NOT then the goal rpm is fine. (as evident with no else statement)

  6. The goal_rpm will be set as the PID Speed

  7. The same current will be sent to the other controllers connected over CNABUS

  8. Set the previous ramping current to not get a spike when releasing PID control and for smooth transition

  9. LOOP BACK TO BEGINNING

god this took too long but at least I have a reference

2 Likes
#60

Solid progress! Nice work

Is this to check for like someone foot braking? If so I’d leave this out. Looks like it’ll cause more issues than it’s worth.

1 Like