Hi! Do you think it is possible to use this robot arm in the actual industrial working environment, where it requires high precision as well as long-term repeatability? We also build the AR4 with the intention to put it into industrial workplace but it didn't turn out so well so now we consider another low-cost solution, which is this one. Can you give us some feedback on this
Hi, so I have yet to personally put this robot through the wringer. However, I know that Igus rigorously tests their robots. They run them for hours and hours to ensure that they perform over time. When I was at automate they ran it for basically three days straight with constant motion and had no issues. In terms of repeatability they do have a video here showcasing it ua-cam.com/video/nDjTJ1MehOc/v-deo.html . It definitely does not have the accuracy of some of the more mainstream $$$ arms out there but for pick and place it should be able to get job done. So depends on what your application is. How accurate do you need it to be? Are you simply moving things from one place to another?
@@theweblover007 I never really got as far as using the AR4 in production environment. It more had to do with reliability and scalability. 1. Each of the joints on the AR4 are different, this means you may experience various mechanical issues that are unique to each joint and solutions don't apply to the others 2. The AR4 uses rotary encoders, as apposed to absolute encoders which make things more repeatable and simple ( and also removes the need for home after a reboot or Estop ) 3. It took a while to build, LOTS of tedious wiring, there are over 60 wires you need to route and mangle, and if anything goes wrong with one connection its not fun to debug that. Dealing with this for more than one robot would be a large hassle. Overall its a really awesome robot! One that Im glad I built and get to play with, but ultimately Im not going to use it for any production applications.
@@theweblover007 I would say the robot arm lacks precision over time, especially for tasks that require high precision. For example, I tried to program it to pick up a small piece of gear and put it into the slot, over time, it start to lose position and fail a task after 3-4 times of repeat, even though I tried to calibrate after every cycle. I believe it is because of the motor backlash since it uses rotary motors like @robotjs said. Another would be the speed, since the 7-axis rail movement is pretty slow, as well as other joints on the robot itself. In my perspective, AR4 is an awesome robot arm for robotics hobbyists to build and play with, but if you want to put it into the workplace, it may not be ideal
Hi, Great channel!! We copy your rebel project. (Rebel, Raspberry Pi, Can Hat, Powersupply and your Github information) But the final communication with the rebel we can't establish. (almost there but missing the final step) Do you have a some tips. We miss something but can't find what it is. Thanks for your help.
Make sure the correct can network is configured inside of "robot.js" file. I think its set to can1. Also make sure the can interface is up. To test communication, go to the motor tab in the user interface and try to type 1 and then 1 into the two inputs for parameter query and click "Query" if something gets written to the json below then its talking. If not then something is wrong. Also check to make sure you are reading 60 ohms for a resistance on the CAN bus.
If you still see issues try to bring down then back up the can interface and then run the program again. Also can you confirm that at least the robot is showing up in the robot dropdown? So the igus-motor-controller is at least talking to robot viewer?
@@robotjs I am a colleague of Martien. From our understanding, "mock" refers to emulating an Arduino, but which specific Arduino model should be emulated and what code should be running on it? Thank you for your initial response; it was greatly appreciated.
@@SebastianOlthuis-qh8bb so the arduino is ONLY used for the gripper. The robot can be run without it. I like to use johnny-five.io/ to control arduinos, so mine is flashed with firmata see here >>> johnny-five.io/platform-support/ . But again this is NOT needed at all to run the robot. I added it after so I could interact with digital IO. --mock simply creates a mock board so the code will run without crashing. You could even comment out that code so the johnny-five never even runs.
Hi! Do you think it is possible to use this robot arm in the actual industrial working environment, where it requires high precision as well as long-term repeatability? We also build the AR4 with the intention to put it into industrial workplace but it didn't turn out so well so now we consider another low-cost solution, which is this one. Can you give us some feedback on this
Hi, so I have yet to personally put this robot through the wringer. However, I know that Igus rigorously tests their robots. They run them for hours and hours to ensure that they perform over time. When I was at automate they ran it for basically three days straight with constant motion and had no issues. In terms of repeatability they do have a video here showcasing it ua-cam.com/video/nDjTJ1MehOc/v-deo.html . It definitely does not have the accuracy of some of the more mainstream $$$ arms out there but for pick and place it should be able to get job done. So depends on what your application is. How accurate do you need it to be? Are you simply moving things from one place to another?
Hey, What all issues did you face with the AR4 in industry environement. I had some ideas around it and would love to know about your experience.
@@theweblover007 I never really got as far as using the AR4 in production environment. It more had to do with reliability and scalability.
1. Each of the joints on the AR4 are different, this means you may experience various mechanical issues that are unique to each joint and solutions don't apply to the others
2. The AR4 uses rotary encoders, as apposed to absolute encoders which make things more repeatable and simple ( and also removes the need for home after a reboot or Estop )
3. It took a while to build, LOTS of tedious wiring, there are over 60 wires you need to route and mangle, and if anything goes wrong with one connection its not fun to debug that. Dealing with this for more than one robot would be a large hassle.
Overall its a really awesome robot! One that Im glad I built and get to play with, but ultimately Im not going to use it for any production applications.
@@theweblover007 I would say the robot arm lacks precision over time, especially for tasks that require high precision. For example, I tried to program it to pick up a small piece of gear and put it into the slot, over time, it start to lose position and fail a task after 3-4 times of repeat, even though I tried to calibrate after every cycle. I believe it is because of the motor backlash since it uses rotary motors like @robotjs said. Another would be the speed, since the 7-axis rail movement is pretty slow, as well as other joints on the robot itself. In my perspective, AR4 is an awesome robot arm for robotics hobbyists to build and play with, but if you want to put it into the workplace, it may not be ideal
Hi, Great channel!! We copy your rebel project. (Rebel, Raspberry Pi, Can Hat, Powersupply and your Github information) But the final communication with the rebel we can't establish. (almost there but missing the final step) Do you have a some tips. We miss something but can't find what it is. Thanks for your help.
Make sure the correct can network is configured inside of "robot.js" file. I think its set to can1. Also make sure the can interface is up. To test communication, go to the motor tab in the user interface and try to type 1 and then 1 into the two inputs for parameter query and click "Query" if something gets written to the json below then its talking. If not then something is wrong. Also check to make sure you are reading 60 ohms for a resistance on the CAN bus.
If you still see issues try to bring down then back up the can interface and then run the program again. Also can you confirm that at least the robot is showing up in the robot dropdown? So the igus-motor-controller is at least talking to robot viewer?
@@robotjs I am a colleague of Martien. From our understanding, "mock" refers to emulating an Arduino, but which specific Arduino model should be emulated and what code should be running on it? Thank you for your initial response; it was greatly appreciated.
@@SebastianOlthuis-qh8bb so the arduino is ONLY used for the gripper. The robot can be run without it. I like to use johnny-five.io/ to control arduinos, so mine is flashed with firmata see here >>> johnny-five.io/platform-support/ . But again this is NOT needed at all to run the robot. I added it after so I could interact with digital IO. --mock simply creates a mock board so the code will run without crashing. You could even comment out that code so the johnny-five never even runs.