I just found this thread after dreaming about implementing such a mode for a few years now.
I recently bought a used Lou Board and burned the Motherboard after spending a day reverse engineering the thing.
So, got a VESC ordered, here’s my plan:
Use only a rear foot sensor to infinitely hold the speed.
Breaking and accelerating should be handled like on a regular board, without the esc intervening.
I am not quite sure yet how to implement the foot sensor, thinking about force sensors.
I am not too concerned about the range, just want to be able to ride that thing without getting noticed by police.
That is also the reason why I will most likely extremely limit the max current, so I can not magically drive up hills and will still be forced to kick up a hill.
Also, I am not sure yet if the VESC should break in order to maintain speed downhill, since that might look suspicious aswell.
Is there any way to adjust whether the VESC will slow the board down in order to maintain set RPM?
I even thought about using two TOF sensors for foot detection. In that case I would be quite worried about stepping on them though.
Also, is there a way to turn off the VESC through UART/CAN?
I suspect that there is a command for that, didn’t find it yet, though.
Would be awesome to have the board go to standby after a certain time of inactivity.
Most antisparks here have auto turn off after 20 or 30 minutes, and auto turn on when the wheels spin (just gotta wait for the VESCs to boot) Theres a group buy going on right now for a really good price if youre future proofing.
Aight, got some progress to report:
Here are pictures from the board and the setup, including a simple pressure sensor.
(turns out I can’t upload pictures)
I am thinking about adding a symmetrical second sensor to avoid issues while balancing in turns.
After spending a few hours trying to connect an arduino I ended up programming the VESC itself, here’ s the code on github: /dakhnod/bldc/blob/master/applications/app_kickassist.c.
For now I am remaining with 2 issues:
- especially at higher speeds the board accelerates beyond the current speed for some reson. Maybe a simple currentRPM * 0.9 or something will help.
- a few times the board just started breaking for a split second, enough to throw me off though.
To counter those issues I implemented a moving average filter that sadly doesn’t seem to help though…
Still had a lot of run riding around so far. Especially riding down hills is amazing since the board breaks by itself.
bumped your level so you can post images now
I bumped you, you can post pics now. Welcome. @wandagoner aperantly can’t find the save button 
.
I tried eliminitating theoverspeeding issue by adding a constant factor, didn’t help.
Sometimes the board slows down to 0.9 of the current rpm, so the code works.
Sometimes it still accelerates to above my current speed.
Are there any algorithms involved in calculating the current rpm that may somehow break the reading of mc_interface_get_rpm()?
If so, I think I will just create my own Hall pin interrupt to test my own calculation of rpm…
I got another issue now, hope someone can help me.
I am measuring the Pressure Sensor (which just changes resistance) using the ADC on the vesc.
I have the adc pulled up by a 1K resistor and pulled down by the sensor, creating a voltage divider.
Recently, the ADC started to report 1,5v ± 0.1, no matter the sensor state.
Even if I only pull the adc up or down without the sensor it still reports 1.5v.
Is there any way to solve that? Any setting I accidentally switched in VESC?
I don’t know of any such setting, i have heard of people frying ADC pins, especially on v4 vescs. Try using ADC2? Its also not a big deal to reset all your settings and start over.
I had a few glitches with my VESC, trying to sort everything out.
Currently, the VESC tool is showing me a Duty cycle of around 4%, although the motor is not moving.
I exptected the duty cycle to be 0 when the motor is neither powered nor moving by itself.
Is there any fix to that?
Alright, turns out the Duty cycle jumps from 4 to 60-80% depending on the input voltage on the ADC pins while the wheel is standing still.
I really don’t know what is going on. Anyone familiar with those symptoms?
You should try just using Vedders ADC app. With this, set the control type to “Current No Reverse Brake Center”. Now ADC1 will act as your throttle control and the servo pin (or normally pwm/ppm pin) acts as a cruise control switch. Pull it HIGH (~3,3v) or LOW (~0v) to activate or deactivate cc.
If you set the input deadband of ADC1 to 100% then theoretically (never tried as I use a remote that uses ADC) all throttle input is ignored and you have cruise control by pulling that servo pin HIGH/LOW. If you need to, you can invert the cruise control pin behavior.
Don’t even need to upload modified vesc fw.
May be a bit tricky since the pressure sensor may vary in resistance range, and the result is almost never binary 0v/3.3v…
I ordered another VESC and have another Issue out of the box.
The 5v rail aswell as the 3.3v are delivering less than they should.
Thus, the hall sensors seem not to work, so the motors alway get recognized as sensorless.
Where exactly does the 5v and 3.3 get generated? What chip should I look for?
So, i managed to total one VESC and got one repaired.
I did drive around for quite a distance now and it’s a lot of fun.
I have just one concern…
often, when i put my foot on the sensor, the set speed is a bit off my actual speed.
When I am accelerating the set speed turns out a bit higher, when i am deccelerating the set speed gets a bit slower.
As far as i understand there is quite some math involved to calculate the ERPM, and I don’t fully understand why.
Wouldn’t it be sufficient to just hook the halls via an interrupt und count the interrupt times per time unit?
To me it looks like there is some predicition involved that tries to predict what the speed is going to be in a fraction of a second, which leads to the strange behaviour described above.
Is there any way to get the actual ERPM or RPM without those algorithms involved?
Are you getting filtered RPM or rpm from mc_interface_get_rpm()?
I am using mc_interface_get_rpm
And i thought that with that there is some filtering involved…