[rett84]

Hello all,

I have implemented in python a TCP sockets client that receives X,Y,Z and angle points from a PC based CNC controller which has a TCP sockets server. The points that I am streaming are very close 0.1-1mm. I send chunks of 60 points at a time to keep up with the robot motion to avoid jerky moves or stop times.

The simulation works really well. Robot motion is very smooth and there is no data starving. Video in the link below shows Motoman robot simulation receiving points from my CNC controller. My next step was to test with a real robot using the robots drivers, which are awesome by the way! 

https://drive.google.com/open?id=18YuMGB...jJUR8du_I8



We have here at the shop a KRC2 KUKA controller. I tested the same simulation but changing to a KUKA manipulator and behaviour is the same with smooth motion. But when I test with the real robot, with robot speed at 10%, motion gets jerky and looks like the system is not keeping up send new points. Robot speed at 5% runs ok. I understand the KUKA driver uses KUKAVARPROXY which might be adding latency to the system.

I would like your advice to improve the robot motion if possible, but I have a few questions.

First, I developed my python program using Visual Studio(to test and debug the code). I can start my python program from Visual Studio and run the simulation in RoboDK. If I want to run the same code on the real robot I need to add the python file to a station and run the python program from RoboDK. If I don't do that, I can still run the python program from Visual Studio, the robot simulation starts e the virtual robot moves, but the real robot does not move(the driver is connect all the time). It is a strange behaviour. Is it possible to change this behaviour and call the robot driver from python and not run from RoboDK?

If not, can I disable the simulation when running on the real robot? Both he simulation and real robot position are synchronized in real time. This might be adding a delay to the system.

Also when the python program calls the RoboDK API it starts RoboDK automatically. How can I disable this?


Thank you for your help and RoboDK is a great tool!

[Albert]

Your project looks good. Displaying data on the screen adds some delay, but it should be irrelevant compared to the delay provoked by the robot motion and communication. Industrial robots do not digest high density of points unless you use dedicated communication protocols specific to each robot.

In any case, you can try turning off display Rendering:

RDK.Render(False)

[workfive]

Just out of curiosity why would you want to stream machining paths to a robot? Typically you would want "absolute control" over the machine to achieve high quality work; hence you probably would need a good CNC (G-Code) interpreter for your KUKA arm to load millions of points and control feeds and speeds, something that KRL cannot do, infact KRL can't even look ahead more than 5 points which is absurd when machining things. If you are simply playing around, then what you have is probably fine (you could try blending although 0.1mm is very tight, you may need to reduce the speed even more, and you could try streaming the points at 20ms, or package them in a SPL container), in any case be careful not to damage your joints. We have all our machines online via ROS but we never feed straight to them via the network, instead we interact with them by loading and unloading data so the controllers can do the jobs they were designed for. Lastly simulation and the real world are two very different environments. Have fun and I look forward to seeing where this is going.

[rett84]

Good to see people interested in this project. 

Machining with robots is not something new. Guys have done it at my shop using Robomaster with ABB and KUKA robots. I'm not sure about what you mean "absolute control"? If you mean controlling peripherals, feed rates, etc. I'm using a Soft PLC-based PC controller Codesys V3, which has an NC file decoder and all the tools to build a CNC controller. The interface you see in the video and all the programming was done in Codesys.

This project is a bit of playing around and not. My intention is to build a unified CNC controller that can either operate robotic manipulators or standard 3/4/5 axis systems. The kinematics for the tables are in Codesys, for the robots Robodk and its functionalities, as robot drivers and unified programming for different robot brands(Python) and simulation come in play.

At the shop that I work we do a lot of waterjet cutting, 2D and 3D, as well a 3D printing machine is being develped. My intention is to have a unified control system for either a robotic or multi-axis system.

I have successfully retrofitted an old Flying Bridge X-Y with Yaskawa Sigma 2 drives using this same CNC controller and project that you see in the video(actually running on a Raspberry Pi, as Codesys has a Raspberry Pi runtime as well). Specific routines are selected for each mechanism of course.

So far my testing with a KUKA KRC2 robot is doing well, the robot follows the programmed path. Speeds and etc are still under testing. I'm having one issue, which I have created another post in this forum about it. Thing is, I need more hardware(and time), eg different machine configurations, robot brands etc, to test more as well. My resources are limited.

Preferably I want to use an accessible CAM package. I have been using Fusion 360. I'm not an expert in this area at all, just a curious Electrical Engineer.

I'm somewhat familiar with ROS. Before developing this system I was reading about ROS as well. I understand ROS downloads trajectories to the robots. But, it looks like it streams points to Motoman robots, but I don't remember exactly. Regardless, because I want to control different mechanisms with one interface, ROS is not suitable.

I'm aware of the lookahead limitation on robot planners. But I wonder, does the same limitation applies when code is generated by RoboDK or RoboMaster for example? Maybe machining won't be possible, but if it works with cutting processes and 3D printing that would be a huge step. 

We can keep the discussion if you are interested.

[Jeremy]

Hi there,

If you are using Fusion 360, you might be interested in our new plugin.
It's not officially released, but you can download a beta version here :
https://robodk.com/downloads/plugins/Fus...plugin.zip

It works exactly in the same way as our other plugin for Rhino, SolidWorks and Inventor.
You can take a look at our YouTube channel for some tutorial on the subject.

Have a great day.
Jeremy

[Albert]

Hi @rett84,

We have a RoboDK version for the Raspberry Pi available:
https://robodk.com/downloads/RoboDK-Pi.tar.gz

There are 2 files that will help you install and start RoboDK:

• Install-RoboDK.sh - Installs RoboDK dependencies. Make sure to have internet connection when you run it. It also creates a copy of RoboDK binaries and required files in the home directory. You'll also see a Desktop shortcut when the install completes.
  
• RoboDK-Start.sh - Start RoboDK (same as double clicking the Desktop shortcut).
  

You can replace the attached 2 files by the ones in the download link as we've improved a few details. More updates and improvements for the Raspberry Pi will come in the next few days. The new Raspberry Pi 4 looks promising with official support for OpenGL. We'll optimize performance soon.

I'm not sure if you already contacted us by email and we provided this information to you. In any case, let us know if you see any issues or suggestions for improvements. 

Albert

[rett84]

Thanks Jeremy and Albert.

This is super cool to have RoboDK running on a Raspberry Pi! I haven't contacted you guys, but for sure I will provide feedback once I test it and if I find issues or improvements.


Thanks!