What do you make of this explanation (uni riding starts at 3:40)
I think the first part seems wrong about always pedaling back to get started moving forward, but the rest of the explanation seems semi-reasonable.
He’s just stopping and starting and of course you will automatically lean forward in that case. But you can start from a stand-still by just leaning forward, no need to ‘pedal back’ (whatever that means).
He doesn’t mean necessarily to pedal backwards but rather to apply pressure to the back pedal. You won’t truly appreciate this until you try to freewheel unicycle. But it would have been good to add one of those in that video for comparison since you either accelerate forwards, balance with body movement only, or brake(if you’re me the braking phase is just an instant upd but maybe one day I’ll figure it out).
I assume that by a stand still you mean being stationary with your centre of gravity exactly above the tyre contact patch. This is a so-called unstable equilibrium, but according to classical mechanics theory this situation can last forever. Now how do you go from there to a forward lean? I guess through a little bit of ‘pedal back’. This type of thing (moving the bottom end to one side to initiate a lean to the other side) is exactly the point of this video. So IMHO the need for ‘pedal back’ is correct.
Hey riders? Who gives a crap about unicycle physics? We do, right?
Well, I just watched this video.
My comments:
2.) Pedal back = driving one pedal down creates an action = rider “tilts back or whiplashes”
3.) An additional force needs to be applied to prevent falling on your back, either:
a.) A constant lean forwards.
b.) A momentary forward rock synchronized to each pedaling action
This should have been mentioned.
Oh there’s actually a lot more. Save it for another topic.
Especially about steering and lateral balance, which is “pedal clock drive direction and timing” controlled, as well as weight distribution from pedal to seat.
Not super complicated, but I hate how scientists need to “minimize” everything to a 2 dimensional sketch and a 5 minute lecture about CG and contact patch…slam
Oh, oh…, I’m one of those nerds interested in unicycle physics 
I’ve read quite a few papers on the subject. A nice quote from a very old (1989) MIT thesis by David W Voss is:
“Physically, in order for the unicyclist to change forward velocity, the wheel speed is slowed in order to generate a pitch error and then in recovery of this error, the new forward (increased) velocity is set. Similar reasoning is valid for the lateral motion - a heading change to the left is achieved by initially incurring a roll error by turning to the right, before recovering on the desired heading.”
[btw, I agree that the simple “pedal backwards to go forwards” sounds pretty silly].
I have a personal project on the back burner to develop a scripted SVG showing a schematic of a unicycle rider with animated pedal force graph as they maintain balance while moving forward at an approximately constant speed with minor bumps in the road (2D only, tire friction taken into account, but no body twisting, camber or gyro forces included).
In researching for this, I found a rather useful and concise paper, in case anyone is interested, for the maths:
[“The development of self-balancing controller for one-wheeled vehicles” by CN Huang in 2010 - pitch control only!]
The interesting/convincing thing is that several people have built controllers based on the theory, and they actually work.
Its me again… I have finished that vector graphics unicycle riding simulation and also a companion text document explaining it (and including lots of ugly mathematics).
I have linked to this in another topic (“quote of the day…”) because it also has a feature of showing text bubbles of observer to rider exchanges.
But I am also linking to it here as the simulation is a kind of video and it certainly is related to “physics of unicycling”.
The link is SVG Play Index
And the first two links on that page are:
https://flight.projectcomputing.com/v/unicycle_physics_maths.txt
https://flight.projectcomputing.com/v/unicycle_simulation.svg
In doing the rider control simulation (as opposed to the unicycle movement simulation) I certainly noticed that my simulated rider had to do the “allow a bit of forward fall before pedaling forward for increased speed”.
The mathematics are non-trivial, even when simplified, but maybe someone out there will enjoy it.
[ps, if you are interested in the simulation code, it is all visible, with some comments even, in the source code of the SVG, no obfuscation, minification or 3rd party library packages - right click in your browser to view the source.]
I’m happy to engage in discussion on the physics etc.
Interesting.
One thing I noticed is that the speed of reaction, especially at a RPM of 0 is slower then what it would be in real life. Seems a little slow to react and maybe that is why he crashes some times.
Also something that may make it look funny is that there seems to be no difference in the ability to react when the pedal are near horizontal compared to when they are near vertical. In real life most all the control is when the pedals are horizontal and almost none when vertical.
That’s awesome! I may put this to use in in my unicycle trainer that I talked about in another thread.
I made it this far before falling. I challenge anyone to go farther.
Thanks for your comments Jim.
In tinkering with this thing after getting it to work, all the changes I have made are in the rider simulation. The unicycle simulation is pretty much pure mathematics, but the rider simulation is more ad hoc. I want the unicycle to crash occasionally and I have tweaked the standard deviation of the various random “sensory” errors (eg pitch angle and torque estimation) when I have modified the code.
The higher falling rate at zero target cadence may be due to the introduced errors being absolute rather than proportional.
There is a 4 frames delay before the simulated user can react to the sensed data regardless of speed, but some of the apparent slow reaction may be because of the simulated rider “deliberately” allowing the pitch error to increase too much just so they have a window to change speed - possibly balance adjustment should be given greater priority over speed adjustment at low target speeds.
I think you are right about the pedal position being a bit unrealistic. There was a cutoff torque value which was dependent on crank angle which probably allowed more torque to be applied than a human would at angles near the “dead” positions (cranks vertical). I have now changed that so the rider is more constrained at these positions. And I think that “falls” at slow speeds now happen more frequently when cranks are near vertical.
But it will never be perfectly realistic - humans are hard to model!
I love the style! All ascii text, svg, js, two files, no dependencies.
Wow, the “unicycle trainer” sounds like an interesting venture!
Best wishes for that, and let us know how you are going.
Regarding the challenge of the simulation distance - unfortunately my slight modifications to the SVG script means that probably it is a bit harder to avoid falls now. In earlier (easier) versions I was probably the only user, and I had been able to “max out” the distance and time on various browsers/hardware, but not now!
I think the simulation performance can also be affected by the underlying hardware and by the strategy the browser engine uses to distribute CPU resources between an active animation other tasks (it probably works better if there are no other active tabs).
Thanks @newuser - heck, there’s also even a few old fashioned comments in the code - this is what you get when a grumpy untrusting old man (who learned programming with paper tape, cards and assembly language) does modern stuff
I have now made a few changes to the human rider simulation, re-arranged the position of some of the screen items (more compact, for a phone screen) and added a version number (now version 1.4).
@JimT , I have further addressed the horizontal crank issue by making the rider adjust the applied torque to preferentially go slightly towards horizontal rather than vertical (at slow speeds). It’s a bit interesting really, as the simulation had to be “taught” this behavior. Perhaps even real humans don’t do it immediately intuitively, but have to learn it? Anyway, I think now when he/she/they/it falls at slow speed, it is most often at the “dead spot”. Of course it is never going to do the usual “idle” of one foot down, and rocking back and forth over a fairly large arc - I guess that is a human “trick”.
The whole thing could be made super fancy by hooking it up to a simple artificial neural net (which I have used in the past) and training it, using “smoothness” and “distance to fall” as feedback, but I’m NOT going to do that.
The idea behind the “unicycle trainer” is to measure the rider inputs using electronic sensors and compare them with the computed optimal inputs required to stay upright. Your calculations can serve this latter purpose. Then the difference between the two could be displayed to the rider, like the RPM meter in your graphic.
I had a question about this statement in your paper:
“The desired state is phi=0 and vx is fairly constant at about 0 to 8 m/s.”
Isn’t the desired state phi>0 when riding forward, especially when riding faster? With phi>0, then gravity will be exerting a force tending to increase the pitch and rotating the frame clockwise (as seen in your graphic with the rider facing to the right).
But isn’t there a slight horizontal force exerted by the axle on the frame bottom end tending to rotate the frame counter-clockwise during a pedal downstroke? Is that what you meant by the “oscillation of the pitch angle”?
I feel like I am leaning forward most of the time when riding forward, especially when pedaling faster.
Regarding the “desired state of pitch”:
Just for fun, I temporarily changed (on my PC only) the target pitch angle in the simulation to 1 degree - the effect was that the rider very frequently crashed when starting, but if they didn’t, they were condemned to keep accelerating until the legs were a blur (in a constant fight against gravity). That doesn’t really prove anything of course.
In real life, there is wind resistance which requires a slight forward pitch to balance, and also rolling resistance has an effect - especially, say, if ploughing along sandy/muddy ground, significant torque is needed just to move at a constant speed, and this will require an average extra forward pitch. A hill climb also means constant torque application is needed and to stop this also tipping the unicycle backward, gravity has to be enlisted, meaning a slight forward pitch of the center of mass is needed.
So the rule is that if you need to put torque into the axle it has the primary desired effect at the wheel, but also an effect on the pitch of the system which has to be countered by gravitational force which needs an offset center of mass to take effect. The exact amount of compensatory pitch (and how to get it) is a bit tricky, but oddly enough we humans manage somehow to do it without even thinking!
Regarding the “pitch oscillation”:
This is just an artifact of our human physical inadequacy and our weird pedal cranks which means that even if we just want to cruise at a constant speed (with a small constant torque to overcome resistance), we cannot do it like an electric motor, we sway back and forth in time with the crank angle, but it doesn’t matter much, as long as balance is achieved on average.
Regarding computing optimal inputs for training a human:
I don’t think the code in my rider simulation would help. The code “rides” in a different way to a human and is an imperfect simulation. Humans are a crazy floppy bag of gooey stuff and bones, with a brain which constantly constructs short term riding targets (partly unconsciously) using recent and historical observations, and each human has different measurements, and setting up and strapping sensors would be expensive and difficult, and I reckon humans need to learn by observing the actual riding feelings (force, speed, position, body balance state) using their own real senses rather than observing a possibly faulty (and distracting?) artificial sensor. But having said that, I agree it would be great if there was some way that a “trainer” could be set up so learners would not be overly distracted by fear of injury and could learn aspects of riding in stages, but I think it may be a HARD problem. But @unibabyguy , I hope you persist with it, and good luck!
