Hydraulic Pressure-Flow Rate Control of a Pallet Handling Robot for an Autonomous Freight Delivery Vehicle

: The current paper presents an upgrade of a pre-installed hydraulic system for the operation of a pallet handling robot for a freight delivery vehicle known as FURBOT (freight urban robotic vehicle) . The automated forklift installed on FURBOT for loading/unloading of cargo is powered with the help of hydraulics. The previous hydraulic system worked via a classical approach with a ﬁxed displacement pump and a bypass valve, making it work on full power when in use. An alternative design was proposed, simulated and installed on FURBOT; it uses a ﬁxed displacement pump and changes the rotation speed in real time using a pressure sensor. Novelty was attained with the use of gear pumps for said scenario. A control algorithm is implemented in the processing unit for controlling the speed of the motor driving the pump. The main advantage of this approach is better use of energy for the vehicle’s battery. The aim of this research is to control both the speed and maximum force exerted by the actuators with the help of a single sensor and an inexpensive pump.


Introduction
The idea behind the FURBOT (freight urban robotic vehicle) project was to propose a light-duty, efficient, sustainable and fully electrical freight vehicle for urban environments. The truck features a pallet handling robot and active suspension for loading/unloading operations. The main purpose of this vehicle is to deliver cargo, for which loading/unloading of cargo is of prime importance. The pallet handling robot installed in the truck not only requires automation, but also it is desired that it should be energy efficient. Furthermore, it should be optimized for performance and be safe for use.
The upgradation of FURBOT is being carried out presently, as the vehicle is required to perform at the H2020 Research and Innovation Programme, SHOW (SHared automation Operating models for Worldwide adoption). The vehicle is set to be fully functional and optimal in time to qualify for its pre-demo in October 2021 for SHOW. Apart from the work which is being carried out for its automation [1,2], the hardware upgradation of the vehicle is also very critical for its performance, especially the safe operation of its robotic forklift. Thus the need for this work was generated.
The vehicle has a control mode for loading/unloading of pallets defined as "Forkmode". The vehicle only handles the pallets when the vehicle is in this particular mode. The automated forklift of FURBOT operates with the help of hydraulics rather than electric drives. The selection of hydraulics over electric drives is due to two main reasons-one being that force density is required under limited space/mass, and secondly because other subsystems have similar requirements that hydraulics can serve. Additionally, hydraulics are economically more viable. Costs play a vital role in the design of FURBOT, as it is desired that the vehicle remains cost effective to keep it commercially attractive.
Another novelty in the work is the use of gear pumps instead of axial piston pumps. Gear pumps are always driven at constant nominal speed (at the speed of highest efficiency for the component; efficiency degrades at speed lower than nominal non-linearly, although not in a way compromising the use of the component), and it is a common practice to use axial piston pumps to generate variable flow rates. This issue is industry-driven, since diesel engines and electric motors usually operate at constant speed. However, an axial piston pump costs typically six to eight times what a gear pump does; it is also subject to more wear with standard filtered oil circuits, as one would expect to use in a small van like FURBOT (not sophisticated overall hydraulic components in the circuits); finally, gear pumps are on the market for use with water-glycol, but for the same fluid axial piston pumps are extremely expensive due to rare use. Hence the novelty and idea investigated was to mount a servomotor on the gear pump: the motor was designed to operate at variable speed and in dynamic conditions; and not be regulated the way it is done with an inverter on asynchronous motor, but controlled in time to promptly serve instantaneous fluid rate.
It was observed that very few publications are available on the optimization problem of the hydraulics of a forklift. Some researchers have focused their research on either vision of the forklift operator [3] or controller design for automated forklift operations [4][5][6]. The focus of optimizing the hydraulics of the system for a forklift is still unexplored. Most of the optimizations are either theoretical [7] or for dynamic modeling [8].
Displacement-controlled actuators and hydraulics are playing vital roles in the development of new and clean technologies for mobile robots [9]. Major challenges being faced in the development of hydraulic systems for such robots are efficiency improvements, noise reduction and advancements in pump technology [9]. The innovative techniques used in this article mainly comprise on/off valves and fixed displacement pumps. The advantages of using fixed displacement pumps over variable displacement pumps are that they are typically smaller, lighter and cheaper than their counterparts [10]. The efficacy of on/off valves is well established [11], and for this reason, such valves are used in our work for development of an energy efficient hydraulic system with a lower cost at the same performance level.
New approaches to solving the intricacies of valve operation and fixed displacement pumps are being studied continuously, and mathematically modeled in order to better simulate their results [12]. The biggest drawback of these displacement pumps is the energy loss which is associated with them. However, these losses can be significantly reduced in the presence of load/pressure sensors [13]. The application of hydraulic systems in itself is a very demanding task. Many researchers have published their results just on the application [14], as a simple condition such as cold weather has the potential to decrease the overall efficiency of the hydraulics system [15]. The discussed articles bring good validity in the proposed work.
Another recent work used the same approach for flow control [16] but they used it specifically for electric drives. Within [16], the process for simulating the controller was similar and MATLAB/Simulink was used for simulation purposes. Additionally, the technique for hardware validation was also similar to our work. Furthermore, in another study, direct driven hydraulics were used to reduce the power consumption of the system [17], which is especially useful for heavy vehicles. This is very helpful in our vehicle as reducing power consumption is one of the goals of our research. Upgrading the energy management for forklifts has also been studied and verified in experimental settings [18]. Our research also uses the same experimental validation technique for our forklift operations to verify our simulation results.
Pressure flow rate control is an essential and emerging necessity. New devices are constantly being patented to safeguard the intellectual property [19,20]. Further work is also being done to save energy by using mutual pressure and flow control [21] and optimization pressure control valve for automatic transmission [22]. In reference to our work, we also tried to optimize our hydraulic system by using an inexpensive displacement pump and pressure sensor. Using a variable displacement pump was never viable for our research as cost effectiveness plays a vital role in the overall design of our robotic forklift.
This study was unique because an already installed hydraulic system was upgraded for better performance through control modifications and new hardware installation. The work completed not only upgraded the hydraulic system of FURBOT, but also produced a safer environment for working. The whole problem was simulated in LMS and SimuLink before implementation. Additionally, the work produced has practical applications in forklift design and is considered vital in the performance of FURBOT. To summarize, the contributions of this research are given below.
1. It is not common practice to use hydraulics in robotic systems. We have taken a new approach by using hydraulics instead of electric drives for our robotic forklift. 2. Furthermore, the axes need force density and very modest precision: An electric motor and gears also give additional precision not needed for our tasks. Additionally, the electric motor and gear pump can have a rigid transmission, and this too is a feature not required for FURBOT application: for this reason, hydraulics are not used much in robots because robots are designed for tasks needing accuracy and made stiff to simplify the control (controlling flexible axes is more complex in trajectory and under variable loads). 3. Validation of our methodology was achieved by conducting separate tests for speed control, the pressure loop, the speed test and the bi-state regulator. Moreover, repetitive experiments were performed to increase the faith in the robustness of our system. 4. The classical approach to regulate speed/force is through pressure reducing valves while the pump turns at full speed; this means it is not possible to set both the maximum force that will be exerted and the speed during the motion. With the help of bi-state regulator, we are able to set both the maximum force exerted and speed during motion. 5. A lot of energy is wasted using pressure reducing valves. The technique proposed is not only safer, but also reduces the energy loss in the system.

Hydraulics on FURBOT
FURBOT is equipped with a complete hydraulic circuit for handling of freight through the forklift, for suspensions and for the hydraulic braking. The complete schematics of the installed hydraulics on FURBOT are shown in Figure 1. The architecture of the hydraulic supply of FURBOT is also given in Figure 2. For each forklift axis, a double acting cylinder is used and controlled by a 4/3 mono-stable distributor, as shown in Figure 3. The suspension uses the same structure, but also includes nitrogen tanks, which can be linked to the cylinder chamber when driving, as shown in Figure 4.
The tank supplies the circuit with fluid and allows heat dissipation. The hydraulic pump is a fixed displacement pump, making the flow rate responsible for regulating the speed of the motor driving it. The bypass valve enables the operator to temporary disable the feed circuit without stopping the pump. With the current design, the pump is running at full speed when the operator enters the "FORK mode" needed to enable the hydraulics to operate the forklifts. Without actuation and negligible oil compressibility, a sharp increase in pressure is observed. Without any kind of regulation, this phenomenon has the capacity to waste energy because the excess of fluid goes back to tank through the pressure relief valve. The pressure valve is required to bypass the circuit to the tank when the pressure exceeds 140 bars. Another pressure regulator generates a lower pressure stream of oil for the suspensions (30 bars).

Synoptic View of Control Architecture
A synchronous brush-less motor drives the pump. The motor is controlled by a servo-controller and makes the set controller + motor a servomotor, as shown in Figure 5. The controller generates the three-phase currents for the motor, and regulates the current (thus the torque) and the speed. This is a current servo-drive where the minor current loop is embedded into the speed loop. The servo-controller is connected via a digital communication link to a custom controller board and implemented on a Linux computer featuring a PowerPC processor, RAM, an FPGA for GPIOS control, an Ethernet layer (MAC and PHY) and onboard CAN transceivers. The controller board, called the open motion controller, elaborates the control of all the low-level devices on the FURBOT via CAN buses and a CANOpen layer: these include hydraulic motor via a drive manufactured by SEVCON, the traction drives, the steering drive, the signaling of the vehicle and other devices via a CAN-to inputs outputs board (DIO).
The current design is sub-optimal from an energetic point of view and has safety issues, especially regarding the fork's actuation, yet this is a classical architecture. Reasons for this design being sub-optimal are: 1. The pump is always running at full speed and the pressure regulators are used uneconomically.
Given the oil compressibility, the rise in pressure is quasi-instantaneous; in other words the pump can start when actuation is needed without wasting energy for the majority of the operation time when in fork mode and waiting for actuation.
2. The forklift's cylinders do not always need 120 bars of pressure to work properly; so the maximum flow rate is not always required. 3. There is no safety regarding the speed of the unloaded cylinders as it is not controlled while working at maximum capacity. However, when the pressure is regulated, lamination valves allow regulating the speed of actuation by limiting the flow rate. Additionally, if the cylinders are stuck, the hydraulic pressure rises to 120 bars of pressure. Thus, it is better to set a maximum pressure set point in order to set the maximum force exercised by the cylinders. The pressure set point will give the maximum force and the lamination valve the maximum speed in steady state.

Research Objectives
The objective was to regulate the pressure of the oil before the fork actuators. The pressure regulating valves are able to regulate the pressure of the oil; however, the problems are: They are designed for a simple service and dissipate energy by bypassing a certain amount of oil into the main tank. One can set the pressure manually but cannot control or regulate it over time.
Hence the idea of regulating the pressure by controlling the flow rate of the pump was formulated (the amount of oil fed into the system in a time period, while compensating for the leaks and changing the pressure according to compressibility formulas). Usually, a variable displacement pump is used for such an application. When it comes to "load sensing" in hydraulics, the flow rate of a variable displacement pump is modified (without changing the rotation speed). In load sensing with variable displacement axial piston pumps, the flow rate is adapted in the time to have no flow through the pressure relief valve, which is there just for safety. Additionally, the cost target of the vehicle does not let us use the normal variable displacement architecture because it is too expensive. Additionally their proneness to failure with fluids different from oil is also an issue, since we desire to shift to water additives with ethylene or propylene glycol in the future.
The idea was to use a constant displacement pump and to change the rotation speed in real time. The flow rate is actually proportional to the rotational velocity of the pump. This required measuring the pressure with a new dedicated sensor, implementing an algorithm in the processing unit (the OpenMCP) and controlling the speed of the motor driving the pump.

Hydraulic Equations and Control Strategy
We define the bulk modulus in hydraulics β [23] as where p is the pressure in the line and ρ is the volumetric mass density of the fluid. Considering that rate of change of density is directly proportional to the rate of change of mass flow rate of the fluid Since rate of change of volume is not constant, especially when the actuators are in motion, our equation becomes 1 Since where "M" and "t" define "mass" and "time" respectively, we get It is desired that we control the output pressure with the input q despite the unknown variations in V. Thus, the "expansion of the walls" then appears as a perturbation term. Curve fitting on volume around a value is non-realistic as V changes a lot in a non-deterministic way.
Let us assume that σ = p cons − p. With the Lyapunov candidate function V = 1/2σ 2 we want: V =σσ < 0 to achieve control whatever the perturbation may be (change of V).
It is possible to take the following first order sliding-mode control for q : q = ρKsign(p cons − p) ≈ ρK σ |σ|+ , where σ = p cons − p and K is the upper bound for | dV dt | and achieve regulation. This is interesting conceptually but of little use for the real life system because such a command law is basically a high-gain, high-frequency control. Since flow rate is controlled by changing the speed of the volumetric pump, we have the following nested loops: current in the motor → speed o f the sha f t → pressure. Sliding mode is well suited for systems that have a low-pass behavior and can be driven at high frequency. Here, the bandwidth of the inner loops, the logic limitations in the electric controller and the delays with the communication link prevent us from having high frequency switching which will result in instabilities: the electric drive cannot cope with the speed changing too quickly. The current loops operating in FURBOT run at 16 kHz, the speed loop runs at 200 Hz and the minimum delay between two consecutive set-points for the speed is 20 ms (50 Hz). Thus the pressure loop can run at a frequency between 200/10 = 20 Hz and 200/5 = 40 Hz < 50. It is required that the outer loop control be as continuous and smooth as possible.
Note that the pressure control mode will be enabled when the actuator is not moving or there is a high load on it, which will result in slow motion under pressure limitation. For a non-time-varying volume, a proportional controller is enough. If an integral term is introduced, it can easily match a small enoughV with a short amount of time, especially if a high integrator gain is used in conjunction with a good anti-windup (to avoid instabilities with steps in pressure).

The Control Strategy
The objective was to be able to set a maximum working force and a nominal speed for each hydraulic axis on the FURBOT. Since it is not possible to control the speed while limiting the force with a single volumetric pump at the same instance, a control mode strategy was devised which switches the control mode according to a defined logic. It works according to the following algorithm ( Figure 6) where the controller is aware of The speed of the pump: through intelligent servo-controller. The hydraulic pressure: through the installed pressure sensor. This is basically a bi-state machine ensuring smooth actuator operation while limiting the power of the cylinders and thus limiting the speed of the fork operation. Pmax is directly proportional to the maximum operating force and Qcons is in keeping with the nominal speed of the actuator (the factor is the cylinder area S).
The operation is the following: most of the time, the actuator is driven with constant flow. If for a reason something is preventing it from moving or the cylinder reaches an end-position, the pressure will raise. For safe operation and to avoid using the pressure limiting valve, the pressure is regulated to Pmax once it goes over Pmax. Once the load is removed or the actuation is done in reverse (pulling instead of pushing), the flow rises until it eventually goes over Qcons, which is the nominal flow rate. Then the controller switches to flow regulation again.

Algorithm
The whole build system of the OpenMCP, which involves the kernel and the filesystem, the cross-compiler, configuration bash scripts and makefiles was cloned using LINEAR mercurial repository. Within the folders and files, there is the furbot application folder with all the source files (.hpp and .cpp), object dictionary description files (.ods) and the latest binary executable. The architecture of the code is the following: The libcanopen++ API is used to create new can buses handlers and CANOpen "master controllers" which can be linked to a bus. A "master controller" is a CANOpen master node with a specific master object dictionary and which can run several "application controllers" with the use of threads. The software's "application controllers" are linked to a specific hardware-device on the bus. They work with the use of threads and callbacks from the libcanopen++ stack and have an internal state machine to operate the vehicle safely. A FURBOT class wraps all the buses and controllers. The latter also includes a network handler to broadcast information via UDP (User Datagram Protocol) to all hosts on the local network. All the objects are instantiated and the threads launch with the call to the Furbot() constructor inside the main function.
Changes to the existing architecture included: Changing the object dictionary for one of the master nodes on the bus. New user entries were added for the pressure process-values coming from the pressure sensor and we did the right PDO (Process Data Object) mapping. Writing a controller for the pressure sensor (two new files), to get the data and to send it to the local network inside UDP packets. A network subsystem for the pressure sensor was added using pre-existing functions.
Creating a class for the algorithm (two new files) to be able to get the behavior explained above. The pressure control mode is a PID control while the flow regulation just consists of setting the speed of the pump. Changing some functions into the furbot class, especially the function starting the pump and running it at full speed by a new function according to the current requirements.

The Open Motion Controller and CAN
The vehicle uses several CAN buses to control the different modules and drives. The algorithm is implemented on the motion controller; the latter runs under a Linux operating system and the "furbot" application runs in the background.

The OpenMCP
It is the main motion controller of the vehicle. The hardware of the OpenMCP is shown in Figure 7. Ethernet links it to all the devices by CAN buses and to the human-machine interface on a local network. Physically, it is composed of two boards: a digital processing board stacked upon a digital interface and a signal handling board that includes network transceivers (CAN and Ethernet), protection components (opto-isolators, fuses and transient voltage suppressors) and an IO interface. On the computing board, there is a PowerPC processor, flash memory, RAM and an Altera FPGA for network layer implementations and some IO logic. Two automotive AMPSEAL connectors are used to physically wire the board inside the vehicle.
The "furbot" application is cross compiled and loaded as part of a Unix file system. A Linux kernel and the file system are loaded in the flash by a separate tool. When the device boots, it decompresses the kernel and the file system (SquashFS) on the RAM. The board allows for two kernels and two file systems being available on the flash memory. It automatically loads the latest ones but allows using the old revision if a problem is detected. Particularly if the boot fails with one kernel, it automatically tries the older one after a few attempts. An executable, added to the path, enables one to load a newer revision of the kernel or the file system via the network and the protocols SSH/SCP.

CAN
The CAN (controller area network) is an automotive fieldbus designed to be very reliable in harsh environments and is an asynchronous multi-master serial bus. The physical layer uses a differential signaling scheme on copper with a 120 Ohms termination resistor to avoid signal reflections at the end of the lines. In the most common implementation, all the nodes share the same link (bus). A complex arbitration process based on a message priority system and several kinds of frames allow only one node to talk at time. Acknowledgment of the messages enables it to detect errors and faults. There are four frame types: The data frame transports the data. The remote frame asks for the transmission of a data frame. The error frame is broadcast by one node which detects an error. The overload frame is broadcast by a node which detects an overload.
All the transceivers have their own clock, but these are re-synchronized on a frame reception using the signal logic transitions: for that purpose, the bit stuffing ensures that there are always enough transitions to synchronize the nodes.

CANOpen
Getting the CAN messages from the hardware to a computer requires an adapter (made in silicon with the OpenMCP) and a driver on the computer. An IXXAT "USB to CAN" adapter was used for the early experiments with Linux machine and the drivers from IXXAT. Hardware is shown in Figure 8. On UNIX, several tools are useful for talking to the bus, such as the can-utils tools. Other than that, the SocketCAN stack enable the user to use a network interface to talk to the CAN bus. The tools involved are candump and cansend to filter/see the received messages or send a message on the bus. The application talks with the SocketCan stack via a library. CANFestival CANOpen library is used to interface an application code with the bus working with CANOpen. CANOpen master node was written, with its own object dictionary generated from a python utility given with the CANFestival library, and was able to control the motor in speed regulation and position regulation.

Preliminary Work on the Pressure Sensor
The pressure sensor operates from 1 to 160 bars in absolute pressure and operates according to the CANOpen ds404 profile. The pressure sensor was mounted on the hydraulic circuit of the FURBOT and was first directly wired to the personal computer using IXXAT. It was then configured using the cansend tool for Linux and the LSS protocol. CANOpenShell utility provided with the CANFestival libraries was used to take feedback from the sensor, set the state with NMT and get the data via SDO/PDO messages. All the electronic hardware was mounted on the back of the vehicle as shown in Figure 9. A python script was written to get the pressure plot in real time. This ensured that the pressure sensor was working properly.

Simulation Modeling
The model falls into three parts: the corrector, the electric drive and the hydraulic circuit. The whole SimuLink model is shown in Figure 10. One of the objectives was to check whether the PI controller proposed above could regulate the pressure with a certain class of system composed of an electric drive and a constant displacement hydraulic pump, without the need for a full mathematical model of the Furbot subsystems. The main output is the pressure of the pump, and the inputs are the set point for the pressure and a pulse generator to command the cylinder in the hydraulic circuit. From the pressure set point, the controller generates a speed set point for the pump that is reached by the drive. The final controller is a PID with anti-windup integrator clamping.

Simulation Results
The control scheme proved successful as long as the speed of the cylinder was limited with a flow limiter and there was enough oil behind the pump. Indeed, if there was no flow limiter, the piston moved too fast, and the circuit could not cope with the corresponding dV/dt. Theoretically, if there is not enough oil, instabilities (oscillations) may happen. A tank with a fixed volume of oil behind the pump can have a damping action. In the real system, we also want to get rid of the flow limiter, but most of the time it will be controlled in constant flow (constant actuator speed) mode, and if it switches to pressure limiting mode it means that a counter action is preventing the piston from moving too fast.
It was observed that there was drop in pressure when the motion of the actuator changed. Nevertheless, the integral term helped the controller to recover regulation around the set point, i.e., 30 bars. The following figure shows the details of the pressure rise at the beginning. A delay was observed between commanded and current speed for the pump. Modeling and the simulation proved that the controller could possibly work in theory. Figure 11 shows the simulation results, whereas a zoomed view of pressure rise is shown in Figure 12.

Pressure Sensor Test and Results for the Pressure Loop
The pump was driven at constant speed to verify the results. The plots below are from the python script with which the data were superposed to see "moving curves" in real time. The time basis was 20 ms between samples, and there was a 255 sample-buffer. Figures 13 and 14 are results of the pump driven at constant speed (rpm). The results obtained reveal the hardware's performance at a constant speed, enabling one to judge the robustness of the controller.
Blue represents pressure. Red represents set speed from the control loop. Green represents actual speed. Yellow represents torque from the motor, measured from the servomotor.  Furthermore, the hardware performance was also validated by running the pump at constant pressure ( Figure 15). These three experiments (Figures 13-15) were performed to validate the hardware and highlight any inherent delays in the pump before validating the controller. With the understanding of these results, we are able to validate better the robustness of bi-state controller.  While performing the speed test ( Figure 18), a jitter was observed at low rpm. It appears that the jitter near the setpoint was due to bad encoder settings for the servomotor: the latter used the UVW phase signals for the synchronous motor instead of the signal from the encoder to get the positions. Thus, there were less coding points (ticks), which is detrimental to speed control for low speeds. Apart from the jitters at low speeds for the reason mentioned above, the controller performance in the speed test (Figure 18) was well within the acceptable range when keeping in mind the inherent lags of the system.  It was thus observed that at low speed, the pump was uncontrollable. This was because the efficiency of the pump was very low at low speeds. The gear pump had an interval of regulation and for lower speeds the internal leaks made it difficult to control, since flow sometimes leaked at low speed. This particular problem was not resolved even after installing a small tank of 0.35 L to damp the system and avoid oscillations. During the acquisition, the bypass valve was closed and then was opened; still, the pump was not able to cope with increasing pressure without creating huge torque, making the pump inefficient.

Final Algorithm Test
The results of pressure control were again collected with the inefficient pump at low pressure, as shown in Figure 19. From Figure 19, one can observe that the actual speed does not follow the set speed, hence the pressure ripple. For the results of the bi-state regulator (Figure 20), a horizontal piston of the forklift system was actuated (which was responsible for its horizontal movement), and we set the nominal speed to 300 rpm, and the maximal pressure to 25 bars. The flow limiter was completely open for that cylinder.  To validate the results of the bi-state regulator and to check its performance, another experiment was performed (Figure 21) with the same conditions. The results of both experiments (Figures 20 and 21) show consistency in the performance enhancing robustness of our bi-state regulator. Furthermore, the results validate our bi-state controller and its performance; actual speed (green) followed the set speed (red) in both of the experiments.
In spite of the presence of ripples in the pressure control mode, it was observed that the piston moved slowly till it reached an end-position and became pressure controlled. An effort was made to block the piston and limit the pressure. The piston was blocked with a chain, which moved slowly with the load release. Additionally, the speed was limited without the flow limiter, which was wasting energy; and the hydraulic pressure regulator was not used. The motor with a properly functioning pump should be low in pressure regulation mode. It is nevertheless possible to activate the pump when an actuator needs to move and to stop it on another condition, i.e., low speed of the pump or timer (tri-state machine).

Conclusions
The overall hydraulic system of FURBOT was upgraded and optimized in terms of energy and safety. An innovative controller was implemented for pressure regulation and flow regulation which enhanced the overall performance of the installed forklift on FURBOT. The whole operation was conceived conceptually and simulated in Simulink before actual implementation. Perfect actuation of the forklift was not achieved due to hardware limitations, but the whole concept was electronically and physically implemented. Additional work is required to achieve better results and remove the remaining issues in the development of actuation system of the forklift. Nevertheless, the achieved results are very promising and of practical use. These results are very attractive in the automation process of project FURBOT.
Furthermore, we have shown that we were able to move the cylinder pump at constant speed through constant flow rate while controlling the maximum force exerted at all times. This was achieved with a single constant flow rate pump and a pressure sensor ending power wastage with pressure reducers. Additionally, at end positions, switching to pressure regulations eliminated the need for limit switches. The drawback of this scheme is that it is not easily scalable to multiple and simultaneous actuators control. This is because the flow of the constant flow pump will be divided through all actuators and the force exerted depends on the section of the cylinder pump; thus, a single pressure setpoint will not be enough.

Conflicts of Interest:
The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Abbreviations
The following abbreviations are used in this manuscript: FURBOT Freight Urban Robotic Vehicle SHOW SHared automation Operating models for Worldwide adoption