Thank you! Love your rockets! I am subscribed for quite a long time :) BTW I am planning to build a new TVC rocket with these servos. I think that I can use current position readings from TVC to build an improved flight simulation. It was hard to tune control algorithm without knowing the exact response characteristics of the TVC mount.
great job! I would advise against using an I²C for communication over long distances. I²C is intended to be used on one single PCB and not in a large network. There it might be better to use CAN, RS485 or Ethernet. They are designed to be robust against induced noise.
considering this is essentially remaking dynamixels he should just look into the dynamixel protocol and utilise it. Half duplex serial. Ive implemented using their protocol for my own servos and other systems. its robust.
I learned about this when I was half-way through the process already. But I think it will work at this scale. Calculations shows that I will fit into 400pf line capacitance limitation. Waveform looks scary (I was also dumb and placed SCL and SDA as adjacent wires in the cable, so there is also a quite bad crosstalk). But despite this I had 0 failures so far. I think I2C could be used like this if you take care about noise and line capacitance a little bit, and not going crazy with wires. I would say up to ~1m should be fine. Also STM32 has an improved current sink, so in theory if host controller is STM32 too, it is possible to use pull-ups with much lower values than I2C standard suggests. That will help with waveform and capacitance. But still no resistance to noise is an issue. I am thinking about CAN too, but there is no CAN in STM32G0 so it will bump up the cost but probably it is worth the money, because CAN is amazing (never used it so far). Thanks for the feedback!
Oh, neat. I'd had the idea for running servos off I2C with an added Vcc line for a while, but I never found the time to implement. Didn't even think about using a hall sensor, but that absolutely makes sense. Really happy to see someone put in the effort! Unless you're planning to make this a salable product (which is absolutely an option you should consider), you should share your schematics and sources so we all benefit!
Awesome work! As soon as i saw how hobby servos worked, and saw how much empty space there was inside, i thought this is useless for robots. Im so glad to see your implementation, id love to see more about the driver circuit.
I am very impressed with your design skills. Everything about it is top notch. I love the bearing solution. And the controller and... well everything really. Subscribed
An absolutely amazing video. You can tell there's knowledge, skill, and so much thought in all you do. I will watch it again as inspiration in my projects.
Спасибо что делишься. Сам очень потихоньку строю что-то ровероподобное но чуть побольше раза в 4 с утилитарной целью - мониторить "владения" 14 гектар. Успехов!
Great job! One idea to reduce complexity of the wheel assembly: If you‘d use motors with axles on both sides, you could mount the magnet and control board on the inside of the wheel.
Yeah, that's a good advice. I really started to appreciate dual-shaft and hollow shaft motors. They gives a lot of options to simplify the design. But one of the goals is to try to keep everything very cheap. These motors are like 1-3$ piece (from Aliexpress), but this limits my choices. Thank you!
Great video and nice explanation. I am an engineer myself and know how hard it is to explain difficult design decisions in a simple way. I also like your approach of integration, some smaller things, like adding a plug for disassembly would be great, but this can be easily added in the next iteration. Looking forward to your next video. Maybe you can tell us a bit about your background, like motivation and education in the next one. Subscribed for sure!
Got insights into some extremely useful information. The feedback control loop was amazing! And I would love to see videos on the design and implementation of the bearing. I am currently working on a rover and I will definitely integrate these into it.
This is so cool! You created a mini brushless motor!! There is a big market for this and I would love to get my hands on a few of these boards. As well, as you asked in the video, you should make more videos of this project and all the gears created. GREAT WORK!
Looks very nice, good work. You should try make a variant for mini brushless motors as well. For small but fast, high accuracy and/or high torque hobby servos/motors. I think that would work very good (and i don't think there are so many other that have made a DIY hobby brushless servo), but is of cause a more complex and challenging project. Maybe use CAN communication. Its developed for car/machine communication and would be suited for this application and use in robots/machines etc. But stay away from RS485, it often dont work as expected. Its ok on longer timescales where a bad signal can be resent like for example in a temperature regulation situation.
Thank you! Yeah, that could be awesome. I will focus on improving brushed DC motor for now, maybe will bring CAN to the next version as it is a good idea. I have researched BLDC motors before and I think the brushed motors should go away at some point if we can make a good and cheap controllers for BLDC. But this is another layer of complexity on top of what I already have, it was too much to bite at once. But I hope I will get to BLDC servos/ESCs at some point :)
This is a great project indeed. As already written by others, it is better to replace I2C by RS485/CAN or another more industrial type of interface. For small projects I2C may be okay, but I think something like a serial interface as used by Dynamixel (where it is easy to swap between TTL and RS485) would be better. For more generic use, the protocol should add for programming the (PID) parameters, allow for absolute positioning or speed control, current feedback (to get an idea of the load of the motor) and more. Making this open source will allow the community to make this an even more versatile project than it already is. Oh - and add connectors. Connectors are a must have for easy maintenance.
Go for it! Starting could be hard. I probably spent a year thinking about the rover, before I started actually doing something. I was scared of the amount of efforts required to finish it (and I still not very close :) ). But when I started I was making progress way faster than I though. And it is also fine to take breaks if you feel burned out. So I would say that if you have an idea and you are passionate about it, just go for it. The faster you start, the faster you will get to something you will be proud of. Good luck!
Great idea, great video! Thanks Just a note on PWM to control the standard servos: it is intended to have a period length of 20ms with T_on of 1.0ms for lowest position up to 2.0ms for the other end position. As long as you stay with this period length your description is correct and you can call it PWM. But in fact the period length is not important, only T_on is considered by a servo. So with another period length one can see not T_on/period is the signal, only T_on is used. The term PWM is a bit misleading here.
I think it will not be quite good for the camera gimbal. It is made for DC motor and there always will be a gearbox and so a backlash. I mean we can do a camera mount, but it will not be very smooth. I have a plan to make a version for the BLDC motor in future. It will (hopefully) be possible to use special direct-drive BLDC and build a real camera gimbal with it.
Pretty sophisticated for an everyday hobbyist! That is, love the idea, although (for lack of skills and patience) I probably would not aspire to recreate it myself.
I'm interested in using your servo motor set up for other builds. I think it can be used to create a very cheap, but powerful robot arm that is better than anything on the market. More details please. Awesome work.
Thank you! I will make a next version with some fixes and will make it open-source. I have a passion for making things cheap too :) This is the way for everyone to have a good stuff. Good luck with your project!
You could also use RS-485, very noise resistant, but your intended line length is short, so something simpler probably works... Maybe even just added a drive transistor on each end, with lower resistance pull up.
In my final year of university, I created an equation to smoothly travel from one position to another with a maximum acceleration, constant speed and low jerk. I have a desmos of it if you are interested. It would be really great to have it integrated in a controller like this
That's cool I will be happy to take a look. I used very simple trajectory and never researched this topic before, but if you have a good answer already I will happily use it.
Oh man I'd absolutely love to use these! Are they going to be open hardware and source? This is a seriously cool design, love that layered control loop
I will 100% open-source it since the next version. The current version has some issues. Not very critical but it could be better. And the firmware is quite sketchy right now.
Great project! If it not too late, change I2C interface to something else. I made this mistake when building my robot and experienced communication breakdown due to electric interference with I2C sensors for wheel position. I2C is good for communication between ICs on PCB but will fail when use on wires. Especially when close to electric motors.😮
I learned it when it was too late. Hope it will be ok, otherwise I will switch to CAN, but it will take significant effort. For now I reduced the problem by using 3 I2C interfaces instead of 1 as I planned. So now it's 5 servos per bus. And two servos works fine. I hope 5 servos will work too. Thanks for the heads-up!
Yeah, I decided to not dive too deep into this. But in fact everything is very simple. Position control is just P regulator. Velocity control is PI (well, almost: I term is applied to velocity delta, P term to current velocity, not to the delta). Current control is just PI. So it is like 3 simplified PID regulators chained. And it is not my invention, google for "PIV regulator" that's exactly what I implemented. Maybe I will make a video about it, but not sure if it will be soon.
Fricking absolutely. We're stuck with 1980s technology for servos. Wiper potentiometers, weak, slow, brushed motors and open loop (from the point of view of the microcontroller) control schemes. I can buy a 500W brushless drone motor for $10, a 4096 position, continuous, absolute rotary encoder for $5, an ESC for another $5 but no one anywhere has put these together into a robotics servo that uses I2C or SPI? No. I have to buy a $1000 NEMA whatever AC servomotor and a $2000 controller that runs over RS232 with a proprietary connector and proprietary software that only runs on ****ing Windows NT. This needs to change.
This is so true! That hurts me too. We have so much cheap and great parts but proper BLDC servos are so expensive. I will go for BLDC servo as soon as I complete the brushed servo first. That will be exciting! It is time for brushed motors to go away.
@@Positive_Altitude Standard servos, even the fast ones are also just way, way too unresponsive. I see people using them in guided rocketry and all they get is oscillation. You can get servos that do 60 degrees in 100ms, but most of that is spinning up and spinning down the motor, so it definitely won't do 30 degrees in 50ms or 15 degrees in 25ms. That includes AC servomotors too. They might be fast when they get going, but they're slow to get there. If you get the data, it would be nice to see an RPM vs time curve when you give your controller a move command. I know your rover doesn't really require high speed position changes but it would be nice to see anyway.
Lol. I have made one of these rockets, check the first video on the channel. And that damn delay... I greatly underestimated how badly 40-50ms delay could affect control algorithm stability. That was the reason why I failed my first launch attempts. And what is the most annoying -- there is no position feedback, so it is not possible to measure step response and use it for control system tuning. I ended up just roughly modeling it in the simulation. As the result rocket flies, but with some oscillations that are not present in simulation. It is totally possible to implement a way to capture step response of my servo, it also will greatly help to tune the servo for high performance, but I haven't implemented it yet. But I can say for sure that 400kHz I2C has almost zero communication delay compared to 50Hz PWM :D
awesome project, i've been thinking about doing something similar but never got to it. Please do share your experiences with printing bearings, yours look very good!
Hey, impressive work 1 more subscriber ! I'm needing custom built servos more and more, and your work possibly will save me days of trial and error this summer. Also definitely interested knowing more about your custom ball bearings, and how you got to the right design - hopefully I'm not alone hoping for that vid ^:D
I'm very interested in the servo control board! I'm working on walking robots. Off the shelf servos are disappointing and get expensive quick when you use a dozen in one robot. Using N20 motors at each joint could be a big improvement.
Yeah! That's sounds cool! How big is the robot? I am working on the next version of the servo. The version in the video has some issues. I will share design files when it will be ready.
If you are talking about the board, the next version will be available. The one in the video has issues. And I will make a video about it when it will be ready.
The great thing about hobby servos is their simplicity and very low cost. Lots of people use them for this reason where they are not really appropriate, like wheel drives and cnc type machines. Makes for cheap toys. You are making a real robot, not a toy. My question is how precise are the magnet position sensors? The hobby servos I've used (cheap ones) have pretty poor precision potentiometers and high backlash gears.
This encoder is 12-bit , so LSB is about 0.1 deg. But there is also a "non-linearity error" that could be somewhere around 1 deg. This error also greatly depends on proper axis alignment. But the good thing is that it is not like noise, it is consistent, the error is is repeatable for every position. So in theory we can assemble the system, then use another encoder or stepper motor as a source of precise angles, collect statistics and offset non-linearity in the software. But I did not do that, for my applications it is good enough.
Wondering if is worth to integrate everything into the wheel and add a slip ring for power and LED and receiver for signal transmission for continuous rotation like a LiDAR
@@Positive_Altitude thanks for the reply. I dabbled with Eagle a long time ago, then played around with Kicad a little and now am looking at EasyEDA. I think if a project comes along where I need a PCB it will be either Kicad or EasyEDA.
Thank you! I use Prusa i3 Mk3 from my local hobby space. It's a good printer but maybe a little bit outdated right now. I think there are better options on the market for the same money right now.
Hi, I would be interested in the idle current of your design. Magnetic sensors ~ 10mA, uC ~10mA, motor driver + rest ~5mA. So, I would expect ~20..25 mA. Is that correct ?
Yeah, this encoder (Semiment SC60228) takes around 12mA, MCU: 6-8mA. The rest is negligible. So yeah, idle is ~20mA which is something you need to care about when you have 10+ of them. I am thinking to use more popular AS5600 encoder in the next version and it takes around 8mA. Also the MCU just busy-waiting most of its cycles, so it could be clocked-down probably 2-4 times (and current is almost linear with frequency). So it is probably possible to get down to ~12mA.
Thank you! Not shared on GH yet, because there are issues and no documentation at all. Maybe I will do that during the next few weeks. But anyway I am working on a new, improved version, that will be shared from the very beginning. I hope I will get there in 1-2 months.
If you are using a magnetic encoder to determine position how do you figure your start point? On a normal servo the potentiometer returns a set resistance value so it knows where its start position is. How are you achieving this?
This encoder returns absolute value :) Yes, the zero position is quite random, because you cannot really align the magnet's poles orientation when attaching it. But if you don't mess with the magnet, zero point stays the same, so you can just offset it in the code.
I am using Rust. It is a great alternative to C/C++, a low-level language too but with some degree of memory safety features provided at compile-time. I like it because I can use one language for embedded, desktop applications, backend and even for frontend (thanks to .wasm). So I can share my code all over the place.
I see that the cage for the ball bearings is 3D printed, but are the inner and outer races for the ball bearings also 3D printed? If so, how well do they wear?
Yes, 3D printed. I did not make a wear test. I feel that they will wear quite slowly if not over stressed. And I assume that high speed will kill them instantly because of heat. But how fast the wheel will wear under the reasonable load is a question. Maybe I will make a test in the future.
@Positive_Altitude My concern is for the pressure that will be concentrated by transfer of the robots weight to the ball bearings. A metal race can handle tremendous pressures, but 3d printed plastic, even at 100% infill is still roughly 70% the density of injection molded plastic. Add to that the fibrous structure of 3D FDM parts, and that does not equal a recipe for success. Great work though.
That's true. But I believe that if load is under the certain threshold these bearings could last long. The threshold is a question. I would expect that one 4mm ball is able to transfer at least 1kg without any issues, but it is my guess. Of course its nowhere near what hardened steel could do. I will make a video about these bearings and will try to make some tests to get an idea what one could expect from these bearings.
Actually I think if both will be plastic, balls will wear much quicker than the runners as they are smaller, so it it probably a good thing that balls are harder. These bearings should be considered as "low load, low speed, low precision". If we compare them with factory made steel, they just sucks in every aspect except weight and price :) For projects like this rover I think they will wear pretty slowly. I print it with PETG an it has good wear resistance. But for example if you are making a racing RC car, these bearings most likely will just melt in a few minutes.
I like everything about your project, but what I like most is that you are using Rust for the programming. I wish I could do the same thing on a Raspberry Pi Pico. What STM board would you suggest to use Rust with? Thank you in advance.
Thank you! I am very happy with Rust for both STM32 and ESP32. I also know some guys that use it for RP2040, so you can do that too! I never used RP2040 but I expect that Rust is well supported there. For STM32 boards - Rust is supported with all of them. So pick any of them, but maybe you should take a board with original MCU from ST. I like cheap stuff, but some cheap boards uses clones of STM32. I don't know if they are working good with Rust, but when I had one I was not able to setup debug for it using original ST IDE (I was using C those days). So maybe they have additional challenges with Rust too. The only issue is that I don't like the high-level HAL implementation in Rust (or I did not find a good one). The one I had was very poor in features. If you do a simple things like "blocking read ADC once" it's ok. But if you want to use the full potential of peripherals like "read ADC with hardware oversampling in circular mode writing values directly to circular buffer in memory using DMA and fire interrupts when ready" it is not supported. You need to dive into reference manual and set it up at low level using registers. But the STM32 documentation is top-grade and you will learn a bunch of cool stuff in the process. Also the low level HAL like register map is there and it is good.
