I think you have to start the project like any other engineering project, with requirements definition. What will this machine do?
- What will it move, lumber, small parts from bins of loose parts, boxes?
What is the payload mass?
- How will it load the payload material? Do human workers load it?
- How is the AMR told where to do a pickup and drop off?
What if there are many of these robots, A call goes out for a pickup, how is it decided which robot gets this call? Do the robots communicate or is there a central planner?
- Can it do multiple pickups and drops and remember what goes where or does in only do point-A to point-B
- How fast does it need to move, Is the path “protected” for its exclusive use, all the way or part way?
There are likely 100 other things to answer before you have pinned down what it is you want to build. I would also write out “use cases”. These are stories from a user’s point of view. Here is an “exotic” one: We store salvages items from building demolitions andmy job is to find items based on a description, box it and place the box on the truck. The robot will help by following me and then I give it a box, it places it in the truck then comes looking for me and follows until I give it another box. You need lots of these stories because later you test design proposals to see if the proposed design can “work” in the use cases.
Or you do the OTHER method, build something, and then find a use for it. Later pretend that you had this use in mind from the beginning.
Selecting and building hardware is a few steps away