When you start thinking about implementing a robotics system, you might come up with some exciting ideas. Maybe you know exactly which problem you want to solve, or you’ve already got a specific vision of the platform you want to build. It’s only natural that you’d want to put your idea into action immediately by contacting robotics service providers about when they can make it a reality.

But before you can get into actually building it, it’s important to clarify a few things about your application. If you overlook these details in your haste to get a quote from a robotics service provider, you’ll have to go back and sort them out before you can continue the conversation. 

We’ve listed the key questions below. Answer them before reaching out to different robotics companies, and you’ll save time and have much more productive discussions with prospective service providers. 

First, ask yourself:

1. How do you want the robot to work?

You’ve probably got a general idea of what you want the robot to do. The following questions will help you drill down into the details.

Autonomously or remote-controlled?

Do you need the robot to operate completely autonomously, or can some (or all) steps be remote-controlled by a human?

Can you use remote controls at first for a proof of concept, and move towards a more autonomous system later?

Operated by an expert or a beginner?

For example, a software engineer has a very different user profile from a nurse or other service provider who is not well versed in robotics.

Accurately, quickly, with a wide range—or all three?

How precisely should the robot be able to navigate its environment?

Does it need to follow a path exactly (such as for driving over a narrow plank, or navigating a hallway without touching the walls), or will it be in a wide-open space?

How accurately should the robot be able to position itself at its end point?

For picking fruit in an orchard, for example, you would probably need quite a precise robot—but it depends on the size of the fruit, and how close each piece of fruit is to the others. 

You might set up a robot that carries a bin and follows people while they pick fruit. In that case, you would probably be fine with a robot that can get within 18 inches of the person. Whereas if you need the robot itself to pick the fruit, you might need the robot to be able to position itself in front of the fruit with <1-inch precision.

What will the power supply look like?

Consider the run time you want, vs. the run time you actually need. You might want the robot to be able to run for eight hours—but can you get away with four?

If you need a longer run time from the robot you’re considering, ask what sort of power supply is compatible. It could be batteries, batteries plus a generator, a charging dock, swappable batteries, or something else.

Indoors or outdoors?

Where will your solution be deployed: a research lab, factory, or in the wild?

If outdoors, does the robot need to work in all weather conditions? What type of weather is most common in your area of operation?

Isolated or near people?

Will the robot be working by itself or with humans?

Will people be in close proximity to the robot—walking around it, or potentially able to come in contact with it?

Are these humans trained to work with robots, or are they members of the general public?

2. How much functionality do you really need for your solution?  

Which technology readiness level are you aiming for?

Are you looking to buy a “product” that you will ultimately resell?

How many do you hope to have available to sell? By when?

What are your must-haves, and what are merely nice-to-haves?

As you get into budget discussions, it will be helpful to have an idea of what you’re willing to give up for the time being. You can always add on other functionalities later.

3. What’s your timeline?

Depending on your project’s complexity, you may be looking at six months to a year or more before you have a working prototype. How does that impact your plans?

Will you be handling any aspects of the development yourself (like the software or user interface)?

If you’re working through a custom development cycle, you will need to allow time for initial scoping/planning, prototyping, and several iteration(s) to get you to the end goal.

Does your use case require safety certification? 

Check if your industry or geographical area requires any safety certifications, like the CE markings required in Europe. The certification process can add months to the project.

Next, ask the robotics company:

1. What’s your outlook?

Given the discussed use case, does anything strike you as unreasonable?

Some proposed use cases we’ve heard of would require the company to solve a new problem in robotics within six months. That’s not going to go well.

2. What’s your timeline?

When could you start working on this?

How quickly can you hire more people, if that becomes necessary to meet timeline requirements?

What do you think might be some sources of delays?

Part lead times, certifications, and solving new problems in robotics (not recommended) are likely candidates.

3. What’s your experience?

Have you worked on similar projects before (product, scale, timeline)? How did those turn out?

4. What can you offer us right now: general guidelines, concept designs, or a full proof of concept?

Can we leverage existing technology to get a proof of concept quickly?

You might want to consider using an existing robotics platform as a stand-in for now to see whether the rough application idea would work.

(This is exactly what Clearpath robotic platforms are for: developing your own application without needing to do all the work involved in a custom design!)

We usually recommend starting with one of our platforms, like the Husky, where we can figure out what sensor array or configuration you might need, add any software you might want to put on it, and develop a basic application with that setup to see if it works. We can usually do all that in our facility, or on-site if the customer has the space for it.

For example, at airports, carts are loaded with baggage and pulled by a piece of equipment called a tugger, driven by a human employee. 

We might use a Husky as a stand-in for a baggage tugger to test the idea of an autonomous baggage mover before we do all the work of developing a new, fully automated tugger. 

Conclusion

By keeping these points in mind before you start reaching out to different robotics companies, you’ll be able to frame your conversation with robotics businesses—and better determine the right service provider for you.

Are you looking to take your project to the next level, whether by supporting your ROS initiatives, moving a project from conception to design, or getting full- service execution?  Contact us and we’ll help point you in the right direction.