The present invention generally relates to the field of a storage or fulfilment system in which stacks of bins or containers are arranged within a grid framework structure, and more specifically, to determine a kinematic state of a load handling device in the storage system.
Online retail businesses selling multiple product lines, such as online grocers and supermarkets, require systems that can store tens or hundreds of thousands of different product lines. The use of single-product stacks in such cases can be impractical since a vast floor area would be required to accommodate all of the stacks required. Furthermore, it can be desirable to store small quantities of some items, such as perishables or infrequently ordered goods, making single-product stacks an inefficient solution.
International patent application WO 98/049075A (Autostore), the contents of which are incorporated herein by reference, describes a system in which multi-product stacks of containers are arranged within a frame structure.
PCT Publication No. WO2015/185628A (Ocado) describes a further known storage and fulfilment system in which stacks of containers are arranged within a grid framework structure. The containers are accessed by one or more load handling devices, otherwise known as “bots”, operative on tracks located on the top of the grid framework structure. A system of this type is illustrated schematically in
As shown in
The grid framework structure 14 comprises a plurality of upright members 16 that support horizontal members 18, 20. A first set of parallel horizontal grid members 18 is arranged perpendicularly to a second set of parallel horizontal members 20 in a grid pattern to form a horizontal grid structure 15 supported by the upright members 16. The members 16, 18, 20 are typically manufactured from metal. The bins 10 are stacked between the members 16, 18, 20 of the grid framework structure 14, so that the grid framework structure 14 guards against horizontal movement of the stacks 12 of bins 10 and guides the vertical movement of the bins 10.
The top level of the grid framework structure 14 comprises a grid or grid structure 15, including rails 22 arranged in a grid pattern across the top of the stacks 12. Referring to
A known form of load handling device 30—shown in
The load handling device 30 comprises a vehicle 32, which is arranged to travel on the rails 22 of the frame structure 14. A first set of wheels 34, consisting of a pair of wheels 34 on the front of the vehicle 32 and a pair of wheels 34 on the back of the vehicle 32, is arranged to engage with two adjacent rails of the first set 22a of rails 22. Similarly, a second set of wheels 36, consisting of a pair of wheels 36 on each side of the vehicle 32, is arranged to engage with two adjacent rails of the second set 22b of rails 22. Each set of wheels 34, 36 can be lifted and lowered so that either the first set of wheels 34 or the second set of wheels 36 is engaged with the respective set of rails 22a, 22b at any one time. For example, when the first set of wheels 34 is engaged with the first set of rails 22a and the second set of wheels 36 is lifted clear from the rails 22, the first set of wheels 34 can be driven, by way of a drive mechanism (not shown) housed in the vehicle 32, to move the load handling device 30 in the X-direction. To achieve movement in the Y-direction, the first set of wheels 34 is lifted clear of the rails 22, and the second set of wheels 36 is lowered into engagement with the second set 22b of rails 22. The drive mechanism can then be used to drive the second set of wheels 36 to move the load handling device 30 in the Y direction.
The load handling device 30 is equipped with a lifting device, e.g. a crane mechanism, to lift a storage container from above. The lifting device comprises a winch tether or cable 38 wound on a spool or reel (not shown) and a gripper device 39. The lifting device shown in
To remove a bin 10 from the top of a stack 12, the load handling device 30 is first moved in the X- and Y-directions to position the gripper device 39 above the stack 12. The gripper device 39 is then lowered vertically in the Z-direction to engage with the bin 10 on the top of the stack 12, as shown in
As shown in
Each load handling device 30 can lift and move one bin 10 at a time. The load handling device 30 has a container-receiving cavity or recess 40, in its lower part. The recess 40 is sized to accommodate the container 10 when lifted by the lifting mechanism, as shown in
If it is necessary to retrieve a bin 10b (“target bin”) that is not located on the top of a stack 12, then the overlying bins 10a (“non-target bins”) must first be moved to allow access to the target bin 10b. This is achieved by an operation referred to hereafter as “digging”. Referring to
Each of the provided load handling devices 30 is remotely operable under the control of a central computer. Each individual bin 10 in the system is also tracked so that the appropriate bins 10 can be retrieved, transported and replaced as necessary. For example, during a digging operation, each non-target bin location is logged so that the non-target bin 10a can be tracked.
Wireless communications and networks may be used to provide the communication infrastructure from the master controller, e.g. via one or more base stations, to one or more load handling devices operative on the grid structure. In response to receiving instructions from the master controller, a controller in the load handling device is configured to control various driving mechanisms to control the movement of the load handling device. For example, the load handling device may be instructed to retrieve a container from a target storage column at a particular location on the grid structure. The instruction can include various movements in the X-Y plane of the grid structure 15. As previously described, once at the target storage column, the lifting mechanism can be operated to grip and lift the storage container 10. Once the container 10 is accommodated in the container-receiving space 40 of the load handling device 30, it is subsequently transported to another location on the grid structure 15, e.g. a “drop-off port”. At the drop-off port, the container 10 is lowered to a suitable pick station to allow retrieval of any item in the storage container. Movement of the load handling devices 30 on the grid structure 15 can also involve the load handling devices 30 being instructed to move to a charging station, usually located at the periphery of the grid structure 15.
To manoeuvre the load handling devices 30 on the grid structure 15, each of the load handling devices 30 is equipped with motors for driving the wheels 34, 36. The wheels 34, 36 may be driven via one or more belts connected to the wheels or driven individually by a motor integrated into the wheels. For a single-cell load handling device (where the footprint of the load handling device 30 occupies a single grid cell 17), and the motors for driving the wheels can be integrated into the wheels due to the limited availability of space within the vehicle body. For example, the wheels of a single-cell load handling device are driven by respective hub motors. Each hub motor comprises an outer rotor with a plurality of permanent magnets arranged to rotate about a wheel hub comprising coils forming an inner stator.
The system described with reference to
It is, however, an object of the present disclosure to provide methods and systems for reliably determining the correct location of a load handling device operated remotely in a storage system.
There is provided a method of determining a kinematic state of a load handling device in a storage system, the method comprising:
Also provided is a data processing apparatus comprising a processor configured to perform the method. Also provided is a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method. Similarly, a computer-readable storage medium is provided which comprises instructions that, when executed by a computer, cause the computer to carry out the method.
Further provided is a positioning system for a load handling device in a storage system, the positioning system comprising:
Also provided is a load handling device in a storage system, the load handling device being arranged to selectively move in at least one of the X and/or Y directions on tracks and to handle a container, the load handling device comprising:
In general terms, this description introduces systems and methods to estimate the relative position of a bot on a grid-type storage system by leveraging the encoder counts already available in the tractive wheel mechanisms, and optionally also the activations of grid sensors positioned on the grid.
Embodiments will now be described by way of example only with reference to the accompanying drawings, in which like reference numbers designate the same or corresponding parts, and in which:
In storage systems of the type shown in
As shown in
In the known embodiment of
Using the one or more position sensors 98a, 98b to independently monitor the position of the load handling device has some disadvantages. For example, there is an inherent component cost, which is compounded by the failure of at least one of the sensors 98a, 98b causing loss of the kinematic reference for the load handling device in at least one direction on the grid structure 15. There can also be issues with the accuracy of the measurements from the sensors 98a, 98b, e.g. caused by disturbances or imperfections in the tracks 22.
The vehicle body 132 comprises an upper part and a lower part. The lower part comprises a wheel assembly comprising two sets of wheels 134, 136 that run on the grid framework 115 structure of such a storage system. For explanation, the two sets of wheels are distinguished as a first set of wheels 134 and a second set of wheels 136. The first 134 and second 136 sets of wheels are arranged around the periphery of the load handling device 130. The wheels in this example are arranged outside the vehicle body 132, but in other examples may be housed within the vehicle body 132. Whilst the particular example drawn in
In the example of
The upper part of the vehicle body 132 may house most of the bulky components of the load handling device 130 shown in
The load handling device 130 in the present example shown in
To change between the orthogonal directions on the grid structure 115, at least one of the wheelsets is configured to move vertically to change which of the X-direction and Y-direction wheelsets are engaged with the tracks. For example, the X-direction wheelsets are fixed and the Y-direction wheelsets are configured to either lift up to bring the X-direction wheelsets into contact with the track or to drop down to lift the X-direction wheelsets off the track. Alternatively, the Y-direction wheelsets are fixed and the X-direction wheelsets move up and down to change which wheelsets engage with the tracks.
In some examples, each of the first 134 and second 136 sets of wheels mounted on the vehicle body 132 is arranged to move vertically to lift clear of their respective tracks or rails. For example, to change direction on the grid structure 115 (e.g. to the X-direction), the first set of wheels 134 are lifted clear of the first set of grid members or tracks 122a, and the second sets of wheels 136 are engaged with the second set of grid members or tracks 122b. A driving mechanism (not shown) such as a motor drives either the first 134 or the second 136 set of wheels in the X-direction or the Y-direction on the grid structure 115. In the particular example of
In more detail, the hub motor 160 shown in
Other types of hub motor are usable as the hub motor 160 for the wheels 150, such as an inner-rotor motor or an axial-flux motor. The inner-rotor motor has the stator winding on its outer shell, and the rotor sits inside the stator and connects to the shaft. Spokes typically connect the wheel to the rotor shaft. Inner-rotation motors typically have a small magnet volume but a larger volume of copper stator windings than outer-rotation motors. An axial-flux motor, in contrast, has the stator windings typically sandwiched between sets of magnets in a non-radial arrangement: the gap between the rotor and stator, and therefore the direction of magnetic flux between the two, is aligned parallel with the axis of rotation, rather than radially. Whilst the drive mechanism of each of the wheels 150 in the preceding examples comprises a hub motor, other means to drive the wheels are applicable in other examples. For example, a pair of wheels at the front and back on either side of the load handling device could be driven by one or more motors connected to a suitable pulley or gear mechanism. In other examples, the drive mechanism for the wheels 150 comprises a belt drive mechanism.
In the block diagram of the wheel assembly shown in
The controller 170 sends control instructions to the drive mechanism, which translates the control instructions into suitable driving output signals to the wheel motors, facilitating the controlled movement of the load handling device 130 on the tracks 122a, 122b of the grid structure 115. The control signals can be provided directly to the wheel motors or to an intermediate motor drive that controls the speed and direction of the wheel motors by varying the power delivered to the wheel motors.
When the controller 170 determines that the drive mechanism is to move the load handling device 130 from its current position to a new position or to alter its velocity, the controller 170 generates a trajectory (otherwise known as a “motion control profile”) which is translated by the drive mechanism into suitable control signals. The new position may be a target position or commanded stop position, for example. The motion control profile defines the kinematic state of the load handling device 130, such as its velocity, acceleration, jerk and/or position over time as the load handling device 130 moves from its current state to the target position. The jerk (or “jolt”) is the rate at which the load handling device's acceleration changes with respect to time, i.e. the first time derivative of the acceleration. The current position could be from a standstill or rest on the grid structure 115, in which case both the initial velocity and acceleration of the load handling device 130 is substantially zero. Alternatively, the load handling device 130 may be in motion at the current position, in which case the load handling device 130 has an initial velocity greater than zero.
In examples, the target position is a desired storage location or grid cell on the grid structure 115, e.g. for retrieving or depositing a storage container. In other examples, the target position is a position or grid cell on the grid structure 115 near a charging point, e.g., when the load handling device 130 is instructed to recharge the rechargeable power source. Typically, such charging points are located around the periphery of the grid structure 115.
Once a motion control profile is generated, the controller translates the motion control profile into appropriate control signals for moving the load handling device through the trajectory defined by the motion control profile. Multiple segments (or “stages”) of a motion control profile may be calculated, e.g. based on one or more predetermined constraints. Such constraints may correspond to the mechanical limitations of the drive mechanism, for example. The one or more predetermined constraints include, but are not limited to, a maximum velocity, a maximum acceleration, and a maximum deceleration. For example, the load handling device 130 is expected to travel at speeds up to four metres per second (m/s) and accelerate at two metres per second squared (m/s2). Given these constraints and the commanded target position, the controller calculates the motion control profile to carry out the desired move. The desired move may include a plurality of positions in the X- and Y-directions on the grid structure 115, e.g. blended or sequentially executed, in order for the load handling device to reach the target location, e.g. corresponding to the desired storage column. Each of the plurality of positions comprises a single move in either the X-direction or Y-direction on the grid structure, for example. For the present description, the terms “commanded velocity” and “velocity constraint” are used interchangeably, as are the terms “commanded acceleration” and “acceleration constraint”.
So-called “point-to-point” movement in the present description refers to movement from a start position to a target position. The final acceleration and velocity are taken to be zero when the load handling device arrives at a programmed destination or the target position.
In examples, inputs to the controller 170 are received via a master controller 174. The controller may be communicatively linked to the master controller 174 over a network 176 as shown in
The motion control profile is generated or calculated (e.g. automatically by the controller), e.g. based on the received one or more constraints and commanded position corresponding to the desired position on the grid structure. In examples, the motion control profile (or “trajectory”) includes a collection of position, speed, acceleration, and/or jerk signals. The trajectory is terminated (or reaches its endpoint) when the commanded position is attained and the remaining signals (speed, acceleration, jerk) are zero, for example.
As discussed above, the motion control profile defines the trajectory of a point-to-point move of the load handling device 130 relative to the grid structure 115 over a time period, e.g. in terms of one or more of: a position reference, a velocity reference, an acceleration reference, and a jerk reference. These references represent functional calculations by the trajectory generator defining how respective motion attributes of the drive mechanism will be controlled as a function of time for a given point-to-point move. The references are mathematically related to one another as derivatives with respect to time. Translation of the motion control profile into control signals, which instruct the load handling device 130 to perform the desired point-to-point move in accordance with the motion control profile, involves the position controller 184 generating a feed-forward signal from the motion control profile, e.g. based on the acceleration reference derived from the motion control profile. The one or more of the position reference, velocity reference, acceleration reference, and jerk reference may be referred to as an odometry reference or kinematic reference representative of the point-to-point move of the load handling device 30 over a given time period.
The feed-forward signal 210 can be translated into appropriate signals to drive the wheels of the wheel assembly. However, in order to ensure that the point-to-point move of the load handling device on the grid structure aligns with the trajectory segments of the motion control profile, the calculated feed-forward signal 210 is compensated by a feedback signal 212 indicating the actual kinematic state of the load handling device relative to the grid structure. The kinematic state of the load handling device on the grid structure can include, but is not limited to, a position and a velocity of the load handling device relative to the grid structure. The velocity of the load handling device can be derived from the first derivative of its position with respect to time, for example.
Based on the feedback signal 212, the position controller 184 can adjust or compensate the controlling signal, determined based on the motion profile 194 from the trajectory generator 182, to ensure that the load handling device moves according to the motion control profile as closely as possible.
In the present system, the feedback signals 212 are generated using a kinematic model 198 instead of one or more position sensors on the load handling device (which would be fed back to the position controller to reflect the “true” state of the load handling device relative to the grid structure). As described above, using such a kinematic model 198 in place of the one or more position sensors allows for a feedback reference of the kinematic state of the load handling device, to help with controlling the positioning in accordance with a generated trajectory, without the disadvantages associated with using physical sensors mounted on the load handling device. More explanation of determining the kinematic state of the load handling device using such a kinematic model 198, e.g. in place of the one or more position sensors, is provided below.
In response to receiving data signals from the kinematic model 198, the position controller 184 can be instructed to re-generate one or more trajectory segments of the motion control profile 194, e.g. by varying one or more manipulated variables, to ensure that the load handling device arrives at its commanded target position on the grid structure.
In examples, the feedback signal 212 from the kinematic model 198 is combined with the feedforward signal 210 to generate a total torque demand for the wheels (or the drive mechanism driving the wheels). A comparison is made between the trajectory position derived from the motion control profile and the position determined from the kinematic model 198. The comparison represents a positional error, i.e. the difference between the trajectory position reference and the modelled position as a function of time. The positional error is fed into a PID (proportional, integral and derivative) controller (or PI controller) 214, which corrects the position to the setpoint, represented by the motion control profile. The correction from the PID or PI controller 214 is combined with the feedforward signal 210 to generate a total torque demand.
As shown in the communication paths of
In one example, the feedforward torque demand is calculated as follows:
Total Torque Demand=Feedforward Torque Demand+Feedback Torque Demand;
where:
Feedforward Torque Demand=Acceleration Feedforward Torque Demand+Velocity Feedforward Torque Demand+Zero-order Torque Demand Value;
where:
Acceleration Feedforward Torque Demand=Trajectory Acceleration×Acceleration Feedforward Gain;
Velocity Feedforward Torque Demand=Trajectory Velocity×Velocity Feedforward Gain;
Zero-order FF Torque Demand=sign(Trajectory Velocity)×Zero-order Torque Demand Value;
where the values of the following variables are empirically determined:
Acceleration Feedforward Gain is a value that depends on the estimated total mass of the load handling device, inclusive of the container and its contents, such that it has a higher gain value when the load handling device carries a heavier container.
Velocity Feedforward Gain also depends on the estimated total mass of the load handling device.
Zero-order Torque Demand Value is the value of total torque demand required to keep the load handling device moving at a constant, near-zero velocity, i.e. it is a proportionality factor.
These three components, acceleration feedforward, velocity feedforward and zero-order torque demand value, are summed together to make up the feedforward torque demand and stored in a look-up table. When compensating the calculated feedforward torque demand with the feedback torque signal, the controller retrieves the feedforward torque demand from the look-up table to combine with the feedback torque measurement.
As described above, the total calculated demand is translated to appropriate controlling signals to drive the wheels. In examples, the total torque demand is shared between the first or the second set of wheels, depending on which of the first and second sets of wheels are engaged with the grid structure. As also described in examples, each wheel of the first and second set of wheels may be driven individually by hub motors 220. The first set of wheels comprises a pair of wheels at the front of the body and a pair of wheels at the back of the body. A similar pair of wheels are present for the second set of the wheels, i.e. a first and second pair of wheels on either side of the body of the load handling device. In operation, the pairs of wheels are driven in synchronisation, e.g. as if on “virtual” or “imaginary” axles. For example, the front pair of wheels are driven in synchronisation as if driven on the same axle, and the rear pair of wheels are similarly driven in synchronisation as if driven on the same axle. The same principle applies to the second set of wheels, even though individual hub motors drive them. Equally and applicably, all four wheels of the first set of wheels may be driven in synchronisation, and similarly, all four wheels of the second set of wheels may be driven in synchronisation. The advantage of driving the wheels of the wheel assembly individually by hub motors is that the torque applied to the wheels can be distributed in different amounts to the wheels, which can be helpful during slippage of any of the wheels.
In examples, the torque demand derived from the motor control profile, or the compensated total torque demand, is distributed between the wheels of the wheel assembly by a biasing mechanism 216. The biasing mechanism 216 divides the total torque demand between the front and rear wheel pairs, e.g. “axles”, to account for any weight transfer of the load handling device on the grid structure. For example, when the load handling device is accelerating on the grid structure, a greater proportion of the calculated total torque demand may be transferred to the front “axle”. Conversely, when the load handling device decelerates on the grid structure, the total torque demand may be transferred more to the rear “axle”. Thus, the biasing mechanism can vary the amount of torque to the first and rear “axles” to transfer the weight of the load handling device between the front portion and rear portion of the load handling device accordingly when accelerating or decelerating on the grid structure.
In examples, the biasing mechanism 216 applies a differential torque demand to the wheels, more specifically to the motors driving the wheels, in accordance with the trajectory acceleration reference of the motion control profile. The trajectory acceleration reference and/or the trajectory velocity reference of the motion control profile provides an indication or a reference point as to whether the load handling device is accelerating or decelerating on the grid structure. In other words, the differential torque applied to the wheels follows the trajectory acceleration reference of the motion control profile, i.e. there is a proportional relationship between the distribution of the torque to the wheels and the trajectory acceleration reference of the motion control profile. In response to signals from the motion control profile generator indicating the load handling device is to accelerate, the biasing mechanism 216 selectively transfers more of the calculated total torque demand to the front axle than the rear axle. Conversely, when instructed to decelerate, the total torque demand is shifted to the rear axle, or the total torque demand is reduced, to provide a “braking” force. Equally, when cruising on the grid structure, the total torque demand may be substantially equally divided between the front and rear “axles”.
As well as the differential torque applied to the front and rear wheel “axles”, the torque demand communicated to the wheel motors can also be controlled on either side of the body of the load handling device, e.g. to control the yawing or turning of the load handling device on the grid structure. For example, depending on the direction of travel of the load handling device on the grid structure, the torque demand can be used to control the speed to the left set or right set of wheels and, thereby, to control the yawing or turning angle of the load handling device on the grid structure. In some instances, with the arrangement of the grid members extending in transverse (X-Y) directions, the differential torque applied to the left and right wheels is controlled to prevent the load handling device from yawing or turning on the tracks i.e. to travel in a substantially straight line.
In addition to translating the motion control profile to control signals for driving the drive mechanism, the biasing mechanism 216 can also be configured to control the slip of the wheels on the tracks as well as periodically compensating the motion control profile in response to receiving position signals from the kinematic model (in place of one or more position sensors mounted to the load handling device) and/or one or more positional track sensors.
Inplace of the one or more position sensors, the kinematic model can also determine a slip of any one of the first and second sets of wheels on the tracks. This is shown in
Slippage of the wheels can occur when the rotational speed of any of the wheels is greater than a velocity component of the kinematic state of the load handling device on the grid structure. The kinematic state of the load handling device on the grid structure is determined using the kinematic model 198. For load handling devices 30 with position sensors 98a, 98b, the velocity component of the kinematic state is derivable from a first derivative of the position component of the kinematic state, as determined by the one or more position sensors, as a function of time—e.g. the rotational speed of the first or second “fifth” wheel depending on whether the load handling device is travelling in the first direction or the second direction.
In examples, the individual rotational speed of each wheel of the first and the second sets of wheels is determined by one or more wheel encoders disposed adjacent to each wheel. The one or more wheel encoders can be an incremental encoder comprising a rotary electromechanical device that generates pulses indicative of the rotational speed of the wheel. An example wheel encoder comprises a magnetic sensor, e.g. a Hall Effect sensor, that can measure the strength of a magnetic field and a ring magnet attached to the motor shaft. When the motor rotates the wheel, it also rotates the ring magnet. The magnetic sensor positioned near the ring detects changes in the magnetic field as the ring magnet rotates. The sensor can count incrementally how many times the motor has rotated. As the ring magnet completes one full rotation, the magnetic sensor detects a set number of changes (e.g. pulses or “ticks”) in the magnetic field as each magnetic pole of the ring magnet passes by the sensor. For a ring magnet with four pairs of magnetic poles, the magnetic sensor would count four pulses during one full rotation, for example. Each rotation of the motor also turns the wheel a given angular rotation, e.g. a certain number of degrees. With this information, e.g. the gearing ratio of the motor and wheel, the number of pulses counted by the wheel encoder representing one revolution of the wheel can be calculated. The expected distance travelled per pulse or rotation can also be determined using the wheel circumference.
Another example of a rotary wheel encoder is an optical encoder. A disc with transparent and opaque areas is attached to the motor shaft and arranged between a light source and a photodetector array that reads an optical pattern that results from the disc's angular position at any given time. A further example is a capacitive rotary encoder in which an asymmetrically shaped disc is rotated within the encoder between two electrodes. Changes in the capacitance between the electrodes can be measured and used to determine an angular value.
In examples, a slip control manager manages the slip of each of the wheels of the wheel assembly by individually comparing the rotational speed of the wheels to the kinematic state of the load handling device on the grid structure determined from the kinematic model in place of the first or second “fifth” wheels. In the example shown in the schematic block diagram of
It will be appreciated that, alternatively, the above described slip control manager may be used in conjunction with the first or second “fifth” wheels. In this way, the rotational speed of the wheels can be directly determined by the output of the “fifth” wheels.
In either case, with “fifth” wheels or without, the slip control manager may be arranged to reduce the torque on the wheel which is experiencing slip. For example, when a first wheel is detected to be experiencing slip, the slip control manager may reduce the torque demand for that particular wheel to zero torque. All the other wheels being utilised but not experiencing slip have their torque levels maintained (i.e. not adjusted). Although in this example the slipping wheel has zero torque applied, other values may be used, for example, the torque demand for the slipping wheel may be reduced to 20% of the original value. One disadvantage of this method of slip control is that it induces an undesired torque on the load handling device, causing it to skew in its trajectory to one side or the other. Where slip events are infrequent and short lasting the undesired torque can be effectively ignored given the undesired torque experienced by the load handling device is minimal.
However, for longer lasting slip events the undesired torque experienced by the load handling device may become problematic. To that end, the slip control manager may instead be arranged to apply slip control on a “virtual” or “imaginary” axle basis, similar to that described previously with regard to biasing the torque between a front virtual axle and a rear virtual axle. In particular, when slip on one particular wheel is detected (whether using a “fifth wheel” or not), the slip control manager is arranged to reduce the torque demand for both of the wheels on the virtual axle. For example, if a rear right wheel of the load handling device experiences a slip event then the torque demand for both of the rear right wheel and the rear left wheel (the rear left wheel being on the same virtual axle as the rear right wheel) are reduced. Preferably, the reduction in torque demand to the wheels on the virtual axle is identical. In this way, the load handling device no longer experiences the undesired torque of the previous slip control method because the torque reduction is equal on both sides of the load handling device. In one example, where the rear right wheel experiences a slip event, the torque demand to the rear virtual axle may be reduced to zero. However, such a dramatic reduction in torque on the load handling device may cause a sudden speed reduction for the load handling device. Alternatively, where the rear right wheel experiences a slip event, the torque demand to the rear virtual axle may be reduced to 20% of its original value. Accordingly, both the rear right wheel and rear left wheel experience a reduction in torque demand to 20% of their original value. In this way, the reduction in speed is not as dramatic and the load handling device may remain on its movement plan.
Additionally, the slip control manager may be further arranged to apply the lost torque to the virtual axle not undergoing a slip event. For example, where the rear right wheel experiences a slip event, the torque demand to the rear virtual axle may be reduced to 20% of its original value. In other words, the torque demand to the individual wheels on the rear virtual axle is reduced to 20% of their original value. However, the torque demand removed from this virtual axle (80% of its original value) may be added to the front axle, in other words each of the front left and front right wheels has added to their torque demand a proportion of the torque demand removed from the rear virtual axle. Accordingly, whilst the rear virtual axle is reduced to 20% of its original value, the front virtual axle has its torque demand increased by torque demand removed from the rear virtual axle. In this way, the speed reduction for the load handling device as a whole is mitigated.
It is to be understood that the architecture shown in
The positioning system 300 also includes, in examples, one or more force sensors for the respective wheels 134 of the load handling device. The one or more force sensors are configured to detect a load on a corresponding wheel, for example. The one or more force sensors may comprise a force transducer that converts an applied force, e.g. a weight loaded onto a wheel, into a linear electrical signal via measurement of movement in the wheel assembly structure using a force-sensing resistor.
In other examples, the positioning system 300 includes one or more force estimators configured to estimate a load on a corresponding wheel. For example, the load on a corresponding wheel may be estimated taking into account the weight transfer during acceleration and deceleration, e.g. based on a mass of the load handling device including an estimated mass of a tote and its payload when carried by the load handling device, using methods known by a person skilled in the art. For example, considering front and rear virtual axles for the front and rear wheel pairs, the vertical loads on the front axle Z1 and the rear axle Z2 may be determined as:
The initial load on the front axle Z1,0 is determinable based on the mass m of the load handling device, e.g. including any tote mass and payload being carried, a distance a2 between the rear axle and the centre of mass of the load handling device, and the wheelbase l:Z1,0=mg·a2/l. Similarly, the initial load on the rear axle Z2,0 is determinable using instead a distance a1 between the rear axle and the centre of mass of the load handling device: Z2,0=mg·a1/l. The middle terms in the axle loading equations represent the aerodynamic drag forces Z1,a=−Z2,a which can be determined, for example, by the expression
where ρ is the fluid (air) density, ν is the velocity of the load handling device, S is a reference area of a face of the load handling device, and C is a shape coefficient e.g. for a rectangular cross section of the load handling device. Finally, the longitudinal load transfer ΔZ is determinable based on the acceleration a of the load handling device and the height h of the centre of mass as: ΔZ=−ma·h/l.
The positioning system 300 includes storage 330 to store a trained model for determining creep values for the load handling device based at least on a given vertical load on a given wheel of the load handling device. The storage 330 may be a random-access memory (RAM) such as DDR-SDRAM (double data rate synchronous dynamic random-access memory). In other examples, the storage 330 may include non-volatile memory such as Read-Only Memory (ROM) or a solid-state drive (SSD) such as Flash memory. The storage 330 in some cases includes other storage media, e.g. magnetic, optical or tape media, a compact disc (CD), a digital versatile disc (DVD) or other data storage media. The storage 330 may be removable or non-removable from the data positioning system 300.
In the context of a wheel moving on a rail, creep is related to a difference between the wheel's rotational speed and its linear speed. For example, the contact area between the wheel and the rail, which is typically elliptical, can be divided into a stick (no-slip) region and a slip region. Longitudinal creep (or “micro slip”) and tangential (tractive) forces arise due to the slip that occurs in the trailing region of the contact patch. As the tractive force increases, the slip region increases, and the stick region decreases—resulting in contact with rolling and sliding. Creep forces act in the plane of the contact patch and are related to the friction between the wheel and rail. The distortion in the wheel and rail is small and localised, but the forces that arise can be significant. In addition to the distortion due to the weight, both the wheel and rail distort when braking and accelerating forces are applied, and when the vehicle is subjected to lateral forces.
For a creeping force to develop, a certain amount of (micro-) slip is required. In some instances, the tangential forces depend on the normal load, friction conditions and relative motion between the contacting surfaces. These tangential forces distort the region where they first come into contact, followed by the region of slippage. The net result is that (a) during traction, the wheel does not advance as far as would be expected from rolling contact, and (b) during braking, it advances further. This mix of elastic distortion and local slipping is known as “creep” (separate from the creep of materials under constant load). The creep in this context, in terms of displacement, is given by ζ=(x−s)/s=Δs/s, where x is the actual displacement of the vehicle and s is the rolling displacement.
Similarly, in terms of velocities, for a free-rolling wheel, an expected linear velocity (in m/s) based on the angular velocity ω (rad/s) is given by the multiplication r·ω where r is the wheel radius (m). There should be a positive velocity delta for a positive tangential force, i.e. Av=(r·ω)−ν. The relation between this velocity difference and the linear velocity is also given by the velocity creep: σ=Δν/ν which is dimensionless. As such, the velocity (or “longitudinal”) creep can be expressed as the rate σ∈[0,1], given by:
where re stands for the effective radius of the wheel at the point of contact with the track. The linear speed of the centre of the wheel, ν, is equivalent to the speed of the load handling device.
The contact forces involved in the wheelset dynamics of the vehicle 132 can be treated as linearly dependent on the creep (c.f. Joost Jacques Kalker's linear theory, valid for small creepage). Similarly, the forces which result in directional stability, propulsion and braking of the vehicle 132 can also be linked to the creep. It is present in a single wheelset and can accommodate the slight kinematic incompatibility introduced by coupling wheelsets without causing gross slippage. All the driving wheels 134, 136 of the load handling device 130 thus have to turn faster than the vehicle 132 is actually moving (known as creep control) to use the maximum coefficient of friction that is available. The maximum available friction occurs when the wheels are creeping. During the transition from the “all-stick” no-torque to the “all-slip” condition, the wheel has a gradual increase in slip, also known as creep and creepage.
In some nomenclatures, “slip” is the additional speed that the wheel has and “creep” is the level of slip divided by the locomotive speed, as outlined above. These parameters are measurable using physical sensors, e.g. position or speed sensors. The measured data can go into a creep controller 218 to control the respective driving mechanisms of the wheelsets based on the slip and creep levels. In the present examples, however, the creep controller 218 obtains a modelled creep value for the load handling device rather than a measured creep value based on position sensor data.
More specifically, the processing unit 340 of the present positioning system 300 is configured to obtain at least one coefficient value for the trained kinematic model and determine a creep value using the kinematic model stored in the storage. In examples, a vertical load value for a wheel, e.g. obtained from the corresponding force sensor or estimated taking into account the weight transfer and any tote mass and payload, is also an input to the processor 340 for determining the creep value using the kinematic model.
The at least one coefficient value is obtained by the model's training using recorded creep data for a plurality of training load handling devices. For example, in one embodiment, the kinematic model comprises a parameterised model for the creep of a wheel, e.g. a mathematical model of the creep in terms of parameters such as the wheel radius and one or more coefficients. The coefficient value(s) to be used when calculating the creep are determined by training the model using the recorded creep data with known parameter values. For example, the training load handling devices 30, such as the one shown in
In examples, the processor 340 determines the kinematic state of the load handling device based on the modelled creep values for the respective wheels or wheelsets of the load handling device by averaging the creep values across the said wheels or wheelsets. For example, different wheelsets may be under different loading conditions, as described in examples above, which is accounted for in the model (e.g. using a loading parameter value in the parameterised model example). Averaging the determined creep values across the wheelsets can help reduce the noise level in the creep data and resulting kinematic data for the load handling device.
The following equation gives an example parameterised model:
where σ is the creep value of a given wheel or wheelset of the load handling device, a is the coefficient value, T is a nominal torque applied to the wheel or wheelset, r is a radius of the wheel(s), and N is a nominal vertical load on the wheel or wheelset. The torque is a difference between a motive torque and a cumulative resistive torque, TM−TR, for example.
The above example parameterised model can be derived from considering the torque balance, which can be written as:
where TM is the motive torque, TR is the cumulative resistive torque, F is the traction force (i.e. friction between the wheel and the ground), J is the wheel inertia, and {dot over (ω)} is the rotational acceleration of the wheel. Then considering the driving case, and leveraging the earlier expressions for a rotating wheel, it is possible to write the creep as:
where a linear relationship between the coefficient of friction and creep, μ=σ/a, is used and again the symbol N represents the vertical load on the wheel. The linear relationship μ=σ/a is found to be a reasonable approximation of a curve of μ against σ in a stable region where the creep is less than a maximum creep, σM, at maximum traction between the wheel and track, i.e. σ<σM. The coefficient α may be a fictitious constant related to the stiffness of the tyre or wheel. Substituting the torque balance assuming the term J{dot over (ω)} to be negligible, i.e. rF=TM−TR, reaches the example parameterised model as expressed above.
For this example model, the single coefficient value α is determined during the training of the parameterised model and stored with the model for calculating future creep values of wheels 134, 136 on load handling devices 130 moving around the grid structure 115.
Another example parameterised model of the vehicle (or “bot”) velocity incorporating a coefficient to account for the velocity slip is given by the equation:
where νw is the velocity of a given wheel or wheelset, β is the coefficient value, τ is a torque applied to the wheel or wheelset, and N is the weight transfer, e.g. vertical load, on the wheel or wheelset. For this example model, the single coefficient value β is determined during the training of the parameterised model and stored with the model for calculating future velocity values of load handling devices 130 moving around the grid structure 115.
The kinematic model comprises an artificial neural network (or simply “neural network”) model in other embodiments. In general, neural network systems undergo what is referred to as a “training phase”. The neural network is trained for a particular purpose—in this case determining creep values for the wheels of a load handling device based on measured parameters. A neural network typically includes several interconnected neurons forming a directed, weighted graph in which vertices (corresponding to neurons) or edges (corresponding to connections) of the graph are associated with weights. The weights may be adjusted throughout training, altering the output of individual neurons and the neural network as a whole. Thus, the one or more coefficient values for the kinematic model may correspond to weight data representative of weights to be applied to the input data inputted to the neural network. The input data comprises measured wheel state data, such as the loading of the wheel or wheelset, a nominal torque applied to the wheel or wheelset, and a wheel radius, for example. After the training phase, the neural network (which may be referred to as a trained neural network and corresponds to the trained kinematic model) can determine creep values based on new wheel state data.
In some examples utilising neural networks, “structured” networks are used as they can generally be more useful than “unstructured” networks for this type of analytical problem. In structured neural networks, transfer functions may be stacked in a hierarchical way to create networks that have a large number of hidden layers. Each of the hidden layers can be seen as the next layer up in a series of non-linearities and computation is an iterative process in which layer outputs are used as inputs to compute the outputs for subsequent layers. A structured neural network can thus be trained using supervised or unsupervised learning. Conversely, unstructured neural networks do not have any hierarchical organisation; they are just a set of linear, static, fully connected neurons. They can thus be trained only in an unsupervised manner, since there is no mechanism to define input and output neurons.
In other embodiments, the kinematic model comprises a support-vector network, a Bayesian network, or another suitable mathematical model for predicting the creep of wheels based on measured wheel state data using a training dataset of creep values calculated from measured wheel state data and corresponding kinematic data of the vehicles. For example, were a nonlinear model used for determining the creep values, a kalman filter could be implemented to estimate the coefficient values in the model.
A kinematic model involving force terms, e.g. the parameterised model examples above involving torque and normal forces, may be referred to instead as a “dynamic model”.
In examples, the storage 330 stores multiple trained models. For example, each trained model corresponds to a trajectory phase of the load handling device, such as an acceleration phase, a deceleration phase, and a cruise phase. Thus, a given model may be selected from the multiple trained models depending on the current trajectory phase of the load handling device, e.g. whether it is accelerating, decelerating, or cruising with substantially zero acceleration. The one or more coefficients of the respective models are thus trained based on recorded data during a corresponding trajectory phase, for example.
In examples, multiple trained models are stored, corresponding to respective loading modes of the load handling device. For example, the loading mode could be an unloaded mode, where the load handling device has no loading, such as when not transporting a container. Similarly, the loading mode could be a loaded mode where the load handling device has some loading such as when transporting a container of items. Another possible loading mode is a fully loaded mode, e.g. where the load handling device has a loading substantially equal to a maximum load threshold. Furthermore, there may be one or more part loaded modes where the load is between substantially zero (e.g. unloaded) and an intermediate load threshold below the maximum load threshold (e.g. fully loaded).
The plurality of trained models may be the same model or model type, with respective coefficient values determined from training the respective model. For example, the same parameterised model may be used for each trajectory phase, but with different coefficient values (e.g. values of a in the above example parameterised model) determined by the training for the corresponding trajectory phase. Similarly, there may be multiple neural networks used, with one for each trajectory phase and/or loading mode, where the network weights are determined differently based on the different training data corresponding to the said trajectory phases and/or loading modes.
In examples, the processor 340 determines the kinematic state of the load handling device based on encoder data obtained from the one or more wheel encoders, alongside the modelled creep value. As described above, the individual rotational speed of each wheel is determinable from the encoder data captured by the one or more wheel encoders in which a rotary device inside the encoder generates pulses indicative of the rotational speed of the wheel.
The processing unit 340 can be a general-purpose processor such as a central processing unit (CPU), a microprocessor, a DSP, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or another programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any suitable combination thereof designed to perform the functions described herein.
In the examples described with reference to
In examples, referring back to
In examples, the grid-type storage system, e.g. as described previously with reference to
With such AIDC tags, it is possible to locate a given load handling device relative to the grid structure by providing each of the load handling devices with one or more AIDC tag readers or scanners. The AIDC tags may be fixed relative to the grid structure to provide a series of reference points on the grid structure. As the given load handling device moves across the grid structure, the load handling device's respective AIDC tag reader reads the signals from one or more of the AIDC tags fixed at various locations on the grid structure. Typically, the AIDC tags are fixed at a junction or crossroads of the tracks at each grid cell. Each AIDC tag (or “label”) contains encoded data, e.g. corresponding to the tag's location in the grid structure, such as coordinate data in terms of grid cells.
In such examples where AIDC means are employed in the storage system, the processing unit 340 of the positioning system may be further configured to determine the kinematic state of a load handling device based on automatic identification data captured by the AIDC machine reader mounted on the load handling device. The AIDC machine reader is itself configured to read encoded data from the one or more AIDC tags. For example, the kinematic state of the load handling device determined using the trained model is refined based on the captured automatic identification data from a scanned tag in the grid structure. The readings (or “activations”) of the AIDC machine reader (or other “grid sensor”) provide an independent source of position information for the load handling device, e.g. a source of truth for the position of the load handling device on the grid structure, at a lower resolution. The activations of the grid sensor can thus be used to refine the one or more coefficients in the kinematic model, which are adaptive in examples. When the load handling device crosses a grid cell boundary, the one or more coefficients are updated accordingly, for example.
Returning to the example parameterised model above for the velocity creep value (or “slip ratio”), σ, and expressing the model in terms of the vehicle (or “bot”) velocity yields:
In these equations, νw=rω is the wheel velocity with r being the wheel radius parameter, ω the angular velocity of the wheel, and νb the bot velocity. An estimation of the bot position can then be derived based on the above equation for the bot velocity, e.g. by integration of the bot velocity with respect to time, which is set out in more detail below.
In examples, the wheel radius r and model coefficient parameters, e.g. α, are assumed to be constants. At each sampling time, an estimate of the loading force N for each wheel may be made based on an internal model of the bot physics. Additionally, or alternatively, the estimate of the of the loading force N for each wheel may be made based on a target acceleration value, e.g. produced by the controller, which may be treated as an approximation of the real acceleration of the bot in the algorithm. A resistive torque value is also computed at each sampling time, based on the internal model of the bot physics and the most recent estimation of the bot speed, for example. The values of the wheel velocity and motive torque may be published as data by a component, e.g. the motor 220. The above equation for the bot velocity may be calculated for each of the wheels driving the bot to produce multiple corresponding estimates of the bot velocity. The different estimates are averaged to reduce the effect of perturbations, for example. The resultant bot velocity estimate is then integrated with respect to time to obtain an estimate of the bot position, as mentioned above.
For example, integrating the above equation for the bot velocity between two time instants t1 and t2 yields:
where the substitution for the resultant torque, T=TM−TR, has been made for completeness. By choosing the two time instants to correspond with two consecutive activations of the grid sensors, the term on the left may represent the distance the wheel has travelled during this time, i.e. the length of the grid cell, which is a known parameter:
where the time instants, ek−1 and ek, are those chosen to correspond with activations at two contiguous grid cells, k−1 and k. In the resultant equation, a and b are parameters representing the resultant values of the respective time integrals. A least-squares method can thus be applied to this equation form using the known cell length value, i.e. the length of a single grid cell in the grid structure 115, for scell. This allows the parameters α and r to be refined, e.g. continuously updated, using the grid sensor activation information. The least-squares method is a Bayesian Recursive Least Squares algorithm in certain cases.
In further examples, an estimate of the track length ŷ is given by:
where H represents a 2×1 vector defined by the two time integrals, {circumflex over (θ)} is the estimated 2×1 vector of the wheel radius re and α parameters, and d˜(0, R) is a stochastic noise parameter with an expected value of zero and a variance R, representing the physical uncertainty in the cell length. Alternative notation is used here for the normal force, FN, and the wheel radius re. A transpose of one of the column vectors H or {circumflex over (θ)} may be used for multiplying them together.
In examples, initial estimates of the model parameters, e.g. α and re, are determined by running the kinematic model on recorded data, e.g. “offline”, to find a good fit for each of the parameter values, e.g. using a classical least-squares method. For example, logged data recorded from multiple load handling devices operating in the storage system comprises data for the velocities, torques and tote masses which can be inputted into the kinematic model to estimate the unknown model parameters, e.g. by a classical least-squares algorithm. As described above, the model parameters can then be refined when running the kinematic model “online”, e.g. using live data for the velocities, torques and tote masses. For example, a recursive least-squares (RLS) method is implemented for the latter refining phase, such as the Bayesian RLS algorithm.
A method of refining the model parameters, e.g. α and re, may involve defining a covariance matrix, P=diag(λr
The method may then comprise three main steps:
where the notation Xa has been used to distinguish a current value of a given variable X from the new refined value the variable is assuming in that step of the method.
The method thus allows the model parameters to be refined (or “re-tuned”) at each grid sensor activation. The estimate ŷ of the cell length may be maintained close to the nominal (known) value. The error in computing the bot velocity using the model can also be kept in check.
At 401, wheel state data, representative of a state of a wheel of the load handling device, is obtained from one or more sensors communicatively coupled to the wheel. In examples, the wheel state data comprises torque data representative of a nominal torque applied to the wheel of the load handling device. The wheel state data may additionally or alternatively include load data representative of a nominal vertical load on the wheel of the load handling device. In some examples, the wheel state data represents the state of a set of wheels (a wheelset), e.g. a nominal torque applied to the wheelset and/or a nominal vertical load on the wheelset. The one or more sensors are thus sensors to measure the corresponding type of wheel state data. For example, the sensors include one or more force sensors configured to detect a load on a corresponding wheel.
At 402, a creep value for the load handling device is determined based on the wheel state data using a trained model. As described in earlier examples, the trained model may include at least one of a neural network, a Bayesian network, a support-vector network, or a parameterised model. The corresponding descriptions apply. In the parameterised model example, the method 400 may also include obtaining a tyre coefficient value determined from training the parameterised model and inputting the tyre coefficient value into the parameterised model with the obtained wheel state data. Examples of tyre coefficients α and β were given in the example parameterised models. Such tyre coefficients may be stored in storage to be accessed and inputted into the parameterised model to calculate new creep values and/or bot velocity values. In the neural network model example, the coefficients may correspond to weights of the neural network obtained during the training phase and stored as part of the neural network model for applying to calculate new creep values and/or bot velocity values.
As described in earlier examples, there may be multiple trained models from which a given model is selected as part of the method 400 of determining the kinematic state of the load handling device. For example, the selection of the given model is dependent on the current trajectory phase and/or the loading mode of the load handling device. For example, the trajectory phase corresponds to whether the load handling device is accelerating, decelerating, or cruising. The one or more coefficients of the respective models are thus trained based on recorded data during the corresponding trajectory phase, for example. The loading mode could be an unloaded mode, a fully loaded mode where the load handling device has a loading substantially equal to a maximum load threshold, or one or more part loaded modes where the loading is between substantially zero and the maximum load threshold.
At 403, the kinematic state of the load handling device is determined based on the modelled creep value. For example, the kinematic state includes at least one of a position, a velocity, an acceleration, a jerk, or an orientation of the load handling device. The position, velocity, acceleration and jerk components of the kinematic state can be evaluated from one another via integration or differentiation with respect to time. Thus, a modelled velocity creep can be used to apply a delta correction to an estimated bot velocity evaluated based on the rotational wheel velocity. Integration of the corrected bot velocity can give a corrected bot position accounting for the creep (or “micro slip”) of the wheels, which is a feature of the wheel's traction mechanics as discussed earlier.
At 404, kinematic data representative of the kinematic state of the load handling device is output. The output kinematic data can be used to generate a target position for the load handling device, e.g. in accordance with examples described with reference to
As described above, the determined kinematic state of the load handling device can be refined based on automatic identification data captured by an automatic identification and data capture (AIDC) machine reader mounted on the load handling device and configured to read encoded data from one or more AIDC tags, e.g. RFID tags, located at predetermined points in the grid pattern.
The method 400 of determining the kinematic state of the load handling device can be implemented by one or more processors, e.g. the processing unit 340 of the positioning system 300 described with reference to
The above examples are to be understood as illustrative examples. Further examples are envisaged. For example, although in the examples described above the creep estimation o=au is used for each of the three motion phases of the load handling devices, e.g. acceleration, deceleration and cruise, while the model coefficients may be determined (and dynamically refined in certain examples) for each phase independently. Examples are envisaged wherein a different relationship between the creep and bot velocity is used for at least one of the motion phases of the load handling device. For example, a simplified relationship may be used for the cruise phase. When cruising, the load handling device is moving at a substantially constant speed, meaning that the traction force needs to only balance out the resistive forces to maintain the substantially constant speed, with the wheels working at a relatively low friction coefficient value, μ. Thus, a different relationship between the creep and friction coefficient may be appropriate for the cruise phase compared to the linear relationship used for at least one of the other motion phases. In some cases, the bot velocity is representable by a nonlinear equation. As described in examples above, a different approach may be implemented for a nonlinear dynamic model, e.g. implementing a kalman filter.
Examples are also envisaged in which the effective wheel radius is neither assumed to be constant nor parameterised as a single variable, but rather expressed as a linear function of the nominal radius and the vertical load, e.g. re=r(1−γFN), where r is the nominal wheel radius and re is the effective wheel radius under loading. Thus, a further parameter is introduced to the model, e.g. γ, which may be considered to be a constant in all three motion phases for the load handling device. In these examples, the need to maintain different model parameters for each of the motion phases may be removed by such parameterisation of the effective wheel radius to try and reduce fluctuations in the estimated parameters of the model.
Furthermore, in addition to the methods described in which a trained model is used to determine creep values, and kinematic states of the load handling device based thereon, examples are envisaged of methods to train a model for calibrating a positioning system of a load handling device. Such a method includes, for example, building a training dataset of calculated creep values and/or corresponding kinematic states determined for a plurality of training load handling devices, e.g. based on wheel velocity data recorded using position sensors mounted on the plurality of training load handling devices, configured to execute predetermined moves. The training dataset (also simply referred to as “training data”) is inputted to a machine-learning algorithm to build the kinematic model based on the training data in order to make predictions of creep values and/or corresponding kinematic states of load handling devices, without being explicitly programmed to do so. For example, an artificial neural network can be used as the machine learning algorithm to develop the kinematic model based on the training data—the “trained” neural network corresponding to the kinematic model. The trained model can then be used to calibrate the positioning system of the load handling device by inputting new data into the neural network which outputs a predicted creep value and/or kinematic state of the load handling device based thereon. For example, determining the kinematic state of the load handling device may involve obtaining the wheel state data from one or more sensors communicatively coupled to the wheel, and determining, based on the wheel state data and using a trained kinematic model comprising a machine learning algorithm (e.g. neural network), the kinematic state of the load handling device. Kinematic data representative of the kinematic state of the load handling device can then be outputted in the same way.
As an example, a (structured) neural network may comprise two parallel sub-networks (A and B) as shown in
The architecture of the sub-network A can be defined by any number of layers and parameters, with the only constraint that the final layer has a number N of parameters, matching the dimensionality N of the state space. In the same way, the architecture of the sub-network B can be defined by any number of layers and parameters, with the constraint that the final layer has a number M of parameters, matching the dimensionality M of the control space.
Such a defined neural network provides a model of the form {dot over (x)}=A(x, u)x+B(x, u)u where {dot over (x)} is the time derivative of the kinematic state vector x. This equation for the kinematic model then represents the dynamic of the state of a physical system. If the dynamical system is linear and time-invariant A and B will be constant. In the present case, the terms of the integrals in the equations change at each move, thus A and B will be time-varying but still linear (at least around the current working point, i.e. linearised in the current state). This means that A and B are functions of the inputs u, but could in general also be functions of the current state x. In a continuous time system, the output at a given time t can be dependent on the state at time t. This is not a strict requirement of the model but is a general possibility, for example A and B might be different if the load handling device is accelerating compared to when it is decelerating. Alternatively, in a discrete time implementation of this system, the model may be of the form xk+1=Ã(xk,uk)xk+{tilde over (B)}(xk, uk)uk where the matrices à and {tilde over (B)} representative of the sub-networks of the system are different to those in the continuous time implementation (A and B).
In these examples, the neural network may be trained using classical gradient-based optimizers, for example, and then implemented in a discrete-time manner, e.g. by a processor onboard the load handling device.
It is also to be understood that any feature described in relation to any one example may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the examples, or any combination of any other of the examples. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the accompanying claims.
Number | Date | Country | Kind |
---|---|---|---|
2112007.6 | Aug 2021 | GB | national |
2201029.2 | Jan 2022 | GB | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/GR2022/000043 | 8/19/2022 | WO |