Are footpad sensors for a VESC onewheel necessary, or is there a "software only" alternative?

I’m just thinking loud here about footpad sensors, onewheels running away on their own, etc.

From a perspective of Potential and Kinetic energies, it should be possible to detect whether a person is present on a board or not - in software only.

Power is the rate of change of Energy, mathematically speaking, Power is the time derivative of energy expressed as:

P = dE / dt

Some physics

Mechanical Power of board with and without a “driver” (person):

We assume that we know the weight of the board, and the weight of the board with a driver.

The Kinetic energy is calculated from IMU data. Increase in Potential energy likewise from IMU data. Then we get the mechanical Power by dividing the total energy by the timestep dt.

Finally, there are power losses due to friction, heat, etc. It should be possible to roughly estimate these. Maybe the total loss is a function of speed?

Electrical Power:
The electrical power is simply the Wattage used by the Vesc (voltage x ampere) averaged over the chosen timestep dt.

Detecting run-away state:
BY comparing the Mechanical and Electrical Power numbers, one should be able to determine if we have a run-away board (no person present).

Are there other things the footpads are used for?
Couldn’t the “Power Up” state be determined by observing IMU data?

2 Likes

It should be possible theoretically to detect the rider getting on the board by IMU input only. How accurate and quick the detection would be once implemented, that I don’t know.

However, how would you get off? Just jump off? Then the board will probably roll onto the rails and the anodisation will get scratched

2 Likes

While what you’re writing and thinking is interesting, it seems to be missing the practical reality of what onewheels (and VESC onewheels) generally see in their daily life.

There are reasons why this board shape has foot sensors, in one form or another.

On the IMU specifically, there have been, and continue to be, times when IMU confusion leads to odd balancing or ride behavior. This can be from slightly bad calibration, a bad IMU, brown outs on the 5v/3.3v rail for one reason or another, a slightly untuned zero vector frequency (currently, a massive thorn in the side of people tuning VESC onewheels and their ride feel), and probably other things.

Relying on the IMU to detect the rider would lead to any IMU confusion or issues to risk a runaway/ghosting board. The same would happen if the IMU simply didn’t register the conditions for dismount.

Ghosting already happens for a number of reasons to do with the footpad, or the tuning of a VESC onewheel, and whenever it does, it’s very scary. A sensor can be damaged or defective, or cold temperatures cause the plastic layers to rebound too slowly to open the switch, or a defective sensor leads a user to disable moving faults, and they encounter a ride condition where that leads to a jump off and a ghosting situation.

Generally, that’s kind of rare, but I think it’s rare because the foot sensor has remained a physical switch that, so long as it’s checked to be working, will operate reliably whether or not the IMU is functioning and calibrated as expected.

Even with a bad IMU, a rider can feel a problem and jump off, and the board will disengage.

I’m not sure if you remember or paid attention to the launch of the Onewheel GT, but due to both the sensor changes and the firmware conditions for engagement, many boards ghosted and led to property damage and injury. One NYC rider had his board ghost backwards and break a pedestrian’s ankle.

That’s all to say, that currently, the way foot sensors are (a physical switch), seems to be on the side of more consistent activation/deactivation so long as when setting up a VESC onewheel, the builder can verify that the sensor actually works and doesn’t show any delay of the ADC voltage changes.

Even outside of IMU confusion, and circling back to the general life of a onewheel, there are many conditions of riding that can and do subject the board to weird, jarring, and impactful movements that can appear almost exactly like a person getting onto the board. Trick riders manipulate the board while on and off, trail riders have their boards tumble down cliffs and bounce around during crashes in odd ways, and onewheels are generally expected to take large amounts of physical abuse and continue to work normally, VESC onewheels included.

The idea of software based foot sensing is interesing, and any new ideas are always interesting.

Stoked Stock and Tech Rails have been working on a LiDAR based foot sensor, and that seems novel and interesting. But, it still leans on the sensor itself being a separate and purpose-focused thing that only concerns itself with whether or not a rider is on the board. And I think that’s because rider detection is near the top of safety concerns for a onewheel.

Riders do fall, and that’s always bad. However ghosting boards are a larger concern, as they can (and have) injured bystanders who didn’t ask for it or have anything to do with the ride.

Mixing rider detection with components that do other things on the onewheel, I generally remain skeptical of.

10 Likes
  • Thanks for you very detailed description.

  • Footpads are the most annoying part in building a diy “one-wheel”, mechanically speaking.

  • I believe that “run-away” can be reliably detected without footpad sensors. There is a large margin between the weight of the board only and the weight of the board with a driver. The Vesc, with FOC, is indeed a very reliable sensor of the applied electric energy. FOC can’t work at all if these measurements are the slightest off.

  • From my experience, with proper filtering, IMUs seem reliable - probably as reliable as the footpads themselves (which also introduce possibilities of errors).

  • Detection of runaway when movement is downhill, and no motor torque is applied to the wheel, is the most challenging special case. This is the situation where the increasing kinetic energy is only fueled by conversion of potential energy. Here detection relies on the knowledge of losses in the system. Due to losses, a heavy board will accelerate faster than a very light board. This can be detected reliably, I think. It’s all a question of the length of the time-window, in which you’re avaluating a changing state.

  • How to get off the board…? I don’t know :smiling_face_with_tear: Any suggestions of how that could be detected without footpads (except pushing the turn-off button)? Some creative thinking is required. This state might be the reason why footpads are required.

If you can come up with a good way of detecting when a person wants to step off the board, I think all the other states can be reliably detected.

1 Like

“onewheels are generally expected to take large amounts of physical abuse and continue to work normally”

The question here is: Which sensor will survive the most abuse - an IMU or a Footpad?

But yes, you added another “state” to the list of states, which is “Detection of a flying onewheel”.

But software detection is not as bad as it sounds… Software doesn’t get damaged - mechanical stuff does…

You certainly seem motivated. I look forward to what may come of your thoughts. Do keep in mind that there have been, and always will be, a decent wall between what works on paper and what survives the reality of application.

Just a couple points I feel I need to push back on:

That’s simply untrue, especially in VESC. FOC values for any motor have a decent spectrum within which they will work. In many cases, nearly uniformly. FOC parameter detection, even in higher end VESCs with better components, will return different values within a range.

If FOC didn’t work if measurements were slightly off, then large quantities of motors and ESCs couldn’t be batch flashed and sent out the door, working fine.

Well… if that were the case, then MD5 checksums wouldn’t be necessary. Neither would VESC firmware reflashes. Or PC reboots.

Software can get bugged all the time, it’s just how it is. Maybe those instances are all rooted in hardware issues, I don’t really know.

But, there are countless cases where VESCs develop seemingly random problems, that get resolved from a reflash of the firmware.

A footpad, probably. It’s a simple physical switch that can be physically protected after being installed.

Also, since it’s a simple physical switch, it’s much clearer to see if a crash or fall has damaged it in a dangerous way. You can check if it still works, and allows a dismount. If the switch isn’t stuck closed, it’s not stuck closed.

IMU problems can and have revealed themselves after successful configurations, sometimes after miles of riding and a rider assuming it’s normal due to lack of reference.

A broken footpad sticks out like a sore thumb.

Again, I look forward to whatever it is you’re working on. I just hope that you keep a firm grasp on why footpads are still used after years, even when other things for onewheels were kind of abandoned.

Cheers.

6 Likes

Thanks for very good points in your feedback. Let’s see how the subject evolves…

OP: anything about onewheels

Mario:

6 Likes

Maybe this is an overstatement or I forgot important details. I will re-frame it:

  • “If something is wrong with the motor or the motor driver components needed for current and voltage measurements, FOC with HFI (sensorless at zero speed) will not work for any practical use. You will know that there is a problem, cause you can’t ride the board. Therefore, FOC with HFI for measuring Power, might be the most reliable of all sensors present in the system”.

  • Isn’t a reliable IMU the core of the whole idea about the onewheel? If the (Kalman filtered or…) measurements are wrong, wouldn’t it lead to an immediate crash, nose-dive, or anything else but success? If an IMU is bad, you would immediately know, right?

  • You have much more onewheel-experience than me, and it’s difficult to evaluate all the details and difficulties in a software-implentation. First thing would be to identify all states in the system.

It can’t be IMU only… You also need electrical power measurements from the motor driver (Vesc).

1 Like

This is already possible. There are settings “push to start” and “disable moving faults”. This requires the board to be in a balanced position to start and you jump on. The board turns off via pitch or roll faults when it falls over.

No one I know has done this because it is not convenient. You want a footpad to engage the board at a minimum. A lot of people use disable moving faults but I don’t recommend it.

1 Like

To me, this looks more and more like a KALMAN filter…

You keep two filters going:

  • Filter 1: Filters data as if a person is standing on the board
  • Filter 2: Filters data as if a run-away state

Then you observe which one has the largest error.

To filter what? It’s an interesting concept but you’ll have to flesh it out a bit to get people to buy into it. What’s the input? What data do you have to support your conclusions? Data logs are useful for this. Post processing different sets of data to show the variables you would like to target for your condition. Proving that they are mutually exclusive to prevent the board from turning off when it shouldn’t.

I’ve been writing board behaviors for a while. I already use a kalman filter on pitch to prevent vibration so implementing it in other places would be easy. The error checking method would have to be written.

I don’t want to discourage you. You have interesting ideas but there are like 4-5 people writing code. I suggest you get into the code and make your ideas reality or do more groundwork to make your case more clearly. If I see you have something I’m happy to pick it up and work on it with you. I’m also just happy to chit chat about board behaviors in general.

1 Like

You’re right - there’s no way around coding, and my points might be naive at this stage. But I’m sure it can be done, and all the data for state detection is there. I will have to code…

Awesome. Great attitude. The community really needs more people who understand the code and are developing ideas. I think there is a lot of low hanging fruit that just needs the right perspective.

Let me know if you have questions. I’m no coding expert by I understand the vesc packages pretty well.

2 Likes

@jack.luis May benefit from your VESC Package expertise. He’s expressed desire for something eskate focused, with the ease of use of Float Package.

2 Likes

We just really need a real esk8 setup wizard

3 Likes

FYI, difference between something like float package and an esk8 setup wizard is float package is more specific on what the board setup is; one esc, one motor, IMU driven, current control. An esk8 setup wizard on the other hand would need multi-esc, multi-motor, different types of remotes, different control schemes. Much more complicated and requiring more expertise than I have.

1 Like

I personally don’t trust software fully; Some hardware solution has to be in palace as a fail safe to ensure the imu data is accurate Maybe a reed switch and then a magnet in your shoe. This would be a pretty inexpensive solution. The only downside is you have to put a magnet in your heel. Standard FSR sensors are fairly reliable. I have some gosting on stock boards with aftermarket sensors but not too many issues with vesc. With pull-down resistors, I have never had any issue.