openinverter forum

Did something that I wanted to do for a long time, a hill hold function, so stopping the car from coasting forward or backward on a hill.

The strategy is to counteract the distance travelled since the time of activation. The more we move away from our reference point, the more we try to pull into the opposite direction.

So to the encoder class I added a function to measure the distance in radiants and a function to zero out the distance measurement. Rolling backwards gives negative distance, forward gives positive distance. When rolling backward we apply positive torque in order to stop rolling.

When pressing the brake pedal the function is armed and distance reset, as soon as you let go off the pedal the controller becomes active. When you give more throttle than hill hold requests the function is disabled and your back to manual control.

I tested it on a super steep incline that requires like 60% throttle to keep the car stationary and it works super well. The car rolls back about 20 cm then it stops. The distance can be configured with the proportional gain. Of course it mustn't be too high as that will cause oscillation. I set the parameter holdkp=-1

It didn't work so well when rolling forward, I have to investigate that. So the controller correctly commands negative torque when rolling forward but at some point FOC generates excessive id and almost no iq and therefor hardly any torque. Have to check if that is a principal issue with MTPA or FOC itself.

This may or may not work with induction motors, actually I'm quite sure it won't stop forward motion. Attaching a binary anyway.

This is fantastic. Sadly I'm not in a position to test but very happy to see this added, and the approach of applying a proportional torque based on distance travelled seems very elegant.

If I might make one (hopefully trivial) suggestion, I would likely not want this feature to prevent forward motion (rolling in the selected direction), so when it comes to configuration, it would be great if this could be enabled independently.

catphish wrote: ↑Fri Nov 19, 2021 10:52 pm This is fantastic. Sadly I'm not in a position to test but very happy to see this added, and the approach of applying a proportional torque based on distance travelled seems very elegant.

If I might make one (hopefully trivial) suggestion, I would likely not want this feature to prevent forward motion (rolling in the selected direction), so when it comes to configuration, it would be great if this could be enabled independently.

Thanks
Yes that seems like a useful config option

Hello johannes. Great, I'll test the sine firmware in the near future, I wanted to ask you to do it earlier, but I kept forgetting something. Thank you for your work.

You can attach a file with the hex extension

Maybe a strategy would be to opt for zero speed instead of distance traveled. And don't forget to include windows for small errors.
Also a maximum torque and speed would be wise to implement.
(While in this mode).

A counter option would be handbrake release request from the drive unit. But maybe that concerns me having a newish car.

EV_Builder wrote: ↑Thu Dec 02, 2021 12:50 pm Maybe a strategy would be to opt for zero speed instead of distance traveled. And don't forget to include windows for small errors.

Tried it, doesn't work. Speed info is much less accurate than position and thus distance info.

johu wrote: ↑Thu Dec 02, 2021 7:12 pm Tried it, doesn't work. Speed info is much less accurate than position and thus distance info.

Yes, because speed is the distance component * time component.
So distance = 0 would be then speed=0. Did you try distance =0?

To let this work better we would be helped with an inclination sensor... It would give us a pre-load idea for the control loop.

Saying that i would think that a Current / Distance Loop would be fairly quick in a PI Loop, but i have no clue yet where the challenge lies in that.
The problem with low speed motor control is that the encoder update rate is sensitive and very influential.
That's why a SIN/COS encoder is so brilliant for many applications instead of a incremental encoder.

What kind of motor / encoder is your test bench?

When i'm upto it i will try these features too.

I'm trying on the Leaf motor with resolver.
It works very good, even on steep inclines. Current/Distance loop is what we have.

EDIT: I also found out why it doesn't stop forward movement: I'm not allowing negative q-voltage while forward gear is selected. That was to get rid of the startup oscillation. Might have to temporarily allow that while hill hold is active. Or only allow hill hold to stop backward motion.

Yeah "the loop needs room to move". How well would this work on the encoder based motors like Tesla?

The Tesla M3 motor does it has encoder or resolver?

EV_Builder wrote: ↑Thu Dec 02, 2021 9:42 pm Yeah "the loop needs room to move". How well would this work on the encoder based motors like Tesla?

It should work reasonably well, as the Tesla encoder is 36 pulses delivering 144 edges (falling, rising, channel A, channel B). So we still have 2.5° resolution. A resolver is not much better, maybe 0.5-1° of noise-free position resolution.

Worked on hill hold a bit and I think I can release it now. I took away the possibility to stop forward motion as that is awkward to use and introduces some additional issues.
So to enable it set "idlemode" to "HillHold" and configure a sane value for idlethrotlim. I use 60%. holdkp can be tuned between rolling distance and oscillation. The high, the less the car rolls back but the unquieter operation becomes to to amplified sensor noise.

Again, I can't test the sine version due to a lack of car, so would be happy if somebody does.

EDIT: as a future improvement I could enable hillhold as soon as the motor changes into the wrong direction. Then there's no need to press the brake.

Is this a new firmware version or an addition to a previously installed one?

no such thing as an addition, it's always a new version

Today I filled in this firmware "stm32_foc.bin" and got a brick from the car. I had to go back to 5.14 I stitched it as always. What have I done wrong?

What exactly happened? I've run this firmware in my car.

Renegate2020 wrote: ↑Thu Feb 03, 2022 1:32 pm Today I filled in this firmware "stm32_foc.bin" and got a brick from the car. I had to go back to 5.14 I stitched it as always. What have I done wrong?

Let's start easy. SINE vs FOC?
Just trying to help here.

FOC.
Stitched as usual. I went to the address 192.168.4.1 - nothing inside. auto does not turn on. I tried to flash it again - the result is the same. I tried to flash 5.14FOC - everything worked again.

Maybe it's something like - https://openinverter.org/forum/viewtopic.php?f=5&t=1756 ?

I have to say i''m incredibly happy with this hill hold functionality. It works like a charm! Hopefully somewhen not just backwards and also forwards. Thanks Johannes - awesome work!

Thanks! Time for a new official release...

hello everyone!
did I do something wrong or is my voltage (130 volts) too low for adequate hill retention work?
even on the smallest slope, I can feel the engine shaking in an attempt to brake the buggy, but it still rolls backwards.

these are my settings