There is no correct answer to this. It depends on your situation and objectives. You should also consider that you are asking this on a ROS Q&A forum where more people will be familiar with ROS rather than Robot Studio. That said:
- When you say "make a pick and place robot", are you making a robot system to resell? Or are you implementing something for an employer or client?
- Are you designing a gripper yourself, or are you buying a commercially available one?
- What are you picking and placing? Is it always in the same place, or do you need to integrate a third party's vision system to determine its position?
- Will you maintain the system in the future? Will you need to change the robot or parts of the system to a different model or brand? Do you plan to reuse the code?
- What are the budget and safety (certification) constraints?
I am not particularly familiar with Robot Studio, and only skimmed the tutorial videos. I gather that it is ABB's software solution with pre-existing assets, that their GUI will be convenient for the use cases they envision (deploying their robots for particular applications), and that you will have someone to complain to and get support from when things do not work. I cannot judge the quality of the software, but I assume that you will have an easier time implementing things that the software (or whichever package you purchased) supports.
From my experience, the downside of many proprietary solutions consists of closed interfaces, vendor lock and lack of flexibility. You may want to add new vision system or another sensor to your robot that is not supported out of the box. You may want to parametrize your workpieces and pass data to the robot in a new way to continue your project. You may want to do X new thing. Oftentimes, the only option you have is to ask the vendor to implement the new interface for you, pay them for additional functionality, or to give up on the project altogether. If your software was open-source, the interface would be open to start with, you could implement a new feature yourself, reuse someone else's work (if e.g. a package for a new sensor has already been published), or ask any contractor to implement it on your schedule (instead of hoping your software vendor will get around to your request).
If you know that you will want to:
- Reuse code from this project with different robots/brands/systems
- Modify the system in a way that the vendor's "suite" software does not support
- Avoid depending on the robot vendor and software for whichever reason
Then it is likely that you will be better served with ROS or other open-source solutions. If you know that your use case can be easily solved by proprietary solution, you are under tight time (and not-as-tight budgetary) constraints, and that staying within a vendor's ecosystem will not pose problems ... (more)
