Would RRF be suitable for an automatic storage machine?
-
I have a need to move small items and store them on racks. The mechanics would be comfortably within the range of a Cartesian 3 axis robot based on V-slot beams and carriages.
Although automatic storage and retrieval systems (ASRS) are common industrial items, it seems there are relatively few diy attempts published to any great level of completion, beyond basic proofs of concept (please share links if I'm wrong on this).
I am seeking opinion from those who are familiar with RRF and perhaps adapting it to original applications, whether you think RRF should be shortlisted in my consideration for a machine controller for my ASRS. As well as the main 3D kinematics, I envisage that the effector may need an RC servo to lock payloads in place and a few limit switches to detect if a payload is present or not. I envisage a small set of loading points, where items will be manually placed prior to automatic storage on the racks. The system will need to detect when these loading positions are occupied without using the effector, so I imagine an optical or inductive sensor will be needed on each one.
Are there any existing features which might be particularly useful? I'm thinking of tool change routines which could be adapted to place an item on its rack or pick it up again.
-
Although automatic storage and retrieval systems (ASRS) are common industrial items, it seems there are relatively few diy attempts published to any great level of completion, beyond basic proofs of concept (please share links if I'm wrong on this).
You are wrong on this. There are many PNP solutions out there, use the search feature to find many posts on this forum for RRF powered automats (don't thank me for the hint…).
I envisage that the effector may need an RC servo …
I envisage a small set of loading points …
I imagine an optical or inductive sensor…
Many envisages and imaginations, no real meat. Are you maybe tasked with a seminar paper or some similar exercise? Just to clarify: this is a forum for makers, not ghostwriters.
Take my good advice: Sit down and conceptualise all necessary building blocks - mechanics, sensors, actuators, controls, interface(s). Sure you can use a Duet to control a „Cartesian 3 axis robot“, but that’s only one part of the envisioned system. In a second step, develop a software model which controls the building blocks so they can interact in a meaningful way. Third: build the hardware, fourth: stitch together the software. Finally, commission the machine and have fun with moving around and storing all your small items. BTW: which kind of items are we talking about? I’m just curious …
-
@infiniteloop thank you for replying. I agree there are many similarities between a PnP machine and an ASRS. I had searched for the latter on the forum with no results. After widening to "PNP" (most results are related to inductive endstop sensors) and "pick and place" there are still few results. Most of them are about getting the configuration to the point where OpenPNP can interface with the controller board and "take over" from there, which doesn't give me much insight.
I have looked at Marlin as a potential machine control firmware as it is used for the Opulo LumenPnP machines, however, I understand the founders had a good relationship with the Marlin dev team early on in the project and were able to make the changes needed via their help. I do not have that advantage so am attracted to the flexibility of RRF.
I can provide the following meat that might stimulate further thoughts and discussion:
- I can assure you I am not involved in an academic exercise. I want a machine, I have experience of designing, building and upgrading my own 3D printers and have most of the skills needed to complete this project already. The higher level software control is where I am least experienced and will need to do most work. I am looking for an adaptable machine controller firmware so I can spend my effort developing higher level behaviour, rather than debugging the lower levels.
- I have been conceptualising all the various parts of this machine for a while and am investigating one aspect of it here on this forum. I did not want to waste my or your time with details which may not be needed for general comment on the suitability of RRF for an ASRS application. I am happy to provide more detail if it assists the conversation. I would be interested in hearing more about your recommended approach to the second step in developing a software model. Are there existing well-trodden approaches to custom machine software design, or is a particular language and set of software tools suggested? ROS has the Gazebo simulator - do you think that's the kind of thing needed or is there something else, or am I better off looking at generating GCODE from a particular generator, like fullcontrol or a python script?
- Where I see similarities between ASRS application and 3D printing - bed probing. The storage locations may not be perfectly spaced and even with guides to accommodate inaccurate positioning, I might prioritise a feature where the effector can measure and the system store the locations more accurately. Similarities between PNP and ASRS - Feeders are somewhat similar to the pick-up positions I'm planning, so I'm sure there's plenty to learn from PNP control software designs. There are clear differences, in that most CNC machine controls run a sequence of operations which are finite. ASRS would have to continually loop over checking the pick-up positions, moving parts to free storage locations and recording the occupancy status of each storage position.
- The items are cable assemblies which have their ends coated and the storage area is where they dry. They will be gripped by their cables and hang down, both in transit and while in storage. Longer cable assemblies may need their uncoated segments coiled to ensure the storage racks can be as close to the floor as possible. Because of the variation in cable diameter and length (possibly need to coil some) I plan to use an interface plate which the cables are clipped to but provides an easier effector interface than if the effector had to try and grasp the cables with a gripper. The plate will also simplify hanging in the storage/drying positions on the racks.
-
I can provide the following meat
Thank you for providing so much detail. That’s truly much meat for further discussions. So let’s start.
• The Duet controllers are great in that they provide an elaborate motion system, they should cover all aspects of picking up, moving and deposit the objects in 3-dimensional space. They also provide a lot of I/O, so that you can deal with analog and digital inputs - who then can trigger events (invoke sub-programs), which is useful to control actuators etc.
• Typically, RRF is controlled by a stream of commands, i.e. GCodes. They tell the Duet where to move or what other action to execute. IOW, RRF/Duet has no idea of the items to move or of the storage locations, you need an external instance which translates the idea of a storage system into GCodes. In 3D printing, that’s the slicer, for PnP machines, OpenPNP does the job.
• For ASRS, you have to develop your own system, which is quite easy in case of a FILO (first in, last out) or FIFO (first in, first out) type of serial storage. These trivial cases can be scripted and run on a Duet. If you need to store different types of cable assemblies in specific storage compartments and to retrieve them according to type or some other scheme, there’s no way but to use a RasPi or similar system.
• It may be difficult to maintain the state of the system (storage capacity of several slots) over time. After every reset, the Duet has to re-calibrate itself, count all items per storage location and init several counters. How many storage queues are we talking of?
• Some sensors involving image- or pattern recognition need an external controller (these belong to the subsystems I mentioned in my first post). An external controller (such as an Arduino) may also be required if you have to interface lots of simple sensors (mechanical or optical switches).
• Do you have a concept of necessary controls - buttons and the like? Except of the automatic pick-up, how will humans interact with the system? All this affects the required I/O capacities.
• You mention imperfect spacing and inaccurate positioning, I would add potential jams and other malfunctions. Depending on the required level of perfection, the subsystems (pick-up, storage queues, goods issue) can become deliberately complex. After specifying some numbers (queues, items/queue, approx. dimensions, timings), the subsystems must be defined in order to guess how many sensors of which kind are needed. With all these details, you can make an educated guess whether RRF/Duet can do the job, of whether it needs to be assisted by an external RasPi.
-
who then can trigger events (invoke sub-programs), which is useful to control actuators etc.
Excellent, this sounds useful to automate / iterate over checking for new items at the "goods in" buffer area. I could have four positions, each connected to a GPIO that would alert the control application if an item needed to be collected.
...I would add potential jams and other malfunctions.
Yes, as you suggest, this is an area which could have a broad range of complexity. I would hope that slotted optical beam-break switches, inductive probes and mechanical microswitches will be easily accommodated in the GPIO scheme, although I understand that I might need to multiplex them into an aggregator to reduce the number of controller board GPIOs they occupy. E.g. all the machine door microswitches could be aggregated onto one GPIO. I might also investigate the use of stallguard to detect moving parts collision.
I would certainly be happy with a FIFO system to start with. Two main operating modes will be "automatic storage" and "automatic retrieval". In "AS" mode, sense any item which has been placed in the "goods in" buffer area, which will be a set of storage positions identical to the storage rack positions but are accessible to the user, or another machine in future. Then move to an occupied "goods in" position, pick the "pallet" up (which will be the adapter plate I previously mentioned, where the cables are clipped and excess length stowed). Then move to the next vacant storage rack position and deposit the pallet, before returning to an idle position or collecting the next item in the "goods in" buffer. "AR" mode would check for vacant positions in the "goods in" buffer area and load items into them, in the same order in which the storage racks were filled.
trivial cases can be scripted and run on a Duet
I'm hopeful that what I describe above could fit this scenario. I think I can see the kind of script which would be adaptable to save storage position status (vacant/filled) to a file on the SD card. I don't think I will be doing sufficient numbers of movements to cause issues with SD card storage, but I will investigate alternatives.
Do you have a concept of necessary controls -
Estop! And then I would want a mode select, which could be a toggle switch on a GPIO, and a run/idle button, which could be a latching push switch or another toggle/rocker switch on GPIO. A basic display to give error status information, along with a momentary push button might be useful to clear errors after user investigation and attempt to follow the programme. I would use a PanelDue or the web interface if it became clear that these are easy to configure as a non-traditional HMI. Open to other suggestions.
So for my basic implementation, which would be a "minimum viable product" for our own use, I think RRF/Duet Duet 3 Mini 5+ might be able to do what I need.
Thanks for all your advice!
-
@SimonM Two thoughts from me:
- For easy I/O expansion, the Sammy-C21 is a great piece of kit, connecting to your mainboard via CAN-FD. Depending on your needs, this would likely need to go onto a custom PCB (with some pull-up/pull-down resistors on inputs/outputs, etc) https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Using_the_Sammy-C21_development_board_with_Duet_3
- The BtnCmd plugin for Duet Web Control is amazing for creating custom dashboards. Charts, buttons to toggle outputs, input monitoring, buttons to launch macros, etc - pretty much only limited by your imagination.
-
@SimonM Overall, the details you provide hint at an industrial application. If so, you will run into problems, mainly these ones:
• Concurrency. In this realm, Duet/RRF has rather sophisticated capabilities, but they can not really be controlled by the scripting language. In a simplified model, RRF maintains an execution queue (in fact, there are two) of certain commands. Some commands are executed out-of-order, and before you run a ”subroutine” (e.g. another script file), the queue must dry up. You have to take care that each new script waits for completion of the current one - which can slow down operations if each of the numerous triggers (optical or mechanical switches) invokes a lengthy script file on its own. Usually, you’ll need some kind of state machine to sync execution - with a scripted language, that’s a major task.
• Forget about storing the state of storage positions on the SD card. As each ”AS” and ”AR“ op would require at least one write access, the SD would wear out rapidly. As I’m familiar with the ways to store and retrieve data to and from files on the Duet, I can safely state that there is no simple way to evaluate a bunch of stored numbers on the fly. For instance, it is near to impossible to operate ”real-time“ on tables like the height map by a script. You can hold and maintain a limited amount of data in RAM, but these have to be inited every time on power-up, so plan for that.
• The PanelDue is not suited for use as a general-purpose UI, you would have to customise its firmware. DWC might be an option if you use a plug-in like BtnCmd, but I doubt it will fulfil the requirements for industrial use. Possibly, you can’t help but to couple the Duet with a RasPi and write some dedicated stuff for Linux. This way, you have a good instance where to implement a state machine (with permanent storage) as well.
-
@infiniteloop Yes, with those additional comments, it does seem like an external SBC for the higher level operation would make sense, thanks.
-
@sebkritikel sorry I missed your reply - thanks for your valuable suggestions!
