My 4yo son watched this with me and now he can’t stop talking about how much smarter you are than me. Thanks a lot, jerk. In all seriousness - nice work. Can’t wait to see the final product.
I've got two Motoman K30's (1995 era) running in production and its a nightmare trying to find Servo Drivers. Looking forward to moving this forward. The world definitely needs opensource 220V / 480V 20VA controllers!
Loads of older CNC machines still have good steel and use these same servos and are impossible to keep running for similar issues. The biggest problem is decent servo drivers that don't cost 8 grand.
@zyxwvutsrqponmlkh the wild part is that most of this technology is gatekept at a national legal level. Japan and the U.S. and Germany even went so far as to stamp "illegal for export" on all Okuma 2spV60 lathes from the 2000s, due to them having these expandable motion controller boards inside of them.
@@IAintScaredOfNoGhostwhile Russia, China and other nuclear weapon countries are flexing their military muscles... I'm pretty OK with export restrictions on technology. It's not just about protecting ones financial interests.
I have a Fanuc CNC mill from the year 2000. It regenerates when the axis decelerate. Makes the LED lights and GFCI outlets in my house whistle. Also I will totally buy that new driver you're building. Keep being awesome!
@@TheCrazyPozavnist They literally make noise. You can audibly hear what the CNC mill is doing to my electricity. My CNC machines are in my shop which is about 40m away from my house, and the GFCI outlets in a completely different building make noise.
@@joels7605GFCIs are transformers, so it means that your machine is reducing the electricity quality by addition of high frequency harmonics. So, PFC or cheaper solution is just a bunch of ferrite beads or reactors(inductors) to improve the power quality.
Easiest way around fanuc encoders to find reliable and affordable drives I have found recently is to ditch the factory encoders and replace them with 16bit encoders from DMM Tech in Canada. I have a couple of fanuc redcap motors been laying in storage for years due to the high price tag to try and revive them. I took a chance and ordered some encoders from them together with their DYN 4 ac servo drives (200vac), and within a few hours I had the motors running like new ones. Hardest job was to make custom fitting plates to fit the encoders. They supply you with software to do the encoder alignment, no fiddling with scopes etc. Just wire it up, fill in a few parameters and if the motor phase connections are done correctly, you will have the motors spinning in minutes. I have no affiliation with them, just found it was the cheapest reliable option after digging for many years. Their online support are also top notch.
It's rare that I listen to someone that grasps this so well. I will be watching and learning. Thanks for taking the time to make this video and share it! Mark
Great job, keep up the good work! I think an open source controller would be an excellent gateway into modern small-scale integration. It could lead to great cobots, research, or even hobby use for other platforms such as metal 3D printers and multi axis EDMs. Super cool!!!
I've always wanted to utilize an industrial robot but the ties to the manufacturers software and controllers has always been a deal breaker. Being able to utilize a robot without the stock controller is huge. I subbed to follow your journey. A finished product that could be used as you envision would be fantastic. Thanks for all your work.
I believe the way your explaining how the Fanuc controller calls for the encoder value of specific axis's when needed. That sounds like the most efficient way to do it. Since at any given time a command move may only require 1 or 2 of the available 6 or 7 axis to move so why would you want to carry the overhead of data communications from the delta of servo motor/encoders not needed when you already know where those joints /encoder counts will end up anyway right ? I like your proposed FPGA architecture. That is certainly the way to go today and like you said keeps the hardware always expandable. FPGA's are the future of all electronics. Software defined control law and FPGA. Great work ! Thank you. J
My buddy has a 7 axis robot we are trying to get running, so we will be following this closely! It's all DC servo with resolvers, and software will definitely be our shortfall.
Very cool project, as someone that programs CNC motion controllers I’d say you have a lot of work on your hands doing this alone. But I’d love to see you succeed
What kind of motion controllers are you programming? I am a software developer myself, but ever since I started building my own cnc controller app, all I dream is coding for something related.
@@LikeFactoryMadeI work for Eding CNC, we develop a range of PC-based CNC controllers for milling machines, laser machines, lathes etc. I’m an embedded software engineer there, so I mostly do firmwares and bootloaders. What are you currently developing?
Just an FYI, although I haven't demonstrated it with a FANUC protocol, I have managed to make the Raspberry Pi Pico poll encoders using the BiSS or Mitsubishi protocols. I can handle 8 BiSS encoders using the PIO hardware of the board. Probably not the best solution when compared to FPGAs but they are very cheap. Love what you're doing btw, keep it up. Greg
docs.google.com/spreadsheets/d/1nRmV0D8c2zIuhrnp7eMNqSO8C0mfWp4tSzxPsphXA7A/edit there’s a sheet that has the protocol sort of explained. A860-2014-T301 is the specific encoder part number, but it seems most aA64i encoders are similar.
The RP2040 PIO‘s were also the first thing that came to my mind instead of the fpga‘s. From my point of view it seems easier to get going and is a lot cheaper as well.
@@TheRainHarvester PIO's are clocked at 125 MHz default, you can definitely write something to handle it. they are 5 bucks! definitely worth a try, and i think they are much easier to use than fpgas
Man... so much knowledge I'll never be able to get even close to. Even though there's a large Kuka sitting in the corner of my workshop collecting dust. Ex colleague bought it several years ago with such an outdated controller it doesn't even have USB. Anyway, never been able to make it work. Any chance to make it useful would be just incredible. Keep up the good work!
Something that might be interesting to some. A particular company I worked for had some of the first Fanuc (cast on the robots was GMFanuc) industrial robots in production as paint robots. If the robot(s) were powered off or lost power through an e-stop or some other reason, or had to have a new encoder installed on an axis, we would need "remaster the robot" which involved installing a special mastering fixture onto the robot, fold the robot up into the fixture by releasing brakes and physically moving the various axis into their zero position on the fixture and pin it to the fixture, then relax the robot after it was pinned. Then go to the robot controller and read the current encoder values from the terminal, compare it to the factory zero master encoder value on the master chart for that robot and axis then add or subtract an offset value so the actual value would equal the master value, then enter the adjusted value into the axis through the terminal save it and go to the next axis. This was then the known zero position of each axis that had any errors adjusted out.
God this is outrageously cool...I'm more of a mechanical guy (cars/motorcycles/etc, just got a manual Bridgeport), but I'm also a software engineer and I've always been fascinated by the idea of using computers to run physical machines. Seeing this really gets my gears turning ;) Also, I've rarely seen someone with your level of knowledge talk about something this complex so clearly! Good on ya :)
I absolutely love your work and the Apache controller case Idea has been super helpful with my cnc project so I wanted to say thanks! And just out of curiosity, where did you learn how to do such cool deep-dives into the electronics? Thanks for the new post and keep up the good work! :D
@@ExcessiveOverkill you must have some sort of formal electronics training? I am awestruck with how much you know yet you seem so young. I can't imagine how long it would take me to reach a level of knowledge to not just understand how all that stuff works, but to improve on it.
Great to see another vid and this is absolutely awesome!, There is currently nothing out there quite like you have described, I will be following this project quite closely and wont have a problem supporting it via patreon or something. I was thinking about buying an old DMG 5 axis milling machine, that has control failures beyond reasonable repair and kind of experimenting with it, I think you project would be a great match and generally good testing for it. Thanks for sharing!
there's a good chance path blending is causing trouble, set g64 to p0.01 in your INI for the rs242 startup routine. The problem with the encoder handling within linuxcnc, is that it is not done by interupt, and I kinda went on a rant about it a few months ago. I have been working on porting EMC2 to OpenRTOS from TexasInstruments for use on their hardware. But dude, I don't have enough time. I think getting EMC off of linux is where I would start. Then with some work there's a way to fix the short coming of the control software. Keep me aprised though, I have some skills as a C programmer for state type logic and deep mechanical engineering skills.
Suggest you aim to include dual STO inputs on the motor controller. And set up the safety+motion controller to eventually support Safe stop 1 (SS1) - which is basically just a configurable delay before triggering STO. Have the motor controllers in charge of the brakes, and link that in to STO chain.
Super interesting project and looking forward to see how things progress. If you are looking for ways to simulate your robot and test out/tune your motion control there are a number of open-source versions of common tools used in industry, such as OpenModelica, Scilab, & others. They have somewhat of a learning curve but it's amazing how much control prototyping you can do with just a simulated model of your system and then fine tune with the real system once you have something working.
I have used ROS (Robot Operating System) with the MoveIt program to control a custom robot arm. I never ended up finishing the project, but it wasnt to hard to get Moveit to work with my arm, and using ROS would make it potentially easier to setup the encoders and all the other control stuff.
This has been a very fun watch. I went through almost the exact same thing with a Unimate PUMA 560 robot I wanted to resurrect. Similar hardware encoder issues, similar starting again from scratch mid-way through situation... stay strong.
I love what you are doing. Subscribed. Keep up the good work. Your explanation of motor controllers and motion controllers was very good. Not many people understand this.
Super cool! The engineering department at my college has one of these and I never knew about all the intricacies involved with having it communicate with a computer.
This is a great thing you're working on. Well designed open source controller would be able to help revive tons of mechanically fine robots with dead electonics. If you'd like some FPGA support, let me know. regards, hypernyan
If you build that controller, you would make a killing. Not only that but you would open the doors for so many people that don't have your expertise (like myself...) to do some really cool stuff! I say do it!
Good luck! I've stayed away from FPGAs because I just consider them above my pay grade. I'm not afraid to jump into unknown waters, but it's already hard enough learning how to write and debug embedded MCU code, not to mention motor control stuff.
Amazing... I only wish I had spent my early EE days learning FPGAs... I don't think my instructors had a clue either. Great overall explanation of the state of options for controlling industrial robots.
Very nice video and super interesting project! Just one advise from my side, if you push the robot (like in 11:14) please have a deadman switch at hand, even if you are 99% sure that nothing can happen.
Have you heard of EtherCAT? It's a network protocol for industrial automation that can do up to 30kHz update rates with low latency and jitter. You would daisy-chain your motor controllers up with using ethernet and hook up the whole thing to a computer that runs the motion control. The chips to do it are surspringly cheap (LAN9252 is ~$10) and can be used with any microcontroller or FPGA. Maybe this could be a fit for this project, as this would make it much more modular and extensible. Adding peripheries or even an additional axis would just be a matter of adding another box to the network. (also it wouldn't require to design everything from scratch, there are already a lot of EtherCAT motor drives out there).
I did look into using ethercat but the IP for the fpgas was like $10k. I think I thought the off the shelf chips wouldn't work for some reason, I don't remember exact why rn. I planned on using rs422 which would give me like 30khz updates with no daisy chaining, but I'll look into those chips again.
@@ExcessiveOverkill This was my gut reaction as well - RS422 but with separate drivers for each motor channel for best throughput. Ethercat is price overkill
"low latency and jitter" they boast as if it's a _good_ thing ("a little bit pregnant"?). How about _zero_ latency/jitter. It's a world of EMI (PWM), who in their right mind throws around data at such a high rate? Marketing BS.
I would love an inexpensive HV motor driver like that! I do quite a bit of motion control/robotics/embedded systems as a hobby, and my day job is industrial control systems, so I actually have a few motors laying around it would be nice to have drivers for. and a project like this really gets me excited! it would be great fun if that could run with a 480VAC supply, as that would be easy and cheap enough to rig up a transformer for in a residential setting, and could run some really high performance motors. but then you got to deal with the nearly 700V peak to peak voltage... I don't see very many quadrature/incremental encoders in my day-day, they have largely been replaced by EnDAT, Hiperface DSL, and SSI. I've even dealt with a few that go direct to EtherCAT. as you mentioned, an FPGA could certainly talk to all of those protocols, however a lot of modern micro-controllers have some kind of programmable hardware fabric that could likely be convinced to speak most of those protocols outside of the actual CPU. Cypress's PSoC architecture, and the Ras-Pi RP2040's PIO state machines both come to mind as possible options that would be ~1/10 the cost. Thanks for the awesome niche content. definitely cant wait to see where this goes!
you work as a genius. but i think open source for industry robot is imposible. just the dream. thanks for your great work. waiting for your next content.
I just discovered your channel thanks to yt magic. I'm looking forward to seeing where this goes and hope that you'll do so well that you can make this a full time gig!
Low voltages caused by high resistance neg/gnd loops or voltage leaks causing positive gnd. Also, back emf can cause dropouts due to the control sigs not having enough disparity between VCC and GND(seen on the oscilloscope with the base voltage jump 4:52) Possibly Separate each GND from the motor/actuator from all other controllers
This is like an upgraded crane, almost, but more mobile and smaller. Great work, would love to build one of these for myself and see what they do. Integration of large machines like this could eventually become a large exoskeleton like the AMP suit, or some sort of mech. Love to see what you're doing with this later, you've got a like and sub. Keep it up man. 👍
Out of nowhere: Lets rely on learning VHDL or Verilog and programming an FPGA just for fun and by the challenge to conclude a project ! There will be many nights over my friend, good luck
@@ExcessiveOverkill Don't fall into the trap many FPGA beginners do and test in real hardware without simulating. It makes debugging very painful, not least because of the incredibly long build times. Have fun with Vivado :)
On the one hand this is very impressive, on the other the time saved to just buy a slightly newer robot and instead put the effort toward something like open source middleware to do the CAM to Robot language. Right now it seems the choice is either something really expensive like SprutCAM or something only slightly expensive like RoboDK. I'm no robot expert, but it seems whatever system you come up with will always lack what a user would get from a functioning commercial robot controller. I've seen 2016 ABB robots go for $5k at auction recently, these were not beat units. I'm in the process of setting up a 2013 ABB 6640 (180kg payload, 2.55m reach). I did pay a lot more for it than $5k, but it came with 7th axis and a guarantee... Anyway good luck with whatever path you choose.
Interesting project! Re. the drive system, I'd suggest you break it down a bit, for each axis: A dual-loop speed servo, with the outer loop managing speed error and the inner loop managing motor drive current. Then separately, a position loop that compares instantaneous target position to actual position and gives the speed servo a signal directly proportional to that, limited to ~80% the maximum drive system speed capability (or whatever below that you consider safe). The G Code interpreter and path calculation system only update the target positions & the servo position system half makes the machine track that. That's how large machine tools typically work. Some also have an element of the path speed added in to the loop to reduce following error at higher feedrates, but that is very critical and can easily cause instability, so I'd suggest you use the pure "following error * fixed gain -> speed" setup. In a machine with good mechanics and low backlash, the gain constant is usually set to give 1mm following error at 1m/minute feed, on a linear axis. I'm not quite sure how that translates to rotary! The current loop section of the speed drive has an integrator (or PID), so the current (motor torque) adapts to the load without any significant change in following error. Position holding should be limited only by the motor capability and mechanical strength of the machine, at that. I spent a lot of time with the first system I designed (early 80s) trying different control strategies but it came down to the simple, linear, following error to velocity setup being the most effective and accurate. (The controller ran on an MC6809 at 2MHz, with resolver position feedback and Inland Motor TPAR analog / thyristor axis drives, on 10m and 5m Butler Elgamills, replacing dead bitslice CPU paper tape systems. They used all fixed-point maths except for the operator position display, and no trig at all, even for radius / circle interpolation).
this video makes me want to get back into this stuff. I joined the discord. my background is mechatronics. I ran a machine shop for 5 years. I know machining, best practice for design, and a little bit of general programming and about microcontrollers, but never took the dive into making my own boards. I always saw H Bridges and thought it was criminal how they were priced. It makes any hobby project relatively expensive (especially for people still in school who are interested in this sort of stuff like grade 12 through university).
If you do need to desolder those mosfets at 13:18 , its not that hard to get them off in one go. Take a paperclip or similar thickness piece of uninsulated copper wire, and solder it to each of the through hole components legs with a big blob of solder. Then heat the wire up with a large soldering iron tip. The wire transfers the irons heat to each of the legs pretty equally, and you can just pull the component out from the other side of the board.
Hi, I've been working on a similar type of motor control project that uses FPGAs to control smaller / lover voltage BLDC motors. I found a pretty sweet FPGA that I've been developing with that might be a good match if you want to swap the zynq out for a smaller FPGA that would live in each motor controller (it is also waaaay cheaper). The chip is a Gowin GW1NSR-LV4C. Sipeed makes a dev board for it that is pretty good for figuring out their toolchain. It has a single ARM cortex M3 along with 4K logic elements which is definitely enough for some custom communications peripherals and a FOC algorithm at some pretty high speeds (I'm trying to do all of my loops at 40Khz +)
Weirdly, I've been noodling doing the exact same thing. Using FPGAs to handle encoders. I can only wish you the best of luck because this seems like a TREMENDOUS undertaking.
Why not run a dedicated microcontroller per encoder? Won't a 80MHz controller be able to sample the encoder and sent the count upon a request? They have interupt gpio so you never miss a pulse. At 80MHz you would have many instructons to sample at 3kHz.
I’m interested. I ended up passing up on 2 free Fanuc welding arms because I realized it was going to be impossible for me to reverse engineer the motor and motion control. I can follow directions and learn along the way, but blazing the trail you’re on is outside my capabilities.
Look into Cypress PSoC 5. I've been able to synthesize motor drivers in the fabric before, the microcontrollers run at 80MHz, they're super easy to program, and pretty inexpensive
my first thought is maybe the brakes spontaneously engage for just a fraction of a second when the supply voltage drops due to the servo motors are drawing some current.
Did anything ever replace TinyG? Last I looked (years), there was nothing that good out there for DIY CNC controllers, although some mention of people repurposing Klipper. I would be surprised if a 600 MHz M7 MCU would not be able to handle this application with appropriate programming. The CMSIS DSP lib has accelerated PID controllers for f32 and q15/31 formats. FPGA tools are less insane now. Yosys support Lattice, Gowin, etc to varying degrees. MYIR Tech has some Zynq modules that you might want to look at. Digilent has a socketable Spartan-7 module. Sipeed has a cheap Gowin-based 20k gate board. Both of those will have limited I/O, though.
If you manage to make a decent DIY/retrofit controller available for older servo drives/motors/robots it could become quite useful in the CNC world as well. Alot of older good heavy machines are send to scrap metal because their lack of recent motion and electronics. Alot of them use FANUC components.
I would use Beckkoff Ethercat motor controllers driving them using LinuxCnc. LinuxCnc is the motion controller giving only target values and the motor controller read the encoders and does the control and pid calculations
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
My 4yo son watched this with me and now he can’t stop talking about how much smarter you are than me. Thanks a lot, jerk. In all seriousness - nice work. Can’t wait to see the final product.
😂🤣LMFAO
I watched this and now can't stop thinking about how much smarter your 4 year old son is than me. Thanks a lot, jerk! :)
"AC power is basically just really long distance regenerative braking."
Haha I love the variety of ways people describe AC for you're quote to "wall gas".
Amen, brother.
That's kinda how big generators in power network keep in sync
I've got two Motoman K30's (1995 era) running in production and its a nightmare trying to find Servo Drivers. Looking forward to moving this forward. The world definitely needs opensource 220V / 480V 20VA controllers!
Loads of older CNC machines still have good steel and use these same servos and are impossible to keep running for similar issues. The biggest problem is decent servo drivers that don't cost 8 grand.
@@zyxwvutsrqponmlkh
every problem is an opportunity
@zyxwvutsrqponmlkh the wild part is that most of this technology is gatekept at a national legal level. Japan and the U.S. and Germany even went so far as to stamp "illegal for export" on all Okuma 2spV60 lathes from the 2000s, due to them having these expandable motion controller boards inside of them.
@@IAintScaredOfNoGhostwhile Russia, China and other nuclear weapon countries are flexing their military muscles... I'm pretty OK with export restrictions on technology. It's not just about protecting ones financial interests.
This is why we scrap these old drives and motors. Add new servos and drives.
Dude this stuff is my childhood dream. I hope you get it done and I'll sure try to help your channel with whatever I can
I have a Fanuc CNC mill from the year 2000. It regenerates when the axis decelerate. Makes the LED lights and GFCI outlets in my house whistle.
Also I will totally buy that new driver you're building. Keep being awesome!
I have one for 6 axis in c++ that runs through arduino 100% custom programmed and better than the machine specific junk that comes with these robots
post the code@@togowack
@joels7605 what do you mean the outlets whistle?
@@TheCrazyPozavnist They literally make noise. You can audibly hear what the CNC mill is doing to my electricity. My CNC machines are in my shop which is about 40m away from my house, and the GFCI outlets in a completely different building make noise.
@@joels7605GFCIs are transformers, so it means that your machine is reducing the electricity quality by addition of high frequency harmonics.
So, PFC or cheaper solution is just a bunch of ferrite beads or reactors(inductors) to improve the power quality.
Easiest way around fanuc encoders to find reliable and affordable drives I have found recently is to ditch the factory encoders and replace them with 16bit encoders from DMM Tech in Canada. I have a couple of fanuc redcap motors been laying in storage for years due to the high price tag to try and revive them. I took a chance and ordered some encoders from them together with their DYN 4 ac servo drives (200vac), and within a few hours I had the motors running like new ones. Hardest job was to make custom fitting plates to fit the encoders. They supply you with software to do the encoder alignment, no fiddling with scopes etc. Just wire it up, fill in a few parameters and if the motor phase connections are done correctly, you will have the motors spinning in minutes. I have no affiliation with them, just found it was the cheapest reliable option after digging for many years. Their online support are also top notch.
You should make videos or blog about it. Alot of people would love to see the process !!
Your motivation , persistence and desire to learn is awesome. I’d love to to quit my job and just do cool projects like this
just embezzle a few million, move to Belize, & you can do it! we believe in you :)
(for legal reasons, I am clarifying that this is a joke lol)
It's rare that I listen to someone that grasps this so well. I will be watching and learning. Thanks for taking the time to make this video and share it!
Mark
Great job, keep up the good work! I think an open source controller would be an excellent gateway into modern small-scale integration. It could lead to great cobots, research, or even hobby use for other platforms such as metal 3D printers and multi axis EDMs. Super cool!!!
I've always wanted to utilize an industrial robot but the ties to the manufacturers software and controllers has always been a deal breaker. Being able to utilize a robot without the stock controller is huge. I subbed to follow your journey. A finished product that could be used as you envision would be fantastic. Thanks for all your work.
I believe the way your explaining how the Fanuc controller calls for the encoder value of specific axis's when needed. That sounds like the most efficient way to do it. Since at any given time a command move may only require 1 or 2 of the available 6 or 7 axis to move so why would you want to carry the overhead of data communications from the delta of servo motor/encoders not needed when you already know where those joints /encoder counts will end up anyway right ?
I like your proposed FPGA architecture. That is certainly the way to go today and like you said keeps the hardware always expandable. FPGA's are the future of all electronics. Software defined control law and FPGA. Great work ! Thank you. J
Hey man I work in the automation industry and do some of this stuff as a hobby as well. I am so impressed by this project. Can't wait to see more
You are legendary!
It's my dream to have an arm of my own one day!
Keep on making amazing content, you are an inspiration!
My buddy has a 7 axis robot we are trying to get running, so we will be following this closely! It's all DC servo with resolvers, and software will definitely be our shortfall.
Very cool project, as someone that programs CNC motion controllers I’d say you have a lot of work on your hands doing this alone. But I’d love to see you succeed
What kind of motion controllers are you programming? I am a software developer myself, but ever since I started building my own cnc controller app, all I dream is coding for something related.
@@LikeFactoryMadeI work for Eding CNC, we develop a range of PC-based CNC controllers for milling machines, laser machines, lathes etc. I’m an embedded software engineer there, so I mostly do firmwares and bootloaders. What are you currently developing?
Just an FYI, although I haven't demonstrated it with a FANUC protocol, I have managed to make the Raspberry Pi Pico poll encoders using the BiSS or Mitsubishi protocols. I can handle 8 BiSS encoders using the PIO hardware of the board. Probably not the best solution when compared to FPGAs but they are very cheap. Love what you're doing btw, keep it up.
Greg
If you can give me the details of the encoders on the Fanuc Motors, I will see if I can get my hands on one and test it on my Pi Pico setup
docs.google.com/spreadsheets/d/1nRmV0D8c2zIuhrnp7eMNqSO8C0mfWp4tSzxPsphXA7A/edit there’s a sheet that has the protocol sort of explained. A860-2014-T301 is the specific encoder part number, but it seems most aA64i encoders are similar.
The RP2040 PIO‘s were also the first thing that came to my mind instead of the fpga‘s. From my point of view it seems easier to get going and is a lot cheaper as well.
@@TheStinkyToastRpi are very bandwidth limited on the GPIO. Do you use external chips to monitor the encoders?
@@TheRainHarvester PIO's are clocked at 125 MHz default, you can definitely write something to handle it. they are 5 bucks! definitely worth a try, and i think they are much easier to use than fpgas
So happy to see an update. I've been working to build a controller for some old robots and am excited to see where this project will lead!
Man... so much knowledge I'll never be able to get even close to.
Even though there's a large Kuka sitting in the corner of my workshop collecting dust.
Ex colleague bought it several years ago with such an outdated controller it doesn't even have USB. Anyway, never been able to make it work.
Any chance to make it useful would be just incredible.
Keep up the good work!
Lovely work! I really enjoy the progress you're making. Big ups!
This is some of the coolest stuff I’ve ever seen
Great explanation of what your issues are and how you plan on solving them. Can’t wait for the next episode. Well done 👍
Something that might be interesting to some. A particular company I worked for had some of the first Fanuc (cast on the robots was GMFanuc) industrial robots in production as paint robots. If the robot(s) were powered off or lost power through an e-stop or some other reason, or had to have a new encoder installed on an axis, we would need "remaster the robot" which involved installing a special mastering fixture onto the robot, fold the robot up into the fixture by releasing brakes and physically moving the various axis into their zero position on the fixture and pin it to the fixture, then relax the robot after it was pinned. Then go to the robot controller and read the current encoder values from the terminal, compare it to the factory zero master encoder value on the master chart for that robot and axis then add or subtract an offset value so the actual value would equal the master value, then enter the adjusted value into the axis through the terminal save it and go to the next axis. This was then the known zero position of each axis that had any errors adjusted out.
It was a struggle and a pleasure to keep up with what you were talking about! Awesome work! Subscribed, looking forward to what’s next
You are a God sir if you successfully implement all of this into open-source. You are one of the most humble tubers around def rang the bell.
God this is outrageously cool...I'm more of a mechanical guy (cars/motorcycles/etc, just got a manual Bridgeport), but I'm also a software engineer and I've always been fascinated by the idea of using computers to run physical machines. Seeing this really gets my gears turning ;)
Also, I've rarely seen someone with your level of knowledge talk about something this complex so clearly! Good on ya :)
I will support you so you can dedicate more time to these badass projects.
I absolutely love your work and the Apache controller case Idea has been super helpful with my cnc project so I wanted to say thanks! And just out of curiosity, where did you learn how to do such cool deep-dives into the electronics? Thanks for the new post and keep up the good work! :D
Mostly from watching a ridiculous amount of engineering RUclips videos. I kinda just learn as I go.
@@ExcessiveOverkillYes, like with TV: YT makes smart people smarter and dumb people dumber. 😉
@@ExcessiveOverkill you must have some sort of formal electronics training? I am awestruck with how much you know yet you seem so young. I can't imagine how long it would take me to reach a level of knowledge to not just understand how all that stuff works, but to improve on it.
Great to see another vid and this is absolutely awesome!, There is currently nothing out there quite like you have described, I will be following this project quite closely and wont have a problem supporting it via patreon or something.
I was thinking about buying an old DMG 5 axis milling machine, that has control failures beyond reasonable repair and kind of experimenting with it, I think you project would be a great match and generally good testing for it.
Thanks for sharing!
That's definitely an involved project. Love the idea of using the driver board for PFC
there's a good chance path blending is causing trouble, set g64 to p0.01 in your INI for the rs242 startup routine. The problem with the encoder handling within linuxcnc, is that it is not done by interupt, and I kinda went on a rant about it a few months ago. I have been working on porting EMC2 to OpenRTOS from TexasInstruments for use on their hardware. But dude, I don't have enough time. I think getting EMC off of linux is where I would start. Then with some work there's a way to fix the short coming of the control software. Keep me aprised though, I have some skills as a C programmer for state type logic and deep mechanical engineering skills.
Suggest you aim to include dual STO inputs on the motor controller. And set up the safety+motion controller to eventually support Safe stop 1 (SS1) - which is basically just a configurable delay before triggering STO. Have the motor controllers in charge of the brakes, and link that in to STO chain.
Awesome work! Most is over my head, but I love trying to understand.
SO impressed. Hope you release your solutions to the world.
Super interesting project and looking forward to see how things progress. If you are looking for ways to simulate your robot and test out/tune your motion control there are a number of open-source versions of common tools used in industry, such as OpenModelica, Scilab, & others. They have somewhat of a learning curve but it's amazing how much control prototyping you can do with just a simulated model of your system and then fine tune with the real system once you have something working.
I have used ROS (Robot Operating System) with the MoveIt program to control a custom robot arm. I never ended up finishing the project, but it wasnt to hard to get Moveit to work with my arm, and using ROS would make it potentially easier to setup the encoders and all the other control stuff.
A intresting thought , feed the signalns and movment to a neural network , and task to translate the signals of the decoders.
This has been a very fun watch. I went through almost the exact same thing with a Unimate PUMA 560 robot I wanted to resurrect. Similar hardware encoder issues, similar starting again from scratch mid-way through situation... stay strong.
I love what you are doing. Subscribed. Keep up the good work.
Your explanation of motor controllers and motion controllers was very good. Not many people understand this.
Super cool! The engineering department at my college has one of these and I never knew about all the intricacies involved with having it communicate with a computer.
This is a great thing you're working on. Well designed open source controller would be able to help revive tons of mechanically fine robots with dead electonics. If you'd like some FPGA support, let me know. regards, hypernyan
You should join the discord! I'm working on getting a contribution system planned out so we can begin diving into the coding.
If you build that controller, you would make a killing. Not only that but you would open the doors for so many people that don't have your expertise (like myself...) to do some really cool stuff! I say do it!
Hi german automation software developer for industrial robots here; I madly aprove.
we need Open source Robot Controllers.
Annin Robotics is a start. I would eliminate the steppers (even if they are closed-loop) in favor of servos.
Good luck! I've stayed away from FPGAs because I just consider them above my pay grade. I'm not afraid to jump into unknown waters, but it's already hard enough learning how to write and debug embedded MCU code, not to mention motor control stuff.
This sounds like an incredibly interesting project. Can’t wait for more updates.
Amazing... I only wish I had spent my early EE days learning FPGAs... I don't think my instructors had a clue either. Great overall explanation of the state of options for controlling industrial robots.
Internet - do your thing. This would be so awesome to have a community around this project
WOW, such a massive project for one guy alone, huh! I'm anxious for the next chapters! Keep this wonderful content, please.
Very nice video and super interesting project! Just one advise from my side, if you push the robot (like in 11:14) please have a deadman switch at hand, even if you are 99% sure that nothing can happen.
Have you heard of EtherCAT? It's a network protocol for industrial automation that can do up to 30kHz update rates with low latency and jitter. You would daisy-chain your motor controllers up with using ethernet and hook up the whole thing to a computer that runs the motion control. The chips to do it are surspringly cheap (LAN9252 is ~$10) and can be used with any microcontroller or FPGA. Maybe this could be a fit for this project, as this would make it much more modular and extensible. Adding peripheries or even an additional axis would just be a matter of adding another box to the network.
(also it wouldn't require to design everything from scratch, there are already a lot of EtherCAT motor drives out there).
I did look into using ethercat but the IP for the fpgas was like $10k. I think I thought the off the shelf chips wouldn't work for some reason, I don't remember exact why rn. I planned on using rs422 which would give me like 30khz updates with no daisy chaining, but I'll look into those chips again.
@@ExcessiveOverkill This was my gut reaction as well - RS422 but with separate drivers for each motor channel for best throughput. Ethercat is price overkill
"low latency and jitter" they boast as if it's a _good_ thing ("a little bit pregnant"?). How about _zero_ latency/jitter. It's a world of EMI (PWM), who in their right mind throws around data at such a high rate? Marketing BS.
This is an incredible undertaking! Subbed to see where this goes!
I would love an inexpensive HV motor driver like that! I do quite a bit of motion control/robotics/embedded systems as a hobby, and my day job is industrial control systems, so I actually have a few motors laying around it would be nice to have drivers for. and a project like this really gets me excited!
it would be great fun if that could run with a 480VAC supply, as that would be easy and cheap enough to rig up a transformer for in a residential setting, and could run some really high performance motors. but then you got to deal with the nearly 700V peak to peak voltage...
I don't see very many quadrature/incremental encoders in my day-day, they have largely been replaced by EnDAT, Hiperface DSL, and SSI. I've even dealt with a few that go direct to EtherCAT.
as you mentioned, an FPGA could certainly talk to all of those protocols, however a lot of modern micro-controllers have some kind of programmable hardware fabric that could likely be convinced to speak most of those protocols outside of the actual CPU. Cypress's PSoC architecture, and the Ras-Pi RP2040's PIO state machines both come to mind as possible options that would be ~1/10 the cost.
Thanks for the awesome niche content. definitely cant wait to see where this goes!
Man this is awesome. Good luck and keep up. I wish you the best of luck!!
You rock! Awesome series, thanks for uploading
First time seeing one of your videos! Loved it & got a sub from me. Looking forward to watching the project grow
you work as a genius. but i think open source for industry robot is imposible. just the dream. thanks for your great work. waiting for your next content.
I just discovered your channel thanks to yt magic. I'm looking forward to seeing where this goes and hope that you'll do so well that you can make this a full time gig!
Low voltages caused by high resistance neg/gnd loops or voltage leaks causing positive gnd. Also, back emf can cause dropouts due to the control sigs not having enough disparity between VCC and GND(seen on the oscilloscope with the base voltage jump 4:52)
Possibly Separate each GND from the motor/actuator from all other controllers
This is like an upgraded crane, almost, but more mobile and smaller. Great work, would love to build one of these for myself and see what they do. Integration of large machines like this could eventually become a large exoskeleton like the AMP suit, or some sort of mech. Love to see what you're doing with this later, you've got a like and sub. Keep it up man. 👍
I think the community missed the opportunity to hire you full time as this project is easily worth a salary.
I'm a purely mechanical guy, but this is some Deep nerd stuff right here, not in an arrogant way tho just waaay deeper than I could comprehend
This is the way. Reduce, reuse, recycle. Well done on the effort so far!
I Love your vision! Keep it up, one more fan won right now! Greetings from Germany Julian
Out of nowhere: Lets rely on learning VHDL or Verilog and programming an FPGA just for fun and by the challenge to conclude a project !
There will be many nights over my friend, good luck
Yes, it’s not fun if it’s not challenging
@@ExcessiveOverkill Don't fall into the trap many FPGA beginners do and test in real hardware without simulating. It makes debugging very painful, not least because of the incredibly long build times. Have fun with Vivado :)
Have you seen the VESC Project? By far the best Open Source brushless motor Controller. Supports many encoders and protocols
On the one hand this is very impressive, on the other the time saved to just buy a slightly newer robot and instead put the effort toward something like open source middleware to do the CAM to Robot language. Right now it seems the choice is either something really expensive like SprutCAM or something only slightly expensive like RoboDK. I'm no robot expert, but it seems whatever system you come up with will always lack what a user would get from a functioning commercial robot controller. I've seen 2016 ABB robots go for $5k at auction recently, these were not beat units. I'm in the process of setting up a 2013 ABB 6640 (180kg payload, 2.55m reach). I did pay a lot more for it than $5k, but it came with 7th axis and a guarantee... Anyway good luck with whatever path you choose.
Really cool stuff, looking forward to the next episode!
Really interesting and look forward to seeing more. Thank you.
Interesting project!
Re. the drive system, I'd suggest you break it down a bit, for each axis:
A dual-loop speed servo, with the outer loop managing speed error and the inner loop managing motor drive current.
Then separately, a position loop that compares instantaneous target position to actual position and gives the speed servo a signal directly proportional to that, limited to ~80% the maximum drive system speed capability (or whatever below that you consider safe).
The G Code interpreter and path calculation system only update the target positions & the servo position system half makes the machine track that.
That's how large machine tools typically work. Some also have an element of the path speed added in to the loop to reduce following error at higher feedrates, but that is very critical and can easily cause instability, so I'd suggest you use the pure "following error * fixed gain -> speed" setup.
In a machine with good mechanics and low backlash, the gain constant is usually set to give 1mm following error at 1m/minute feed, on a linear axis. I'm not quite sure how that translates to rotary!
The current loop section of the speed drive has an integrator (or PID), so the current (motor torque) adapts to the load without any significant change in following error. Position holding should be limited only by the motor capability and mechanical strength of the machine, at that.
I spent a lot of time with the first system I designed (early 80s) trying different control strategies but it came down to the simple, linear, following error to velocity setup being the most effective and accurate.
(The controller ran on an MC6809 at 2MHz, with resolver position feedback and Inland Motor TPAR analog / thyristor axis drives, on 10m and 5m Butler Elgamills, replacing dead bitslice CPU paper tape systems. They used all fixed-point maths except for the operator position display, and no trig at all, even for radius / circle interpolation).
your garage is the Bat Cave!!
First time here and already know where the channel name comes from, looking at the linear guide and block for the revised pen holder. 👍
Oh woah! he's back!
this video makes me want to get back into this stuff. I joined the discord. my background is mechatronics. I ran a machine shop for 5 years. I know machining, best practice for design, and a little bit of general programming and about microcontrollers, but never took the dive into making my own boards. I always saw H Bridges and thought it was criminal how they were priced. It makes any hobby project relatively expensive (especially for people still in school who are interested in this sort of stuff like grade 12 through university).
Its this sort of work that give me hope for our future, one where manfactoring isnput back in the hands of the people and not the rich
If you do need to desolder those mosfets at 13:18 , its not that hard to get them off in one go. Take a paperclip or similar thickness piece of uninsulated copper wire, and solder it to each of the through hole components legs with a big blob of solder. Then heat the wire up with a large soldering iron tip. The wire transfers the irons heat to each of the legs pretty equally, and you can just pull the component out from the other side of the board.
Also, a syringe style solder sucker can work well.
Hi, I've been working on a similar type of motor control project that uses FPGAs to control smaller / lover voltage BLDC motors. I found a pretty sweet FPGA that I've been developing with that might be a good match if you want to swap the zynq out for a smaller FPGA that would live in each motor controller (it is also waaaay cheaper). The chip is a Gowin GW1NSR-LV4C. Sipeed makes a dev board for it that is pretty good for figuring out their toolchain. It has a single ARM cortex M3 along with 4K logic elements which is definitely enough for some custom communications peripherals and a FOC algorithm at some pretty high speeds (I'm trying to do all of my loops at 40Khz +)
Weirdly, I've been noodling doing the exact same thing. Using FPGAs to handle encoders. I can only wish you the best of luck because this seems like a TREMENDOUS undertaking.
Why not run a dedicated microcontroller per encoder? Won't a 80MHz controller be able to sample the encoder and sent the count upon a request? They have interupt gpio so you never miss a pulse.
At 80MHz you would have many instructons to sample at 3kHz.
Truly Inspiring, I will follow all the steps.
Looks like a robot out of the Body shop in a GM plant. :) I hope that you weren't hanging off of that robot while it was live...
man this is pure gold, so underrated! Keet it up 🚀
Man, You are crazy! I wish You luck.
My guy, you're an absolute Wizz! God Bless!
Excellent work! looking forward to seeing how it goes
Awesome. You've given me hope for my Fanuc 100!
I’m interested. I ended up passing up on 2 free Fanuc welding arms because I realized it was going to be impossible for me to reverse engineer the motor and motion control. I can follow directions and learn along the way, but blazing the trail you’re on is outside my capabilities.
Thats seriosuly impressive i love that.. I want to build one in future
I hope the drive goes well.
Can't wait to see Rob (RO8) cutting some interesting stuff with its router spindle.
Just found this channel and subscribed within the first 43 seconds this is the shit.
Brilliant - keep going with this - love to see it move forward
Look into Cypress PSoC 5. I've been able to synthesize motor drivers in the fabric before, the microcontrollers run at 80MHz, they're super easy to program, and pretty inexpensive
Good luck 👍
my first thought is maybe the brakes spontaneously engage for just a fraction of a second when the supply voltage drops due to the servo motors are drawing some current.
Did anything ever replace TinyG? Last I looked (years), there was nothing that good out there for DIY CNC controllers, although some mention of people repurposing Klipper.
I would be surprised if a 600 MHz M7 MCU would not be able to handle this application with appropriate programming. The CMSIS DSP lib has accelerated PID controllers for f32 and q15/31 formats.
FPGA tools are less insane now. Yosys support Lattice, Gowin, etc to varying degrees.
MYIR Tech has some Zynq modules that you might want to look at.
Digilent has a socketable Spartan-7 module. Sipeed has a cheap Gowin-based 20k gate board. Both of those will have limited I/O, though.
Been binging your channel and this upload got me all hyped to see it pop up lol thanks for making me want a robot arm now 😂
This is great, glad to see a part two
What a wealth of information. Great work.
You are an absolute madlad! Awesome!
If you manage to make a decent DIY/retrofit controller available for older servo drives/motors/robots it could become quite useful in the CNC world as well. Alot of older good heavy machines are send to scrap metal because their lack of recent motion and electronics. Alot of them use FANUC components.
I would use Beckkoff Ethercat motor controllers driving them using LinuxCnc. LinuxCnc is the motion controller giving only target values and the motor controller read the encoders and does the control and pid calculations
You are blowing my mind