Depends. Do you speak/read Chinese? Do you have an "in" with the manufacturer, or know someone who does?
My experience so far with Chinese robots has been 100% universally 
So far, every Chinese robot I've encountered has been a cheap knockoff of a Major Brand robot that is poorly made, very poorly documented, has no effective tech support, runs on crappy software, and generally shows signs of an attempt to copy a Major Brand robot without understanding anything about what makes that Major Brand robot worth buying.
Also, I wouldn't trust the safety features on any Chinese robot I've used any further than I could throw a cheesecake underwater.
The only way I would buy one of those robots would be if:
1. I bought a bunch of extras to use as replacements or as sources of spare parts
2. I hardwired my own safeties, and/or surrounded the robots with solid fencing the robots couldn't possibly punch through
3. Did nothing with them more complex than simple pick&place or spot welding.
In the interests of being fair, there may be Chinese robots out there that are better, and I've just had bad luck so far. But based on my experience with other Chinese-designed and -built systems, I'm not optimistic. There's a very consistent "amateur hour engineering" vibe in my experience, along with a frightening ignorance of even the most basic safety principles.
I usually don't care too much about spares, documentation, but would like decent software.
Well, I can only say that after ~30 years in robotics, I care very much about all three.
Does attaching cognex cameras to them and using insight software negate robot manufacturer software? It seems to me that cognex does all robotic guidance and directs the robot where to go.
Not even remotely. Adding Machine Vision (of any brand) involves an interaction between the MV system and the robot's own software. And the complexity of that interaction scales up faster than the complexity of the application.
For example, I once had a vision system that worked purely in Base Frame offsets, that the customer bought to put on a robot that couldn't support Base Frame offsets. Kludging together a solution that mostly worked was a nightmare... in no small part b/c that brand of robot had poor documentation of the details of its kinematic system and geometrical offset methods.
No MV "takes over" from the robot -- at most, the MV system takes a measurement, and passes that measurement to the robot. For this measurement to be at all useful, the robot and MV must be correctly calibrated to each other, or to some shared common reference frame. And even if the measurement is correct, it's still up to the robot to actually use that measurement in some meaningful way. And intelligently -- when I was still new at this, I didn't limit-check the vision measurements in the robot, and ran the robot straight into the floor b/c the packet data got corrupted somehow and 100.00 became 10000.
packet data got corrupted somehow and 100.00 became 10000.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
Interesting. A single bit flip could cause this, assuming they are sending the offsets via strings.
. in the ASCII table is 46, which is 0010 1110.
, in the ASCII table is 44, which is 0010 1100.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
Nah, it really was packet corruption in this instance. It's embarrassing to admit, but this was a long time ago -- the Vision guys thought I was doing the limit checking, and I thought they were doing the limit checking. And the system ran perfectly for over a thousand cycles... until the day of the customer buyoff when that decimal got dropped in the communication channel and we learned the hard way that no one was doing the limit checking. (sad trombone noise here).
Interesting. A single bit flip could cause this, assuming they are sending the offsets via strings.
. in the ASCII table is 46, which is 0010 1110., in the ASCII table is 44, which is 0010 1100.
Huh! I did not know that, but it could handily explain what happened. IIRC, I just added a couple re-try cycles, and if the data from the vision system didn't come back within acceptable limits after 2-3 attempts, then we bailed out and summoned an operator.
in the ASCII table is 46 "."
in the ASCII table is 44 ","
And the system ran perfectly for over a thousand cycles
then this was probably not the case
not sure if its a cobot. It only goes to 2000mm/s with 5kg load.
Nothing moving that fast with that payload qualifies as Collaborative. That robot with no payload moving at 2m/s would not qualify. It doesn't matter how advanced its collision detection is, nothing moving that fast can stop fast enough to avoid causing injury.
Nothing moving that fast with that payload qualifies as Collaborative. That robot with no payload moving at 2m/s would not qualify. It doesn't matter how advanced its collision detection is, nothing moving that fast can stop fast enough to avoid causing injury.
Why can't vision be added to make it a cobot? When it detects human in near vicinity it slows down, should be simple to program?
No problem at all, it's as easy as everytime, if you have a problem, throw a vision system on it and all is done. If that's not enough just add something with AI at the latest now every problem is solved. 
It's not only the speed, but also things like torque, reliability, fail safe... 
how do you expect to meet safety requirements prescribed by regulations? safety circuits in robotics applications require functional safety. used components have to be safety rated and certified, use redundancy, monitoring etc.
you did not answer the question. robot guarding requires safety components and circuits. you mentioned using camera to achieve this. can you please point to specific camera you had in mind and why do you think this qualifies for safety applications? or did you by "vision" mean something else like area laser scanners?
Nevermind, it may take more work software wise then installing one of these:
Need to figure out how to attach to back of my robot?
Why can't vision be added to make it a cobot? When it detects human in near vicinity it slows down, should be simple to program?
Well, I think the issues that self-driving cars have with reliably detecting humans is illustrative. Not to mention getting 100% volumetric coverage, and being able to ensure that any such detections are 99.99999% reliable and fast enough.
There is a fairly new product on the market called FreeMove, that uses a number of depth cameras spaced around the cell. I don't think it tries to detect humans, as much as human-sized objects that are moving in areas whose fixed obstructions have been mapped. And it took over 5 years, IIRC, to get all of the required safety regulatory certifications.
