How to get active parking brake

[zapshe]

By the power of not having the ability to edit …:

And you’d add some conditionals so this only happens at a certain RPM or AD1 frequency. There’s a lot of data available.

However, it’s noisy and tends to make a click noise. Here’s the journey:

VESC Tool that I had installed would not support CAN for whatever reason, and that made it so I couldn’t see a LISP tab in DEV TOOLS. I then downloaded the beta version which did let me use LISP - but I needed to update the firmware to be able to use it. The motor simply isn’t working very smoothly with this new firmware. Don’t get me started on how much I hate QML and LISP.

This is a common issue I’ve had when first starting with VESC Tool, where running the motor during detection is very smooth and nice, but then after that it becomes shaky, only rotating at higher currents, and even then the motor will be much noisier.

I still can’t use BLDC mode, it just can never detect properly. VESC Tool still has a long way to go, but pretty amazing for being free. I’ll update once I get everything running smooth.

[jaykup]

Coming along!

What motor are you using, what battery, and what did you select in the motor wizard?

[zapshe]

Going back to the original firmware with the current VESC Tool, mCommands.setHandbrake(40) in QML gives a very very smooth brake!

The braking power feels a bit more powerful than what I got on DC mode. The downside is I’m using QML, which I hated more than LISP and was why I was trying to get LISP working.

@jaykup

Coming along!

What motor are you using, what battery, and what did you select in the motor wizard?

I’m using the 63100 190KV with a 12S battery.

I’ve gone through the motor configuration a hundred times, switched phase wires, changed manual values, etc… The firmware that the beta version uses simply isn’t playing nice with the motor ;(

[jaykup]

Which esc?

That motor should detect easily, but a lot has changed with the beta. A few things you can try:

Use the 750g and 2000g outrunner setting in the wizard

Before running detection change these without testing defaults:

• Up the switching frequency under foc → advanced. 30khz should be fine.
• Turn off phase filters
• change the observer to the regular one
• manually enter the detection results under FOC from the old firmware into the new firmware

Here is an 8/24 build of beta 6.0 that might work better. I run this on a 12s 6374 230kv board, and I’m pretty sure I spun the 63100 190kv up on the bench testing new features with this version.

Official VESC 3.02 FM 6.00 beta.zip

I have the same motor, I can give it a try tonight and see how it works.

[zapshe]

Well, it’s confirmed, HandBrake does exactly what DC mode does. When it’s active, only two of the three motor wires get hot, and the braking feels very similar.

I have the Flipsky 75100 ESC. Honestly, I end up just resetting the firmware until it eventually works smoothly. Regular VESC Tools is giving me some issues now too.

I’m downloading the version you sent me, looks promising! I’ll update you. Appreciate the link a lot! By the time I got the dev version he had just updated it.

[jaykup]

Ohhhh that explains a lot, especially if the firmware is showing as the 75_300_R2.

Definitely disable phase filters.

Also see this thread. The beta firmware there matches the tool I posted.

How to update firmware on the Flipsky 75100 FOC ESC

This 84v 100a ESC can often be found on AliExpress for under $100 shipped. Flipsky claims the firmware cannot be updated and won’t release the source code, so I modified and compiled my own. [image] NOTE: There are two incorrect versions of this diagram floating around. The ADC1 pin is at the end of the COMM connector, and the Hall Sensors may be different. This version is correct: [image] History: At first, Flipsky released this ESC with a note on their website that said the firmware co…

[b264]

BLDC detection is easy. Follow the tips in the ? on the detection page. There is no wizard for this.

@b264

@Tony_Stark

and BLDC detection was just not working.

Try BLDC detection with default parameters

If unsuccessful, raise I to 10A, try again

If unsuccessful, raise D to 0.12 (12%), try again

If unsuccessful, raise ω to 250 erpm, try again

If unsuccessful, raise I to 15A, try again

If unsuccessful, raise D to 0.17 (17%), try again

That process hasn’t ever failed me with esk8 sized motors

But also just click the ? and read exactly what it says there; it’s actually really helpful.

[zapshe]

Broooooooo

Bro

No way ;( Flipsky, why has thou hurt me so?

I’m checking out all this info. I was a little iffy with this ESC, which is why I’m putting it in my skateboard and not my other project where I’m looking for a quality ESC.

@b264

BLDC detection is easy.

I’ve changed those values a million times with no success. It’ll spin just fine and give me nothing.

It might be because of this firmware nonsense, I’ll definitely try again after updating it.

[jaykup]

@zapshe

When it’s active, only two of the three motor wires get hot

Isn’t this expected? Only two of the three phases are driven at any one time while the other is used to sense bemf voltage to track position. So a motor that isn’t rotating would be using the same two phases.

[zapshe]

@jaykup

Isn’t this expected? Only two of the three phases are driven at any one time while the other is used to sense bemf voltage to track position

Didn’t know that. New to everything

I noticed a few things. I didn’t ignore input when running the code, so the input and code conflicted causing weird noises. Turning ADC off does the trick, I’ll incorporate it into the code soon.

That beta version you had is much more stable than the last one. The newest one crashes when I even try to look at live data!

I’m not sure how big a difference the new firmware did, but the motor is running smoothly again BLDC mode still doesn’t work, even after following the steps you put Peter :((

However, I now can use LISP with a nicely running motor! So the real coding begins… once I wake up.

Bed time, I stayed up a lot, I didn’t even notice the time. I also trust Flipsky less now :(( But they do have good customer service and unbeatable prices.

THANKS GUYS FOR THE HELP!

[tech.shit]

@zapshe

Peter

His name’s Brian

[Linesflag]

Peter is also good.

[zapshe]

@tech.shit

His name’s Brian

Hold on, so he’s the talking dog? I thought he was a family guy.

[tech.shit]

More like an Atomic Dog:

George Clinton - Atomic Dog

[zapshe]

These wires worry me. 12AWG wires can get pretty toasty carrying so many amps for the braking. For the skateboard, I could add a fan in the encloser with some breathing holes, but it won’t be quiet as easy to get cooling in my other projects.

Anyway, I can read the AD channels right off LISP and set conditionals for how the motor should act. This is what I envisioned when I first got started, exciting!

The ESC hardware is fine and LISP runs smoothly enough. Though, beware of printing to the console in infinite loops It takes up the entire run-time of the program when you go into Dev Tools and causes VESC Tool to crash. Only option was to reinstall the firmware.

The skateboard materials are crawling their way over from china.

Side Story: I need to drill into some tough thick aluminum and hand tools weren’t doing the job. An adapter should be here to tomorrow to see how good this motor functions as a CNC machine

[zapshe]

This is crazy, having a print statement anywhere in a loop will just overtake everything.

LISP on VESC Tool very much seems like a work in progress. It’s as if the code is running parallel on the same thread. It would print repeatedly but not run any other code in the loop.

Why LISP was chosen instead of literally any other programming language is beyond me. Python is the obvious choice to make it programming friendly. C++ would have been a good choice.

Well whatever, can’t complain too much when it’s free, but it’s boggling. They even programmed it in C and said themselves they’re still learning LISP.

[zapshe]

Well, I guess that’s it. LISP is just plain awful to work with, but it doesn’t take much to do what I wanted:

(print(get-adc 0))
(print(get-rpm))

(loopwhile t
  (if (< (get-adc 0) 0.5)
  
    (if (< (abs(get-rpm)) 200)
     (set-handbrake 50)
     (set-handbrake 0)
    )
    
    (set-handbrake 0)
  )
)

My plan with the remote-less skateboard is to have two “pedals” that I can easily press when needed. I can have it so the acceleration happens while my foot is on the pedal and then maintains the current when I take my foot off. Then it’ll slow down when I press on the brake pedal.

Left foot accelerates, right foot brakes. They’ll also be weight sensors instead of just pressure pads, which is something that I can either take advantage of or might be too unreliable. If that doesn’t work out, I have some other ideas.

And if all else fails, I’ll have a stupid remote ;(

May have to alter the code a bit, though this very well could be close enough to perfect. The 200 will definitely have to change. It has to be a value low enough that the skateboard doesn’t dead stop while going too fast, but high enough it doesn’t think it’s moving when it’s really just braking while overcoming something like a slope. I’d have to test, but I think there’s likely a very large sweet spot.

Did I mention how stupidly unintuitive if statements are? Whoever made this language definitely wanted to look important while programming.

[zapshe]

Well, looks like LISP and regular old VESC tool don’t exactly play nice.

LISP takes up valuable CPU time running a loop which interferes with regular operation.

Two solutions:

Stop using App input all together and rely solely on LISP code to run the motor.

Or be reasonable and figure out how to do some multithreading.

I’ll update with code once I figure this stupidity out.

[zapshe]

Well, it didn’t need threading, it just shouldn’t constantly set handbrake current while not braking.

However, I can’t get the handbrake to work at all without turning ADC off manually in the settings. I used “(app-adc-detach 1 1)” which should (and does) stop the motor from acting on ADC input. But I noticed that using that command alone makes the motor draw 1-2 amps of braking current. This stops by settings ADC to just current and no brake.

Even then, the handbrake still will not work, and the motor will just make a ticking sound for every loop iteration. Turn ADC off manually, and it works no problem.

At my wits end for tonight. If anyone has any idea what’s causing that issue, would help a lot. It’s the final nail in the coffin.

Getting regular App input to play nice with LISP is such a pain, I am actually really considering just having input off and programming my own current logic… in LISP… shudders.

Functional programming my ass

[zapshe]

Oh, well I changed ADC update rate to 1hz, then it did a 180. It’ll handbrake and once a second it’ll make a tick where it wont.

This confirms that even though I’ve detached ADC input, it hasn’t actually stopped the update loop for ADC input which then interferes with the code.

Anyway, I’ll have to figure it out tomorrow. Here’s the code I have so far, idk if anyone is even interested or reading this stuff anymore:

(define rate 1)
(define braking 0)

(define one 1)
(define zero 0)

(print(get-adc 0))
(print(get-rpm))


(defun brake()
    (progn
      (print "Braking")

     (if (eq braking 1)
      
      (progn
      (print "1")
      (set-handbrake 25)
      )
      
      (progn
      (print "2")
      (app-adc-detach 1 1)
      (set-handbrake 25)
      (define braking one)
      )
      
     )
    )
)

(defun unBrake()
     (progn
      ;(print "unBraking")
      
      (if (eq braking 1)
      (progn
      (app-adc-detach 1 0)
      (set-handbrake 0)
      (define braking zero)
      )
      )
     )
)

(defun loop()

    (progn
    
        (if (< (get-adc 0) 0.5)
            (brake)
            (unBrake)
        )
        
        (yield (/ 1000000 rate))
        (loop)
    )
)

(loop)