I built something much like that as my diploma thesis many years ago. The arm does not only work with the weight pulling down, but accelerating the weight to the left or right does create a force in the opposite direction and hence a momentum in the opposite direction that you want. It will work much better when you mount the weight on the bottom so that it is as close as possible to the ground.
But that force is from the acceleration, not the movement, so low-pass filtering the control signal should help. -- maybe why he had better luck controlling it manually: he's too slow.
@@gmaxwell Seems like the control loop update rate and/or bandwidth might've been even slower than that. It's tricky to find a compromise between sampled outputs (servo PWM at modest frequency and therefore, presumably, update rate) and good dynamics; it can be easy to get jerky movement, or too much phase shift, especially when noisy inputs need to be filtered (a median filter may help for the ADC). Even harder to characterize what the actual transfer function of a human controller is; maybe there's a zero in there, or sensitivity to velocity or acceleration, that hasn't been captured in the PID yet.
I am lesrning this in physics right now. You are much clearer than my teacher. I wish that he did the same models as you lol. Thank you very much for everything :)
You may want to add a low pass filter to the output of control loop. The random noise causing it to become unstable is often caused by noise exaggerated by the derivative term. You can fix that by decreasing your derivative gain, but that has the side effect of making your control lag behind more. You can also apply the filter to the sensor data before it is sent to the control loop. This is generally better as it allows you to adjust the filter for each sensor, but is more work and likely not necessary here
The cause of the oscilations at 10:40 is not feedback loop lag! Not sure if you just simplified it for the video, but simply using the axis' of the accelerometer (At 9:17) of the IMU (MPU6050) to calculate the tilt angle only works for situations with constant velocity. The accelerometer will measure total accel (gravity vector plus kinetic acceleration), this causes issues when moving/accelerating producing false angle measurements. Since your control output results in an acceleration of the accelerometer, it will cause the measured tilt angle to be incorrect and attempt to correct for the false disturbance in turn resulting in the oscilations seen at 10:40. The solution is some kind of sensor fusion of the accelerometer and gyroscope (Simplest ist complementary filter).
One simple change that would add to the stability is to change the axis that the shift weight swings on. If you swing it like a pendulum it will lower the center of gravity on the shifts, keeping the reactive force at bay. The only caveats would be distance to the ground and power of the shifting motor which could both be reduced by varying the axis angle from vertical.
If my understanding of the physics involved here is correct, for the bike vehicle, you don't need the weight arm, just steer the bike into the direction of tip, slightly over correcting, so that you have margin to resume your desired course.. For turning without the weight arm you just need to understand you a bike (motor or otherwise) is steered: 1) The Front Wheel Steering Angle is set to some value opposite the desired turn direction, causing the bike to lean towards the desired turn direction. This is called counter steering 2) The FWSA is then set to the a value in the same direction as the desired turn, starting the turn. 3) As the turn continues, the FWSA is modulated to maintain the desired lean angle 4) Just before the turn is ended the FWSA is increased in the direction of lean, bringing the bike back to vertical, ending the turn. In short, the you steer the front wheel of a bike to adjust the lean angle, and adjust the lean angle to change the direction of travel. The control algorithm for this would look something like (I think, I’ve never done anthing like this, only have a good understanding of the physics of a bike, and watched several James Bruton videos on balancing robots): DesiredTravelHeading == RadioControllerSteeringAxis + DesiredTravelHeading TravelHeadingPID(input[IMU_CompassHeading], SetPoint[DesiredTravelHeading], Output[DesiredLeanAngle]) LeanAnglePID(Input[IMU_RollAngle], Setpoint[DesiredLeanAngle], Output[FrontWheelSteeringAngle])
When dealing with instability, the Derivative term should be under special scrutiny as(depending on the implementation) it has a tendency to amplify noise (the analog potentiometer choice is what I think saves the day) The integral action is needed to drive the error to 0, as a PD alone can’t do it, you can only get it close with high gain. If I were you I would try adding some Ki to get rid of the dc error and drop Kp and Kd as needed to get the system stable. However for cornering (especially at high speeds) I suspect the main limit will be the speed of the analog servo itself
I've never had much success tuning PID controllers using the D term. It's only really been helpful where the loop has some delay. As you say, the D term is terrible with noise.
@@axelBr1 The D term is very situational, and not used very frequently (in motor control for example is basically never used) technically the derivative gain enhance yout phase margin at the expense of worsening your gain margin, thus you can theoretically use it to be able to push the P and I gain harder. It can also improve settiling time. The problem with derivative action is that the derivative itself amplifies high frequency noise (it is basically a high pass filter) as such pure derivative action in a single feedback sensor scenario is not viable so there are two alternatives 1) use a second sensor that directly senses the derivative, for example It is fairly common in aerospace for attitude control system where you get the accelleration from an accellerometer and rate of rotation from a gyro, no math needed, however this is expensive as you have to buy 2 sensors 2) you add a filter term to the derivative that limits it's bandwidth to the region of interest, thus cutting down on HF noise, however this is another parameter to tune, and also the more you filter, the less usefull your derivative
Can you program in an "averaging" of the gymbal, this way it reduces the jitter to the counter weight...this way it slowly over time moves the arm rather than jerkily slams it over Very very cool, and I also thought maybe the weight can be on a linear rail sliding back and forth with a screw rather than an arm..., oh and 3D print the wheel with a groove and slap a rubber oring on it...traction solved, unless you run it on water or slick surfaces So awesome! Keep em coming!!!!
Your conclusion at the end about trim ballast is exactly correct, you want to use the gyroscope for control and you can actually use the whole vehicle or inverted pendulum as the ballast if you intentionally hold it at an off angle for a while you can use that too unwind Your Gyro angle and avoid saturation. It’s also possible to use this data to lean in the returns and avoid having to manually correct for the maximum size using gravity to advantage to keep minimized the key here, but it does require a lot more thinking or at least a decent linear model of the dynamics, also I’m using voice to text so hopefully this makes any sense but I’m on the highway so deal with it
absolutly love it! auto o-rings can get to a couple of inches for tires. put an angle of the front fork for ease of forward control. arc the weight over the top. this is a bearing and servo torque planning nightmare. you are beating the snot outta me.
I was gonna mention that wobbly front wheel, but you already did toward the end of the video. The static test at 10:37 showed how the lateral wobble of the front wheel was simultaneously being compensated by the weight servo, indicated by the herky-jerky movements of both the weight and front wheel. I'm suspecting the instability in performance is due to the center of gravity changing quickly due to the offset of the front wheel during the wobble, but I'm a definitely not a physics professor and only know enough to be dangerous. I'd like to see the same system mounted to a more structurally sound bicycle, I bet it would run a lot smoother. That's a pretty freakin' cool project, by the way!
With just about 1 update per second it is a miracle that it works at all. BTW. You can always compensate for the lack in programming skills by getting more powerful hardware. That's what entire industry is doing since forever. I would recommend something with FPU.
Love the video! And I am sure you're already good on ideas for improvements, but I need to get these ideas out of my head. For the weight shifting, you could add a second mirrored arm opposite the gyro to cancel out the weight shift torque (though this would eat into your electronics space). Then for the wheel stuff, you could have the current "front" wheel as the back wheel and do back-end steering. This lets the traction wheel be more stable and will help reduce turning errors and crashes such as the one seen at 12:20. I cant wait to see how far you take this!
Some quick tips to reduce the latency of your control loop would be to enable interrupts on the MPU-6050 and use the INT pin to fire a pin change interrupt on the Arduino and to use either reduced size floating point precision, fixed precision, or even a higher performance microcontroller (STM32, ESP32, or really anything with an FPU or wider ALU than 8 bit). Consider adding a median filter or sliding window average on the tilt potentiometer if you aren't already, and if you're bored, take a look at free running mode for the ADC to supersample with a very low performance impact.
I think you could use the entire bike as it's own counterweight - with a raked front fork and rapid steering control. Like a push bike rider who is not moving forwards/backwards. Then tune steering angle to counter tilt/velocity. If the "chassis" mass is not high enough for good control authority then additional mass/lever arm can be added to the front forks.
Something to note is that shifting a weight back and forth creates an opposite torque on the body. If you are leaning to the left, and you move a mass equal to yourself to the right to bring your center of gravity to the right so you stabilize, you're ALSO pushing against an equal mass of yourself, which by Newton's laws, reminds us that you are now pushing yourself even further to the left. It's wild if you look at a graphed simulation for CG as you swing the arm back and forth (or use a linear motor) because you initially fall even MORE to the side you're already falling toward as you push 'away' the mass, and THEN gravity's effect takes over the mass once you stop moving it. A similar issue happens when making segway-style balancing devices: if the rider is falling forward, by nature of driving the wheels forward, conservation of angular momentum means that the unit as a whole (including your body) will pivot around the CG, causing your gyros to read a backwards rotation that is indistinguishable from actually falling backwards. Professional mass-market products compensate for this by actually doing an insane amount of math simulation in realtime to calculate the mass 'on-board' and then calculate, based on that, exactly how much it will rotate backward for any given amount of forward acceleration. For smaller balancing robot toys and such, this is less of an issue because the mass is permanently the same, give or take a few dozen grams for different battery types, though as an interesting side note, Wowee released a little self-balancing toy robot that had a tray you could load things onto, and a little bluetooth app to drive it around, and with enough sniffing of the bluetooth packets, someone was able to turn it into a scale, albeit a very poorly calibrated and inaccurate one, to calculate approximations of the weight placed on its tray just due to how it measured its own difference in rotational acceleration when driving forward/backward.
Talks about the momentum bringing the vehicle to the other side so I think to myself "I think you're going to have to use a PID loop to adjust the amount of correction you........ aaaand he's done it never mind" 😂
A PID control law is a *really* bad choice for something like this, where the assumptions of linearity and time-invariance is violated. But even when your system can be usefully reduced to fit those limitations, PID control is still *never* the optimal choice, except for extremely simplistic toy problems. Its *only* advantage is that it can be implemented with only a very simple analog computer (depending on whether you need to compute the derivative/integral terms or if you're able to receive them as inputs, in which case you might only need a single summation device), however this isn't really relevant anymore, since digital microcontrollers capable of millions of instructions par second can easily be had today for only a couple of cents.
@@mortlet5180 I assume that the issue is that the direction of the force changes depending on the turn radius? Couldn't you just include that as a parameter in the control loop?
No, even ignoring the issues related to turning and the bank angle required to avoid slipping, one of the biggest issues is that the rotational inertia of the system (how it responds to a given applied moment) changes non-linearly according to the balance weight's position. The second showstopper is the non-linear response of the servo as it tries to swing the weight around. Even if it could be effectively modeled and controlled as a second-order lagging actuator, the problem is that we don't want to control the angle of the stepper motor, we want to control the vehicle's attitude. Unfortunately, we have a *lot* of inter system cross-coupling between things like: The roll dampening gyro coupling due to friction in the bearings and reaction forces from the motor; The stepper motor's angular acceleration imparting both a torque in the roll and yaw axes as well as a side force that gets transmitted to the wheels from the very top of the vehicle; Flexing of the 3D-printed plastic under the relatively large forces; Additionally, the instant that the vehicle starts moving (even in a straight line), the entire system changes again to one where any reaction force about the roll axis will produce a gyroscopic counter force from the wheels, proportional to the vehicle's linear speed over the ground. Please don't misunderstand, I'm not saying the issue is the physical design of the vehicle nor the materials that it's made from. These things are already fixed as far as the control system is concerned and the fact that he could acheive acceptable performance via manual control also shows that the vehicle *is* controllable as it stands. I just don't like it when people popularize the use of PID control in the 21'st century, because then anyone that comes across it without any prior knowledge or experience, will believe that PID control is what they should try to use for their project as well; that invariably results in a lot of lost time and frustration from searching the entire parameter space while trying to tune something that doesn't even have a solution, culminating in a final implementation that either never properly works or is just deemed 'good enough' because of how much time and effort they've already spent on getting to that point. In my opinion, PID control is something that should *ONLY* ever be taught in a professional setting, where it is used to motivate why better techniques were developed and to facilitate learning about historical hardware limitations that are simply not applicable today.
Dude, to me You are the most talented (and funny) tinkerer on my radar. I even like Your plugs because of the quirky, always pissed looking animations. Your math and stuff (again) is way over my paygrade but it´s fun to watch. Although I like Your cold adventure better, You seem so close on that. Don´t matter: this channel is very much fun to me. Kind Regards
Assuming you had an idea of what the front wheel angle and current speed was, you could adjust the control loop to try to hold the bike at the neutral point rather than upright. (In other words, leaning into turns.)
Add Kalman filter to get accurate angle data while swinging and incorporate acceleration generated by accelerating moving mass and it'll work perfectly
Like your project, every gyroscope-related project is indeed interesting. In my project the control can be realized just by a potentiometer to measure the precession, you do not need other measurable variables such as IMU6050, etc.
I think you can simplify this all the way back down to only using the gyro alone and just improve the software. I would increase the refresh rate to help reduce any lag in the reaction time: program your gyro to overreact at the first sign of leaning so that it gets ahead of it, rather than that long delay of lagging behind the fall... Then, once you cause the bike to start moving in the opposite direction, make your gyro counteract the momentum by meeting the motion in the center again, rather than waiting for the bike to be leaning in the opposite direction before it finally reacts again. So not only react to left lean and right lean: but also immediately start a counter reaction as soon as it changes direction. Again, your triggers must be when it tilts, but also immediately when it changes direction. So if you're leaning left and it overacts so hard that it starts sending the bike back right, as soon as that direction changes, the gyro should immediately start counteracting to the LEFT again.. It's counter intuitive because why would you want your weight to be going left when your bike is still leaning left: but that's how you have to do it to get ahead of the momentum.
If you have any drive belt (eg GT2 from a printer. It wont be GT2 but injets have drive belts in em if you have an old dead one laying around) wrap it around the drive wheel. Shave down the nubs for less jiggle on flat surfaces, but the rubber should net you plenty of traction.
I built a drone controller for my thesis. I believe you control system is more appropriately called "state feedback" rather than PID, since you are directly collecting angle rate data rather than differentiating the error rate, which is not the same particularly in discrete time. Like you, we also found that controlling a double-integrator system in discrete time is impossible without rate data (with math and everything but I forgot).
The center of gravity can be shifted by changing the angle of inclination of the entire structure. It is necessary to implement a gyroscope drive. Having reached some small limit, it is necessary to pull the gyroscope structure in the opposite direction.
Wide rubber bands on the wheels for traction. You can use a bolt & brass bushing for the steering kingpin. You should add a bit of caster to the front wheel and see if the natural stabilization from that passive gyro can do the trick without fancy controls.
Been missing your videos, love that it works so well already that it's just refinement 😁 have you thought about using a resistive load from the gyroscope that sends flywheel energy back to the battery to both slow it down and speed it up to act as another "nudge" balancer? It might make it much easier to turn using that method with your extra weight shift. Anyways, love the video have a nice weekend👋
Great work, but don't forget on a bike a lot of the turning action comes from leaning into the turn. Would be cool to see an intentional lean while turning added to the controls.
Have you heard of the DARPA self steering bullet? This tech reminds me a lot of that, just on a bigger scale... could be a cool concept for you to explore! loved the video btw
I think it would really benefit from an integral term in the control loop. Not having one means you'll have a non-zero steady-state error, which will make the thing slowly tilt until it's going fast enough for the other error terms to gather up enough strength so that the control loop corrects it. This results in an unstable system.
I see from your earlier monorail vid with two reaction wheels that you roughly replicated the same feedback loop of the real Brennan monorail. Think it would have worked quite a lot better with the same heavier reaction wheel you used here. A heavier and faster spinning wheel slows down precession making your servo driven reactions all the more stable.
You don't need integral gain because the mechanical response from weight position to chassis angular position is already a double integrator. Second derivative might help. Also as you swing the weight right it creates a reaction force to the left as the weight is moving, only to switch in direction once the weight stops moving is hanging there. This kind of sign flip is very destabilizing, but I think your gyro is masking the initial reaction force so that it can work.
Nice video :) thank you. Quick tip, pid controller are rarely good with static nonlinearities such as mechanical gap, friction etc. Why not try a sliding mode controller or maybe an active disturbance rejection controller or alike. There are a million alternatives to a pid :)
thankyou love your effort here and i feel like a magnetic coupling to a suspended weight from one side of the gyro gives you ready made self adjusting feedback loop if you allow the gyro to rotate around the axis ...also consider x3 gyros with the payload in the center and a magnetic coupling attaching the one side of x3 gyros to the center weight food for thought eh
You should be able to get rid of the weight shifting servo and use the steering servo some clever control logic to actively balance it. Just needs active movement forward/backwards to work (to stand still, just move forward/backwards by an inch or so).
I'm a big fan of your videos, I've been subscribed for a while. Since it's happened more than a couple of times now, I wanted to let you know that something about your thumbnails (especially those, like this one, that feature a cut-out image on your "default" background) makes them nigh invisible to me 😕 every time you put out a new vid, it inevitably takes me at least a few days to get to it, if at all -- and when I finally do, I end up realizing that I'd inadvertently scrolled past it multiple times over the previous days...and while on a personal level, this could easily be remedied by, for example, turning on notifications, I'm letting you know because if this is regularly happening for me, I'm sure I'm not the only one. Unfortunately I am neither a creator nor a graphic designer, so I can't give you any legitimate advice as to what you might change; but if I had to make a few suggestions based solely on my intuition, I would say trying different fonts, using a different font color than white, adding secondary text in a different color, and/or adding more color variation on the thumbnails which use your "default" template. But there's a decent chance I have no idea what I'm talking about insofar as that goes. Anyway, hope you don't take this the wrong way -- I just want as many people to see your awesome vids as possible!
This has probably been mentioned already… but front fork angle makes a huge difference for turning stability on bikes. A vertical front fork would be doing this thing zero favours.
I need to try feeding the _measured_ D term into my PID loops now. I've always just calculated it from the feedback/error against the previous iteration, but this could be interesting. 🤔
Sick video! Do you think you could use the lipo at the counterweight? Assuming you probably wouldn't crack the wire or insulation from fatigue, it could work well! Edit: Just got to that part of the video lol
You should, theoretically, not need to have the "trim" at all. If the gimbal is getting close to lock, then have it over-correct, so that the entire device starts tilting the other way.
The government fears the idea of this man acquiring more complex means of production. If he can do this with basic shop tools, a 3d printer, and AliExpress grade parts, imagine what he could do with a CNC and high quality parts
You can likely improve turning performance by giving the arduino some data on the desired/current steering angle so it can compensate for and lean into the turn.
Fridge guy is now gyroscopic guy???
always has been just look back in the channel
Pretty soon we will have a self driving and balancing cryo-cooler!
He is pirate!
I thought he was submarine guy?
Next thing you know he's seasoning cutting boards with Adam Ragusea.
This man has perfected the art of high end "shitty" engineering. If it looks shit but it works it aint shit.
Same can't be said about the Cybertruck.
for real. I fell like this guy knows something about every topic lol.
This is exactly how we prototype in industry.
@@Spencer_Spwhich industry lol. The monorail industry?😂
@@IamProFish engineering in general
He's not ugly, he's doing his best for you because you made him.
I love the amout of extrapolation physics gives you from just a few known variables it blows my mind how much we can accurately predict
I built something much like that as my diploma thesis many years ago. The arm does not only work with the weight pulling down, but accelerating the weight to the left or right does create a force in the opposite direction and hence a momentum in the opposite direction that you want. It will work much better when you mount the weight on the bottom so that it is as close as possible to the ground.
But that force is from the acceleration, not the movement, so low-pass filtering the control signal should help. -- maybe why he had better luck controlling it manually: he's too slow.
@@gmaxwell Seems like the control loop update rate and/or bandwidth might've been even slower than that. It's tricky to find a compromise between sampled outputs (servo PWM at modest frequency and therefore, presumably, update rate) and good dynamics; it can be easy to get jerky movement, or too much phase shift, especially when noisy inputs need to be filtered (a median filter may help for the ADC). Even harder to characterize what the actual transfer function of a human controller is; maybe there's a zero in there, or sensitivity to velocity or acceleration, that hasn't been captured in the PID yet.
How can someone be so frickin smart, but also such a good communicator and entertainer?!
Amazing job friend, please don't stop doing this
but HR want an excited team player, sorry ;)
I am lesrning this in physics right now. You are much clearer than my teacher. I wish that he did the same models as you lol. Thank you very much for everything :)
My brain is too smooth for this video.
no its not.
Where did you get lost?
That's the smoothest way of calling someone dumb 😂
The cybertruck joke was apt 😂
wake up babe, hyperspace pirate uploaded
For the last time, It's BEN, not babe..
Wake up babe! BBQ is done...hyperspace pirate...nice. hi ben
Yeet
Your test-bed is so cute, with it's toddler level reaction at the end.
You may want to add a low pass filter to the output of control loop. The random noise causing it to become unstable is often caused by noise exaggerated by the derivative term. You can fix that by decreasing your derivative gain, but that has the side effect of making your control lag behind more.
You can also apply the filter to the sensor data before it is sent to the control loop. This is generally better as it allows you to adjust the filter for each sensor, but is more work and likely not necessary here
The cause of the oscilations at 10:40 is not feedback loop lag! Not sure if you just simplified it for the video, but simply using the axis' of the accelerometer (At 9:17) of the IMU (MPU6050) to calculate the tilt angle only works for situations with constant velocity. The accelerometer will measure total accel (gravity vector plus kinetic acceleration), this causes issues when moving/accelerating producing false angle measurements. Since your control output results in an acceleration of the accelerometer, it will cause the measured tilt angle to be incorrect and attempt to correct for the false disturbance in turn resulting in the oscilations seen at 10:40. The solution is some kind of sensor fusion of the accelerometer and gyroscope (Simplest ist complementary filter).
One simple change that would add to the stability is to change the axis that the shift weight swings on. If you swing it like a pendulum it will lower the center of gravity on the shifts, keeping the reactive force at bay. The only caveats would be distance to the ground and power of the shifting motor which could both be reduced by varying the axis angle from vertical.
If my understanding of the physics involved here is correct, for the bike vehicle, you don't need the weight arm, just steer the bike into the direction of tip, slightly over correcting, so that you have margin to resume your desired course..
For turning without the weight arm you just need to understand you a bike (motor or otherwise) is steered:
1) The Front Wheel Steering Angle is set to some value opposite the desired turn direction, causing the bike to lean towards the desired turn direction. This is called counter steering
2) The FWSA is then set to the a value in the same direction as the desired turn, starting the turn.
3) As the turn continues, the FWSA is modulated to maintain the desired lean angle
4) Just before the turn is ended the FWSA is increased in the direction of lean, bringing the bike back to vertical, ending the turn.
In short, the you steer the front wheel of a bike to adjust the lean angle, and adjust the lean angle to change the direction of travel.
The control algorithm for this would look something like (I think, I’ve never done anthing like this, only have a good understanding of the physics of a bike, and watched several James Bruton videos on balancing robots):
DesiredTravelHeading == RadioControllerSteeringAxis + DesiredTravelHeading
TravelHeadingPID(input[IMU_CompassHeading], SetPoint[DesiredTravelHeading], Output[DesiredLeanAngle])
LeanAnglePID(Input[IMU_RollAngle], Setpoint[DesiredLeanAngle], Output[FrontWheelSteeringAngle])
When dealing with instability, the Derivative term should be under special scrutiny as(depending on the implementation) it has a tendency to amplify noise (the analog potentiometer choice is what I think saves the day)
The integral action is needed to drive the error to 0, as a PD alone can’t do it, you can only get it close with high gain.
If I were you I would try adding some Ki to get rid of the dc error and drop Kp and Kd as needed to get the system stable.
However for cornering (especially at high speeds) I suspect the main limit will be the speed of the analog servo itself
I've never had much success tuning PID controllers using the D term. It's only really been helpful where the loop has some delay. As you say, the D term is terrible with noise.
@@axelBr1 The D term is very situational, and not used very frequently (in motor control for example is basically never used)
technically the derivative gain enhance yout phase margin at the expense of worsening your gain margin, thus you can theoretically use it to be able to push the P and I gain harder. It can also improve settiling time.
The problem with derivative action is that the derivative itself amplifies high frequency noise (it is basically a high pass filter) as such pure derivative action in a single feedback sensor scenario is not viable so there are two alternatives
1) use a second sensor that directly senses the derivative, for example It is fairly common in aerospace for attitude control system where you get the accelleration from an accellerometer and rate of rotation from a gyro, no math needed, however this is expensive as you have to buy 2 sensors
2) you add a filter term to the derivative that limits it's bandwidth to the region of interest, thus cutting down on HF noise,
however this is another parameter to tune, and also the more you filter, the less usefull your derivative
Can you program in an "averaging" of the gymbal, this way it reduces the jitter to the counter weight...this way it slowly over time moves the arm rather than jerkily slams it over
Very very cool, and I also thought maybe the weight can be on a linear rail sliding back and forth with a screw rather than an arm..., oh and 3D print the wheel with a groove and slap a rubber oring on it...traction solved, unless you run it on water or slick surfaces
So awesome! Keep em coming!!!!
If you know the steering angle and speed you can calculate the centripetal force, all you have to do is lean into the turn the appropriate amount
Your conclusion at the end about trim ballast is exactly correct, you want to use the gyroscope for control and you can actually use the whole vehicle or inverted pendulum as the ballast if you intentionally hold it at an off angle for a while you can use that too unwind Your Gyro angle and avoid saturation. It’s also possible to use this data to lean in the returns and avoid having to manually correct for the maximum size using gravity to advantage to keep minimized the key here, but it does require a lot more thinking or at least a decent linear model of the dynamics, also I’m using voice to text so hopefully this makes any sense but I’m on the highway so deal with it
Adding the battery to the weight shift was genious
absolutly love it! auto o-rings can get to a couple of inches for tires. put an angle of the front fork for ease of forward control.
arc the weight over the top. this is a bearing and servo torque planning nightmare. you are beating the snot outta me.
Very impressive first try. And the schedule you worked under is insane. Hats off to you
I love it, the anvil as stopper is gorgeus.
Congrats on (2^8)*10^3 subscribers!!!
I was gonna mention that wobbly front wheel, but you already did toward the end of the video. The static test at 10:37 showed how the lateral wobble of the front wheel was simultaneously being compensated by the weight servo, indicated by the herky-jerky movements of both the weight and front wheel. I'm suspecting the instability in performance is due to the center of gravity changing quickly due to the offset of the front wheel during the wobble, but I'm a definitely not a physics professor and only know enough to be dangerous. I'd like to see the same system mounted to a more structurally sound bicycle, I bet it would run a lot smoother. That's a pretty freakin' cool project, by the way!
I absolutely adore how you tinker with stuff that can remove limbs.
Please never stop.
You're awesome!
With just about 1 update per second it is a miracle that it works at all. BTW. You can always compensate for the lack in programming skills by getting more powerful hardware. That's what entire industry is doing since forever. I would recommend something with FPU.
I like the sound of gyros spinning up in the morning.
It's cool that you show the math behind it!
I thought I only loved your channel for the awesome coolers but turns out I love anything you do. Thanks buddy!
Love the video! And I am sure you're already good on ideas for improvements, but I need to get these ideas out of my head. For the weight shifting, you could add a second mirrored arm opposite the gyro to cancel out the weight shift torque (though this would eat into your electronics space). Then for the wheel stuff, you could have the current "front" wheel as the back wheel and do back-end steering. This lets the traction wheel be more stable and will help reduce turning errors and crashes such as the one seen at 12:20.
I cant wait to see how far you take this!
Alternate title: How to avoid adding a third wheel to a bike by adding a third wheel.
Perfect timing for a 5 hour layover 😄
I love hyperspace more than I love my children
I love how it just defiantly flips over for no reason.
High-rise buildings have that too. For example, a big ball on bearings to counteract and compensate tilt...
Some quick tips to reduce the latency of your control loop would be to enable interrupts on the MPU-6050 and use the INT pin to fire a pin change interrupt on the Arduino and to use either reduced size floating point precision, fixed precision, or even a higher performance microcontroller (STM32, ESP32, or really anything with an FPU or wider ALU than 8 bit). Consider adding a median filter or sliding window average on the tilt potentiometer if you aren't already, and if you're bored, take a look at free running mode for the ADC to supersample with a very low performance impact.
Use a Linear servo/voice coil actuator to shift the weight only in the perpendicular axis instead of being rotated
I think you could use the entire bike as it's own counterweight - with a raked front fork and rapid steering control. Like a push bike rider who is not moving forwards/backwards.
Then tune steering angle to counter tilt/velocity.
If the "chassis" mass is not high enough for good control authority then additional mass/lever arm can be added to the front forks.
Something to note is that shifting a weight back and forth creates an opposite torque on the body. If you are leaning to the left, and you move a mass equal to yourself to the right to bring your center of gravity to the right so you stabilize, you're ALSO pushing against an equal mass of yourself, which by Newton's laws, reminds us that you are now pushing yourself even further to the left. It's wild if you look at a graphed simulation for CG as you swing the arm back and forth (or use a linear motor) because you initially fall even MORE to the side you're already falling toward as you push 'away' the mass, and THEN gravity's effect takes over the mass once you stop moving it.
A similar issue happens when making segway-style balancing devices: if the rider is falling forward, by nature of driving the wheels forward, conservation of angular momentum means that the unit as a whole (including your body) will pivot around the CG, causing your gyros to read a backwards rotation that is indistinguishable from actually falling backwards. Professional mass-market products compensate for this by actually doing an insane amount of math simulation in realtime to calculate the mass 'on-board' and then calculate, based on that, exactly how much it will rotate backward for any given amount of forward acceleration. For smaller balancing robot toys and such, this is less of an issue because the mass is permanently the same, give or take a few dozen grams for different battery types, though as an interesting side note, Wowee released a little self-balancing toy robot that had a tray you could load things onto, and a little bluetooth app to drive it around, and with enough sniffing of the bluetooth packets, someone was able to turn it into a scale, albeit a very poorly calibrated and inaccurate one, to calculate approximations of the weight placed on its tray just due to how it measured its own difference in rotational acceleration when driving forward/backward.
Those last 5 seconds were hilarious. Thanks for this vid!
As a professional grass cutter your sidewalk edge looked pretty good 👌🏿
edging pro tip
Talks about the momentum bringing the vehicle to the other side so I think to myself "I think you're going to have to use a PID loop to adjust the amount of correction you........ aaaand he's done it never mind" 😂
A PID control law is a *really* bad choice for something like this, where the assumptions of linearity and time-invariance is violated.
But even when your system can be usefully reduced to fit those limitations, PID control is still *never* the optimal choice, except for extremely simplistic toy problems.
Its *only* advantage is that it can be implemented with only a very simple analog computer (depending on whether you need to compute the derivative/integral terms or if you're able to receive them as inputs, in which case you might only need a single summation device), however this isn't really relevant anymore, since digital microcontrollers capable of millions of instructions par second can easily be had today for only a couple of cents.
@@mortlet5180 do you have an alternative?
@@mortlet5180 I assume that the issue is that the direction of the force changes depending on the turn radius?
Couldn't you just include that as a parameter in the control loop?
No, even ignoring the issues related to turning and the bank angle required to avoid slipping, one of the biggest issues is that the rotational inertia of the system (how it responds to a given applied moment) changes non-linearly according to the balance weight's position.
The second showstopper is the non-linear response of the servo as it tries to swing the weight around. Even if it could be effectively modeled and controlled as a second-order lagging actuator, the problem is that we don't want to control the angle of the stepper motor, we want to control the vehicle's attitude.
Unfortunately, we have a *lot* of inter system cross-coupling between things like:
The roll dampening gyro coupling due to friction in the bearings and reaction forces from the motor;
The stepper motor's angular acceleration imparting both a torque in the roll and yaw axes as well as a side force that gets transmitted to the wheels from the very top of the vehicle;
Flexing of the 3D-printed plastic under the relatively large forces;
Additionally, the instant that the vehicle starts moving (even in a straight line), the entire system changes again to one where any reaction force about the roll axis will produce a gyroscopic counter force from the wheels, proportional to the vehicle's linear speed over the ground.
Please don't misunderstand, I'm not saying the issue is the physical design of the vehicle nor the materials that it's made from. These things are already fixed as far as the control system is concerned and the fact that he could acheive acceptable performance via manual control also shows that the vehicle *is* controllable as it stands.
I just don't like it when people popularize the use of PID control in the 21'st century, because then anyone that comes across it without any prior knowledge or experience, will believe that PID control is what they should try to use for their project as well; that invariably results in a lot of lost time and frustration from searching the entire parameter space while trying to tune something that doesn't even have a solution, culminating in a final implementation that either never properly works or is just deemed 'good enough' because of how much time and effort they've already spent on getting to that point.
In my opinion, PID control is something that should *ONLY* ever be taught in a professional setting, where it is used to motivate why better techniques were developed and to facilitate learning about historical hardware limitations that are simply not applicable today.
@@mortlet5180 Thank you for the great answer. 👍
Dude, to me You are the most talented (and funny) tinkerer on my radar. I even like Your plugs because of the quirky, always pissed looking animations.
Your math and stuff (again) is way over my paygrade but it´s fun to watch. Although I like Your cold adventure better, You seem so close on that.
Don´t matter: this channel is very much fun to me. Kind Regards
Assuming you had an idea of what the front wheel angle and current speed was, you could adjust the control loop to try to hold the bike at the neutral point rather than upright. (In other words, leaning into turns.)
Add Kalman filter to get accurate angle data while swinging and incorporate acceleration generated by accelerating moving mass and it'll work perfectly
You want to use two control loops. One for position and that feeds into an angular rate controller. This is give you better/ smoother control.
Like your project, every gyroscope-related project is indeed interesting. In my project the control can be realized just by a potentiometer to measure the precession, you do not need other measurable variables such as IMU6050, etc.
I think you can simplify this all the way back down to only using the gyro alone and just improve the software. I would increase the refresh rate to help reduce any lag in the reaction time: program your gyro to overreact at the first sign of leaning so that it gets ahead of it, rather than that long delay of lagging behind the fall... Then, once you cause the bike to start moving in the opposite direction, make your gyro counteract the momentum by meeting the motion in the center again, rather than waiting for the bike to be leaning in the opposite direction before it finally reacts again. So not only react to left lean and right lean: but also immediately start a counter reaction as soon as it changes direction. Again, your triggers must be when it tilts, but also immediately when it changes direction. So if you're leaning left and it overacts so hard that it starts sending the bike back right, as soon as that direction changes, the gyro should immediately start counteracting to the LEFT again.. It's counter intuitive because why would you want your weight to be going left when your bike is still leaning left: but that's how you have to do it to get ahead of the momentum.
Great video! Your engineering proficiency muddles my little brain.
If you have any drive belt (eg GT2 from a printer. It wont be GT2 but injets have drive belts in em if you have an old dead one laying around) wrap it around the drive wheel. Shave down the nubs for less jiggle on flat surfaces, but the rubber should net you plenty of traction.
I built a drone controller for my thesis. I believe you control system is more appropriately called "state feedback" rather than PID, since you are directly collecting angle rate data rather than differentiating the error rate, which is not the same particularly in discrete time. Like you, we also found that controlling a double-integrator system in discrete time is impossible without rate data (with math and everything but I forgot).
Very cool and fun video. Worked a treat.
The center of gravity can be shifted by changing the angle of inclination of the entire structure. It is necessary to implement a gyroscope drive. Having reached some small limit, it is necessary to pull the gyroscope structure in the opposite direction.
Wide rubber bands on the wheels for traction. You can use a bolt & brass bushing for the steering kingpin. You should add a bit of caster to the front wheel and see if the natural stabilization from that passive gyro can do the trick without fancy controls.
Oh, and for this to work right you need FORCE CONTROL on the steering, not position control. This means no rc servos for steering input!
Always entertaining.
Your neighbors must really wonder about you.😁
Been missing your videos, love that it works so well already that it's just refinement 😁 have you thought about using a resistive load from the gyroscope that sends flywheel energy back to the battery to both slow it down and speed it up to act as another "nudge" balancer? It might make it much easier to turn using that method with your extra weight shift. Anyways, love the video have a nice weekend👋
Great work, but don't forget on a bike a lot of the turning action comes from leaning into the turn. Would be cool to see an intentional lean while turning added to the controls.
There’s an excellent video on YT on the Brennan Monorail which was gyroscopically balanced weight shifting, from the 1920’s or so.
this would be a viable solution for building an electric dirt surfer/speedboard. I'm gonna do it.
Thsnks Pirate
You can add stability during travel by adding rake to the front fork/wheel.
Have you heard of the DARPA self steering bullet? This tech reminds me a lot of that, just on a bigger scale... could be a cool concept for you to explore! loved the video btw
I love your stuff man, so fun.
Impressively consistent spelling of receiver even on the schematic.
I think it would really benefit from an integral term in the control loop. Not having one means you'll have a non-zero steady-state error, which will make the thing slowly tilt until it's going fast enough for the other error terms to gather up enough strength so that the control loop corrects it. This results in an unstable system.
I see from your earlier monorail vid with two reaction wheels that you roughly replicated the same feedback loop of the real Brennan monorail. Think it would have worked quite a lot better with the same heavier reaction wheel you used here. A heavier and faster spinning wheel slows down precession making your servo driven reactions all the more stable.
You don't need integral gain because the mechanical response from weight position to chassis angular position is already a double integrator. Second derivative might help. Also as you swing the weight right it creates a reaction force to the left as the weight is moving, only to switch in direction once the weight stops moving is hanging there. This kind of sign flip is very destabilizing, but I think your gyro is masking the initial reaction force so that it can work.
It might actually be much easier to tune without the D term and include the I term. The D usually ruins everything.
I loved the ending!!! Just the ok bye! It made my day lol
Nice video :) thank you. Quick tip, pid controller are rarely good with static nonlinearities such as mechanical gap, friction etc. Why not try a sliding mode controller or maybe an active disturbance rejection controller or alike. There are a million alternatives to a pid :)
thankyou love your effort here and i feel like a magnetic coupling to a suspended weight from one side of the gyro gives you ready made self adjusting feedback loop if you allow the gyro to rotate around the axis ...also consider x3 gyros with the payload in the center and a magnetic coupling attaching the one side of x3 gyros to the center weight food for thought eh
You should be able to get rid of the weight shifting servo and use the steering servo some clever control logic to actively balance it. Just needs active movement forward/backwards to work (to stand still, just move forward/backwards by an inch or so).
love to see it!
Now that’s cool , the maths are above my level but really interesting thank you.
The fact that it takes all of this just to mimic a fraction of the stability of having more wheels is pretty demonstrative why we do that instead XD
Delightfully sane madness!
Thank you.
I'm a big fan of your videos, I've been subscribed for a while.
Since it's happened more than a couple of times now, I wanted to let you know that something about your thumbnails (especially those, like this one, that feature a cut-out image on your "default" background) makes them nigh invisible to me 😕 every time you put out a new vid, it inevitably takes me at least a few days to get to it, if at all -- and when I finally do, I end up realizing that I'd inadvertently scrolled past it multiple times over the previous days...and while on a personal level, this could easily be remedied by, for example, turning on notifications, I'm letting you know because if this is regularly happening for me, I'm sure I'm not the only one.
Unfortunately I am neither a creator nor a graphic designer, so I can't give you any legitimate advice as to what you might change; but if I had to make a few suggestions based solely on my intuition, I would say trying different fonts, using a different font color than white, adding secondary text in a different color, and/or adding more color variation on the thumbnails which use your "default" template. But there's a decent chance I have no idea what I'm talking about insofar as that goes.
Anyway, hope you don't take this the wrong way -- I just want as many people to see your awesome vids as possible!
0:51 I saw this shot on a Facebook post a few days ago and now by complete chance I’ve found the source on UA-cam :o
This has probably been mentioned already…
but front fork angle makes a huge difference for turning stability on bikes.
A vertical front fork would be doing this thing zero favours.
It would be cool/interesting to see if you could "replicate" the gyros from the Apollo CSM. Make it be able to track distant points, etc.
So cool! Is it possible to make the video longer?
would be nice to see how it performs with a servo to control the angle of the gyro instead of free tilt and a controlled counter weight ;)
I think it would be interesting if you can use the steering wheel + static gyro to balance.
This was a pretty cool project! If I may ask, though, whatever happened to that DIY submarine project you were doing a while back?
I need to try feeding the _measured_ D term into my PID loops now. I've always just calculated it from the feedback/error against the previous iteration, but this could be interesting. 🤔
Love it!
Sick video! Do you think you could use the lipo at the counterweight? Assuming you probably wouldn't crack the wire or insulation from fatigue, it could work well!
Edit: Just got to that part of the video lol
Take stering data send to front well as data to feedback loop
Very interesting and entertaining 👍
Mom the fridge man is back
Great job bro
You should, theoretically, not need to have the "trim" at all. If the gimbal is getting close to lock, then have it over-correct, so that the entire device starts tilting the other way.
The government fears the idea of this man acquiring more complex means of production.
If he can do this with basic shop tools, a 3d printer, and AliExpress grade parts, imagine what he could do with a CNC and high quality parts
Dude you could improve the quality of your wheels (as well as dumping a bit) by using an O-ring as contact surface (tire) with the ground
Fantastic work. Would rate-shaping the servo arm response help the stability of the counterweight?
The small pitch bumps are translated into roll 'bumps' via precession.
You can likely improve turning performance by giving the arduino some data on the desired/current steering angle so it can compensate for and lean into the turn.
Really neat
Humanity: invents 4 wheel vehicle
Hyperspacepirate: overengineer it to 2 wheel
Genius!