I did something like this on my sc10.2 I made bellow air springs at each shock and wrapped each shock in a wire coil added a shock disc with 5 holes and ferro fluid. I used the valve/pump units from some blood pressure cuffs. A hall effect sensor and a small neo magnet to read each arm. A simple setup using a custom pcb and an arduino m0 with an imu and hall sensors tracking wheel speed in all 4 wheels
Nice. I like that setup. I was trying to figure out ways to get a small pump like that. Initially I was planning on hydraulic actuators. Which IMU did you use?
Ty for this working through this completely absorbing active suspension project! Obviously, it took someone with passion, patience and high intelligence to tackle such a beast, you are killing it! Please keep it coming...sub'd. Peace out.:)
Hi great project! Subscribed just for it. A few comments, as others have said, your servos will not have the speed to correct for road vibration. On flat tar lower control arm sees about 20hz, most suspensions can act on 1-4 hz. There are few research grade high speed active systems that try to work in the 20 hz range. At full scale the speed and force needed in the actuator results in something too big and costly, but it is coming, and it will change racing forever. Let the springs and dapaners suck up the high frequency stuff. What alot of active systems try to do is active body control, so just control body roll/pitch/yaw. This is in the frequency range that hydraulic or electric actuators can meet with today's technology. It also simplifies the control equation as you can use pid and height or even height and 3dof sensor.
Thanks. That makes a lot of sense on the vibration rates. Thanks for the info on the frequencies. I haven't found literature on the specific suspension frequencies ranges that active suspensions have been built to target. I really need to build a single wheel test rig to measure the frequencies and optimize my filtering and actuator damping. I'm leaning towards having an electronic force based actuator like a linear motor which won't need as much power at this scale versus a real automobile. Also I should be able to have a much higher frequency response versus the servos. I agree with your thoughts on just controlling the roll/pitch/yaw, particularly with an off-road rc car like this. I'm think I will implement a secondary spring system so the servo doesn't have to support the weight of the car and absorb the shock loads from jumps. The servos can handle this but they need a lot of current to do so (~2 amps each).
I managed to get a few BNO085 IMUs from Mouser last week. Keep looking! I'm curious if the servos can move fast enough to respond to high frequency bumps, like the gravel in the video. In my autonomous RC car project I'm modeling actual steering servo position, not just assuming the servos are at the intended position that was sent in the last PWM pulse. My model just uses basic linear interpolation of nominal servo velocity, but in your case it would probably be asymmetrical due to the normal force. It might be interesting to see the modeled servo position in your data logging, and see if that accounts for the undesired acceleration that you're seeing.
Thanks for the tip, I hadn’t seen the BNO085 before but it seems to be better than the BNO055 and available. The servos definitely don’t respond fast enough. I’m not an expert on this, but I’m using some filtering on the IMU and the encoders which gives me something like a 5ms sample period. Then I only command the servos to a new position every 20ms. But I did burn up two of the servos because I think I’m just sending them in opposite directions every few readings. Ideally I may need to get servos with feedback so I can read the current position and not just the commanded position.
@@IndeterminateDesign What's the frequency of bumps that you're seeing in the logs? i.e. how frequently does the sign of the vertical acceleration vector change, after subtracting gravity? I could believe you're hitting over 100 bumps per second on gravel, so that may exceed your 200Hz IMU sample rate, much less the 50Hz PWM signal. It may simply be the case that modern digital logic components aren't able to respond fast enough for this type of terrain. Have you tried it on terrain with fewer, larger bumps?
So I need to do some better logging, but when the library removes the gravity vector, it seems to be consistently ~0.5G when the car is not pitching or rolling. But as soon as the chassis rolls or pitches, and the gravity vector starts to pick up values from X&Y sensors it all goes wrong. So it makes the accelerometer data fairly messy, but I'm definitely registering over 100 bumps/sec. So when I integrate the acceleration to get the velocity, I implemented a "bleed" of about 2% so that the velocity always trends a bit towards 0 to hopefully eliminate the integration error. The larger the bleed the more erratic the velocity becomes and if it's too small it just overflows either positive or negative. The encoder data at the wheels is surprisingly clean, and I'm seeing a natural frequency around 3hz front and 4hz rear. I think I burnt out the servo because the servo is just being commanded all over. I think I need to implement a safety function that takes into account the speed of the servos and sets a limit on how fast the commanded position can change.
Yes they do. In earlier videos I talk about this, but each suspension arm has an encoder. The accelerometer is primarily for the overall spring mass of the chassis.
This algos don't take delay into account. Short bumps may result in wheel lift after the bump ends. The servos have also limited speed and the small rocks are quite high frequency. Adding more weight to the car and driving on hard dirt would be more forgiving :). Best would be to put sonic sensors just in front of each wheel and control this in feed forward. Or put low pass filter on the measures position with a time constant kinda close to the delay. Anyways, great stuff.
Thanks. I think not taking into account the delay in feedback and properly filtering is what caused one of my servo's to fail. I have a simple EMA filter on the encoders which does add some smooth and a bit of delay, but I think I need to use something like the ServoEasing library that allows you to specify accelerations and velocities to the servo.
It’s an RC10T, but it’s 30 years old so no longer made. The servos are animos DS3218 Pro. The code isn’t very stable yet as it’s just a prototype, but I’ll work to get it uploaded to my GitHub site.
I recently had a similar idea and found your videos, I look forward to seeing part 4.
I did something like this on my sc10.2
I made bellow air springs at each shock and wrapped each shock in a wire coil added a shock disc with 5 holes and ferro fluid.
I used the valve/pump units from some blood pressure cuffs. A hall effect sensor and a small neo magnet to read each arm.
A simple setup using a custom pcb and an arduino m0 with an imu and hall sensors tracking wheel speed in all 4 wheels
Nice. I like that setup. I was trying to figure out ways to get a small pump like that. Initially I was planning on hydraulic actuators. Which IMU did you use?
Ty for this working through this completely absorbing active suspension project! Obviously, it took someone with passion, patience and high intelligence to tackle such a beast, you are killing it! Please keep it coming...sub'd. Peace out.:)
This is brilliant and thought provoking entertainment - thank you !!!
Great project! Looking forward seeing the results
Hi great project! Subscribed just for it. A few comments, as others have said, your servos will not have the speed to correct for road vibration. On flat tar lower control arm sees about 20hz, most suspensions can act on 1-4 hz. There are few research grade high speed active systems that try to work in the 20 hz range. At full scale the speed and force needed in the actuator results in something too big and costly, but it is coming, and it will change racing forever. Let the springs and dapaners suck up the high frequency stuff. What alot of active systems try to do is active body control, so just control body roll/pitch/yaw. This is in the frequency range that hydraulic or electric actuators can meet with today's technology. It also simplifies the control equation as you can use pid and height or even height and 3dof sensor.
Thanks. That makes a lot of sense on the vibration rates. Thanks for the info on the frequencies. I haven't found literature on the specific suspension frequencies ranges that active suspensions have been built to target. I really need to build a single wheel test rig to measure the frequencies and optimize my filtering and actuator damping. I'm leaning towards having an electronic force based actuator like a linear motor which won't need as much power at this scale versus a real automobile. Also I should be able to have a much higher frequency response versus the servos.
I agree with your thoughts on just controlling the roll/pitch/yaw, particularly with an off-road rc car like this. I'm think I will implement a secondary spring system so the servo doesn't have to support the weight of the car and absorb the shock loads from jumps. The servos can handle this but they need a lot of current to do so (~2 amps each).
I managed to get a few BNO085 IMUs from Mouser last week. Keep looking!
I'm curious if the servos can move fast enough to respond to high frequency bumps, like the gravel in the video. In my autonomous RC car project I'm modeling actual steering servo position, not just assuming the servos are at the intended position that was sent in the last PWM pulse. My model just uses basic linear interpolation of nominal servo velocity, but in your case it would probably be asymmetrical due to the normal force. It might be interesting to see the modeled servo position in your data logging, and see if that accounts for the undesired acceleration that you're seeing.
Thanks for the tip, I hadn’t seen the BNO085 before but it seems to be better than the BNO055 and available.
The servos definitely don’t respond fast enough. I’m not an expert on this, but I’m using some filtering on the IMU and the encoders which gives me something like a 5ms sample period. Then I only command the servos to a new position every 20ms. But I did burn up two of the servos because I think I’m just sending them in opposite directions every few readings. Ideally I may need to get servos with feedback so I can read the current position and not just the commanded position.
@@IndeterminateDesign What's the frequency of bumps that you're seeing in the logs? i.e. how frequently does the sign of the vertical acceleration vector change, after subtracting gravity? I could believe you're hitting over 100 bumps per second on gravel, so that may exceed your 200Hz IMU sample rate, much less the 50Hz PWM signal. It may simply be the case that modern digital logic components aren't able to respond fast enough for this type of terrain. Have you tried it on terrain with fewer, larger bumps?
So I need to do some better logging, but when the library removes the gravity vector, it seems to be consistently ~0.5G when the car is not pitching or rolling. But as soon as the chassis rolls or pitches, and the gravity vector starts to pick up values from X&Y sensors it all goes wrong. So it makes the accelerometer data fairly messy, but I'm definitely registering over 100 bumps/sec.
So when I integrate the acceleration to get the velocity, I implemented a "bleed" of about 2% so that the velocity always trends a bit towards 0 to hopefully eliminate the integration error. The larger the bleed the more erratic the velocity becomes and if it's too small it just overflows either positive or negative.
The encoder data at the wheels is surprisingly clean, and I'm seeing a natural frequency around 3hz front and 4hz rear.
I think I burnt out the servo because the servo is just being commanded all over. I think I need to implement a safety function that takes into account the speed of the servos and sets a limit on how fast the commanded position can change.
Looks great!
Really interesting project. I wonder if implementing suspension arm angle sensors might work better than using accelerometers?
Yes they do. In earlier videos I talk about this, but each suspension arm has an encoder. The accelerometer is primarily for the overall spring mass of the chassis.
This algos don't take delay into account. Short bumps may result in wheel lift after the bump ends.
The servos have also limited speed and the small rocks are quite high frequency. Adding more weight to the car and driving on hard dirt would be more forgiving :).
Best would be to put sonic sensors just in front of each wheel and control this in feed forward.
Or put low pass filter on the measures position with a time constant kinda close to the delay.
Anyways, great stuff.
Thanks. I think not taking into account the delay in feedback and properly filtering is what caused one of my servo's to fail. I have a simple EMA filter on the encoders which does add some smooth and a bit of delay, but I think I need to use something like the ServoEasing library that allows you to specify accelerations and velocities to the servo.
Great project! Thanks for sharing!
You bet!
Great project!
Look at the Williams FW15 Formula 1 Car
It used active suspension in 1993
Love it!
What if you get a used treadmill and place bumps on the belt to give you the roadway you desire as well as a mount to measure the cars stats
That’s a great idea, I don’t have the space for that setup right now but it would be a lot more accurate to have all 4 wheels going over the bump.
I would likd to replicate your project. What RC car model are you using? Can you share project details?
It’s an RC10T, but it’s 30 years old so no longer made. The servos are animos DS3218 Pro. The code isn’t very stable yet as it’s just a prototype, but I’ll work to get it uploaded to my GitHub site.
lower right lower shock bolt is loose.
Thanks, good catch!
Can you post the cad files for this project? i'd like to add this to my rc car
Let me see if I can export a step file. It’s bit of a mess since I have several different designs in the same file.