Patent Description:
Small electric vehicles (personal mobility vehicles) such as mobility scooters and electric wheelchairs are treated as pedestrians under the law if they satisfy regulations for speed, vehicle body size, and the like, and travel in pedestrian traffic zones such as sidewalks and roadside strips instead of roadways. For such small electric vehicles, in addition to manual driving according to operations by an occupant, investigation is underway to enable self-driving, in which the vehicle follows a predetermined route using sensor information, map information, and location information obtained by positioning means (see, Patent Literature <NUM>, for example). Patent Literature <NUM> discloses an operation system for autonomous personal mobility vehicles that may pick up a passenger and self-drive to a target location and a parking location. Patent Literature <NUM> discloses a system for dispatching a charging vehicle to an intermediate location of another vehicle in case this other vehicle does not have sufficient energy to reach a destination.

By including a self-driving function in a small electric vehicle that is permitted to travel on sidewalks, not only autonomous driving by manned self-driving but also dispatching and returning (retrieving) by unmanned self-driving are possible, which are expected to be used for automatic transportation services and the like. However, unlike the case of ordinary vehicles that travel on roadways with a standardized road structure, various challenges exist in relation to enabling self-driving for the case of small electric vehicles that travel on sidewalks.

For example, in the case of ordinary vehicles, the travel lane of the road is fixed regardless of self-driving or manual driving, and thus, in the case of providing an automatic transportation service, the route is simply planned so that the pick-up/drop-off position for passengers is at the edge of the road on the travel lane (left lane) side. However, in the case of a sidewalk-traveling vehicle like an electric wheelchair, manual driving enables the occupant to select whether to travel on the sidewalk adjacent to the left side or the right side of the road. In addition, while traveling on the right side of the road is recommended for roads without a sidewalk, there are no laws prohibiting this.

However, when providing an automatic transportation service using an electric wheelchair, the obligation and responsibility for travel lies with the service provider, who is required to comply with the mobility regulations in (<NUM>) through (<NUM>) below.

Also, in the case of unmanned self-driving, the treatment is similar to an automated delivery robot for the delivery and pickup of goods, and the vehicle is considered to be a sidewalk-traveling vehicle similar to an electric wheelchair robot, subject to the condition of being remotely monitored. However, considering the impact on the movement of surrounding pedestrians and the like, actions which are discouraged in manned driving, such as reversing on sidewalks, are difficult to implement from the standpoint of providing an automatic transportation service.

Consequently, when dealing with navigation for self-driving wheelchairs, issues like the following need to be addressed, and it is difficult to propose an optimal mobility service using conventional route planning and navigation methods that assume a conventional motor vehicle or a manually driven electric wheelchair.

In particular, if a route is generated as-is in response to (c) and (d) above, there is a concern that the user will feel uncomfortable from incorrectly thinking that the self-driving wheelchair, which is circling around or taking a detour in the travel segment, will pass by the destination point without noticing, or that the user (occupant) will cancel self-driving unexpectedly or drop-off unexpectedly and abandon the electric wheelchair.

Accordingly, research is underway to make it possible to increase the selection possibilities for traffic patterns and avoid circling around and the like by generating a route using, in combination, dispatching by unmanned self-driving, manned self-driving, and manual driving by the user. Although the addition of the manual driving option in this way increases the freedom in route selection, there is also a need to consider that battery consumption increases in accordance with the driving style and distance traveled during manual driving by the user, and that the return to the vehicle station may fail due to insufficient battery power during manual driving by the user or during the period after the drop-off of the user until the return to a vehicle station.

The present invention has been made in the light of the above points, and an object thereof is to provide an operation system for a small electric vehicle that can execute rapid and reliable retrieval in cases in which autonomous return would fail due to insufficient battery power or the like.

To solve the above problems, the present invention is an operation system as defined in the independent claim <NUM>.

As described above, the operation system for a small electric vehicle according to the present invention has the retrieval support function that, in a case in which return to the vehicle station is predicted to fail, selects the vehicle retrieval point at or before the anticipated failure point and calculates the anticipated arrival time at the vehicle retrieval point, and therefore, in a case in which autonomous return would fail due to insufficient battery power or the like, the retrieval point for the vehicle and the anticipated arrival time at the retrieval point are acquired in advance and early, and therefore rapid and reliable retrieval can be performed, which is advantageous for preventing a situation in which the vehicle would be detained in an inappropriate place such as partway up a hill or in the middle of an intersection.

Hereinafter, an embodiment of the present invention will be described in detail and with reference to the drawings.

In <FIG>, an operation system for a small electric vehicle according to the embodiment of the present invention includes at least one small electric vehicle <NUM> (hereinafter also simply referred to as a vehicle <NUM> in some cases), an operation server <NUM> for managing and operating the vehicle <NUM>, an operator <NUM> (operator interface), and at least one user <NUM> (user communication terminal <NUM>; client). In the following description, a case in which one of each exists is described for convenience, but in actual operations, it is anticipated that a large number of small electric vehicles <NUM> (<NUM>') will be registered in the operation server <NUM> and, although fewer in number, a plurality of operators <NUM> and a plurality of user terminals <NUM> will simultaneously connect to the operation server <NUM>.

The operation server <NUM> is provided with a communication system <NUM>, a vehicle management part <NUM>, a user management part <NUM>, a planning part <NUM>, a map database <NUM>, and an infrastructure coordination part <NUM>, and is configured by hardware including at least one computer and software running on the computer.

The communication system <NUM> is implemented as a fixed communication terminal permanently connected to a communication network provided by a telecommunications carrier, enabling the client (user terminal <NUM>) to connect to the operation server <NUM> over the Internet and/or a mobile communication network and utilize a service through data communication, and also enabling the operation server <NUM> to connect to a communication terminal <NUM> of the vehicle <NUM> over the Internet and a mobile communication network, and remotely manage and operate the system of the vehicle <NUM>.

The vehicle management part <NUM> is a database with which the operation server <NUM> manages the registered small electric vehicle <NUM> (<NUM>'), individually stores information groups such as an ID of the vehicle, model information, registered station, status (such as standing by on full charge, preparing to dispatch, be dispatched, self-driving, manual driving, returning, waiting for retrieval, retrieving, and charging), battery power (SOC), battery state of health (SOH), using user ID, presented plan (travel route) information, and operation history, and is provided to enable efficient management and operation of each vehicle <NUM> (<NUM>') by the operation server <NUM>.

In particular, the vehicle management part <NUM> is provided with a battery power monitoring part that estimates a drivable distance from the battery power (SOC) during actual travel of the vehicle <NUM> and compares the drivable distance to the scheduled remaining driving distance on the travel route and the return route according to a presented plan to monitor whether the battery power is sufficient. If the remainder of the drivable distance with respect to the scheduled remaining driving distance falls to zero or to a threshold value or below, the battery power monitoring part determines that the battery power is insufficient and predicts a driving limit point (failure point). Thereafter, retrieval support for the vehicle <NUM> is performed on the basis of this information. This point will be described later.

The user management part <NUM> is a database for managing a user who connects to and is registered with the operation server <NUM> (registered user; hereinafter, unless specifically noted otherwise, a user denotes such a registered user), individually stores information groups such as a user ID, authentication information, registered terminal information, reservation information, usage information, and a usage history, and is to enable efficient management and operation by the operation server <NUM>.

The map database <NUM> (map system) has a layered structure consisting of: road map data for display, which is a general road map with expanded data relating to pedestrian traffic zones such as sidewalks, roadside strips, crosswalks, and entrances and exits of parks and facilities; text data corresponding to names and the like on the map; and map data for route search which corresponds to a geometric route structure, with the data in each layer being specified by and associated with location information (latitude and longitude coordinates). The road map data for display provides a map display to a display screen of the operation server <NUM>, on which text data is overlaid onto the map display depending on the zoom level. The text data is also used for text search.

As illustrated in <FIG>, for example, the map data for route search includes nodes (for example, 60a, 61a, 60b, 61b, and so on) set at traffic turning points such as intersections (junctions to crosswalks), bend points, railroad crossings, facility locations (entrances and exits) connected by sidewalks and roadside strips designated as pedestrian traffic zones, and links (for example, La, Lb, and so on) set for each driving style allowed in the traffic zones connecting adjacent nodes, with each link being set as vector data for which orientation is uniquely determined by an initial point node and an final point node. Consequently, for a sidewalk (for example, 50a) allowing for travel in both the forward and backward directions during manual driving or the like, two links (La, Lb) are set in the forward and backward directions, respectively. On the other hand, for a roadside strip (for example, 50b), basically only a link (La) in the forward direction is set.

For example, as illustrated by the enlarged view of the area around a corner of the intersection <NUM> in <FIG>, the links in both the forward and backward directions of sidewalks 51a and 52a attached to the roads <NUM> and <NUM>, respectively, and the links of crosswalks 51c and 52c crossing the roads <NUM> and <NUM>, respectively, are connected to a node 63a in a corner of the intersection <NUM>. Note that in <FIG> and in <FIG>, described later, the roads are denoted by the reference numerals <NUM> to <NUM> while the intersections are denoted by the reference numerals <NUM> to <NUM>.

Furthermore, a travel cost depending on the route length and a secondary travel cost depending on factors such as the road grade, width, and surface condition are set for each link, a secondary travel cost (penalty score) depending on the link connection angle and width (space) is set for each node, and route search is executed on the basis of these costs.

The planning part <NUM> (route generation part) is provided with a search algorithm that searches, on the basis of dynamically set nodes such as a departure point (pick-up point) and a destination (drop-off point) input into the display screen or the like of the operation server <NUM>, for an optimal route from among a large number of travel routes connecting the nodes, performs a route display corresponding to the optimal route (and alternative routes) returned by the search, and also has functions for registering a confirmed route (travel plan) selected by the user <NUM> in the user management part <NUM> and registering the confirmed route in the vehicle <NUM> to be dispatched.

The infrastructure coordination part <NUM> acquires external information distributed by external organizations, such as road control information (traffic congestion, accidents, road closures, and the like), weather information (rainfall, snowfall, wind speed, and the like), and environmental information (smog, pollution) through the communication system <NUM> and maintains and updates the external information over its validity period so that the planning part <NUM> can refer to the information for route search.

The operation server <NUM> is provided with, separately from an input-output device for the setup and operation/management thereof, a monitor <NUM> and a remote control part <NUM> enabling the operator <NUM> to perform remote monitoring and remote control of the small electric vehicle <NUM>. These are installed as an operator interface in a control seat of the operator <NUM>, for example, and in such a control seat, a communication terminal <NUM> enabling the operator <NUM> to communicate with the communication terminal <NUM> of the subject vehicle <NUM> and the communication terminal <NUM> of the user <NUM> through the communication system <NUM> is also installed.

On the monitor <NUM>, various setting information for the operation server <NUM>, registration information pertaining to the vehicle management part <NUM> and the user management part <NUM>, external information acquired by the infrastructure coordination part <NUM>, and the like can be displayed in response to operations by the operator <NUM>. Additionally, on the monitor <NUM>, a map provided by the map database <NUM>, a route generated in the planning part <NUM>, particularly the confirmed route (including a dispatch route and a return route described later) and navigation registered in the user management part <NUM> and the vehicle <NUM> to be dispatched can be displayed, and an image (video) from a camera (external sensor <NUM>) of the subject vehicle <NUM> can also be displayed. With this arrangement, the operator <NUM> can remotely control the subject vehicle <NUM> with the remote control part <NUM> while checking on the monitor <NUM> a forward video (and a surrounding video) while the subject vehicle <NUM> is traveling.

The user communication terminal <NUM> of the user <NUM> may also be a fixed terminal used when renting or ordering the small electric vehicle <NUM>, but for the purposes of dispatch guidance and authentication of the subject vehicle <NUM>, is preferably a mobile terminal that can be carried when using the subject vehicle <NUM>. Note that the small electric vehicle <NUM> is also provided with an in-vehicle speaker and pickup microphone connected to the communication terminal <NUM> to enable voice calls with the operator <NUM> during manual driving and the like, and by providing a passcode input device (such as a keypad), authentication of the subject vehicle <NUM> is possible, although a mobile terminal is necessary for guidance prior to dispatch.

The small electric vehicle <NUM> is configured as a personal mobility vehicle (sidewalk-traveling vehicle) such as a mobility scooter or an electric wheelchair, in which a vehicle body is provided with a seat and a plurality of wheels, including drive wheels, and is provided with a manual control part <NUM> enabling manual driving by the user <NUM> (occupant) in a seated state and a drive unit <NUM> for driving the drive wheels.

For the manual control part <NUM>, a joystick type that can be disabled easily during self-driving is suitable, but a handle type is also possible. In the case in which a handle-type steering control part is provided, in addition to the need for a steer-by-wire steering system, the handle itself is preferably retracted, folded, or covered by a cowling to make it difficult to be grasped by other pedestrians or the like.

The drive unit <NUM> can be configured as an electric wheelchair type, in which the driven wheels are provided as freewheels (omni-directional wheels) and the left and right drive wheels are driven separately by left and right motors such that forward and backward movement and left and right turning can be performed by controlling the left and right motors, but can also be configured as a mobility scooter type, in which the left and right drive wheels are driven by a single motor and the driven wheels are steered by an electric power steering apparatus. Although not particularly limited, the former is more consistent with a joystick-type manual control part, whereas the latter is more consistent with a handle-type manual control part.

In addition to the manual driving mode in which the small electric vehicle <NUM> travels under user control, to enable operation in the self-driving mode for traveling autonomously in accordance with a predetermined route under remote monitoring, as illustrated in <FIG>, the small electric vehicle <NUM> includes a communication terminal <NUM> for mobile data communication and connection with the operation server <NUM> through the communication system <NUM>, a navigation device <NUM> for route guidance, a driving control part <NUM> that controls the drive unit <NUM> according to the route guidance, a positioning system <NUM>, and an external sensor <NUM>.

For the positioning system <NUM>, it is suitable to provide a global navigation satellite system (GNSS) receiver for receiving GNSS signals and acquiring the absolute location of the vehicle through positioning calculations, a magnetic sensor for measuring the geomagnetic field and acquiring the heading of the vehicle, and an inertial sensor for detecting the attitude, or in other words the three-dimensional inclination, of the vehicle, thereby enabling localization <NUM> of the vehicle and route guidance by the navigation device <NUM>.

For the external sensor <NUM>, it is suitable to provide cameras for imaging in front and around (the rear and sides) of the vehicle, and a LiDAR (laser scanner) for recognizing course structures and obstacles in front of the vehicle, whereby the combination of this detection information enables course environment recognition and obstacle recognition for autonomous driving.

For example, road surface markings such as white lines (lane markings) and crosswalks are recognized from a camera image, course structures of sidewalks and roadside strips are recognized from LiDAR 3D point cloud data, and by combining this recognition information, the course of the small electric vehicle <NUM> and its position in the lateral direction on the course are specified. Traffic signals and road traffic signs are also recognized from the camera image and used for driving control. Note that, as described already, the camera image (video) is transmitted to the operation server <NUM> through the communication terminal <NUM> and used for remote monitoring and remote control by the operator <NUM>.

The driving control part <NUM> recognizes the course environment and driving status of the vehicle <NUM> on the basis of the above-described localization <NUM> by the positioning system <NUM>, the route provided by the navigation device <NUM>, and obstacle and course environment recognition <NUM> based on detection information from the external sensor <NUM>, and at the same time predicts the movement of nearby mobile objects and controls the drive unit <NUM> to achieve autonomous driving by decelerating or stopping to avoid interference if there is a possibility of interference. Also, if an obstacle consisting of a non-mobile object on the course is detected, a local route for avoiding the obstacle is generated, and steering avoidance is executed.

The small electric vehicle <NUM> is provided with: a battery (secondary battery) that supplies power for driving to the drive unit <NUM> and low-voltage operating power to a control system, which includes the navigation system <NUM> and the driving control part <NUM>; and a battery management unit (BMU) for monitoring the input-output current, total voltage, and remaining capacity of the battery and for managing the status of the battery. The BMU has a function for calculating the remaining capacity (SOC) on the basis of the integral of the input-output current (cumulative power consumption).

When performing a route search in the planning part <NUM>, reference points for the following four locations are set as dynamic nodes on the basis of input information from the user <NUM> connected to the operation server <NUM>.

Of these, if (<NUM>) and (<NUM>) are not selected from among existing nodes on the road map data, nodes are added on links that pass through or are adjacent to the designated points.

A travel cost (L1) depending on the route length and a secondary travel cost (L2) depending on factors such as the road grade, width, and surface condition are set for each link, and a secondary travel cost (penalty score) depending on the width or space (N1) and the link connection angle (N2) is set for each node, as already described. In a route search, the travel cost (L1) depending on the route length (PL) is the major cost of a route search, whereas the other travel cost (penalty score) is a secondary cost supplement metric that adjusts the main cost in an increasing direction. More practical travel routes can be derived by combining known route search methods (such as the A* algorithm and Dijkstra's algorithm) with "main cost (L1) adjustment by a cost supplement metric (L2, N1, N2)" to find an optimal route with the lowest total cost.

For example, in <FIG>, if a search for a travel route is performed using the travel cost (L1) depending on the route length PL (travel distance) of each link, the route passing through the nodes N11 and N21 has the shortest total route length, and the route passing through the nodes N11 and N21 is the optimal route.

However, if there exists an element (L2) indicating the load actually incurred during travel besides the cost (L1; route length, travel time) associated with the travel itself, the element is incorporated into the link as a cost supplement metric and the travel cost is adjusted. The cost supplement metric (L2) may also include a temporary cost (penalty score) acquired by the infrastructure coordination part <NUM>, such as traffic congestion information and road maintenance information other than the above.

For example, if road maintenance information (Ld1) and traffic congestion information (Ld2) exist on the two links indicated by the dashed lines in <FIG>, the travel costs (PL=<NUM>, PL=<NUM>) for these links are adjusted by the temporary travel costs (Ld1, Ld2), respectively. For example, if Ld1 and Ld2 are weighted to be <NUM> and <NUM> times the cost, the route passing through the nodes N12, N23, and N31 has the lowest cost.

Note that, in addition to travel costs such as the width or space (N1) and the link connection angle (N2) for nodes, it is also necessary to recognize traffic signals when passing through intersections and crosswalks, wait for signals as necessary, and pass through at the appropriate time, and travel costs caused by the above are also incurred. In the case of a railroad crossing, a link cost associated with crossing the railroad tracks is also incurred in addition to the cost of recognizing an alarm (warning sound) and the crossing gate.

Moreover, a time-limited cost (penalty score) acquired by the infrastructure coordination part <NUM> may also be added to a node. For example, if intersection congestion information (Nd3) exists for the node N21 indicated by the dashed line in <FIG>, the travel costs (PL=<NUM>, PL=<NUM>) for the links connected to the node N21 may also be adjusted by the temporary travel cost (Nd3).

Next, the flow from route generation to travel plan presentation in response to a dispatch request from a user in the operation system according to the present invention will be described with reference to the flowchart in <FIG> and the maps in <FIG>.

First, the user <NUM> desiring to use the small electric vehicle <NUM> (automatic transportation service) connects to the operation server <NUM> and inputs reservation information such as the desired use date, desired pick-up time, desired pick-up point, destination point (desired drop-off point), and the like (step <NUM>).

If the input of information by the user <NUM> is completed, the operation server <NUM> accesses the vehicle management part <NUM>, compares the desired pick-up point of the user <NUM> to the status of vehicles <NUM> registered in a vehicle station <NUM> located in a service area, and selects a vehicle <NUM> with compatible status, cruising range (charge level), and the like (step <NUM>).

In addition, as illustrated in <FIG>, the planning part <NUM> first adds the selected vehicle station <NUM>, the desired pick-up point <NUM> and destination point (desired drop-off point) <NUM> of the user <NUM> as dynamic nodes 70n, 71n, and 72n to the map data for route search. Accordingly, dynamic links (indicated by thick arrows in <FIG>) starting or ending at these nodes 70n, 71n, and 72n are also added to the data.

Next, in the map data for route search to which dynamic nodes (links) have been added as described above, a search for an optimal route is performed under the assumption that the vehicle will travel from the vehicle station <NUM> to the desired pick-up point <NUM> (71n) by unmanned self-driving, travel from the desired pick-up point <NUM> (71n) to the destination point <NUM> (72n) by manned self-driving, and then return from the destination point (desired drop-off point) <NUM> (72n) to the vehicle station <NUM> by unmanned self-driving (step <NUM>).

In <FIG>, base routes (<NUM>, <NUM>) generated under the assumption of self-driving as described above are indicated by block arrows. The base routes (<NUM>, <NUM>) include a dispatch route (5a to 5c) that travels from the vehicle station <NUM> to the desired pick-up point <NUM> by unmanned self-driving, a user travel route (5d to <NUM>) that travels from the desired pick-up point <NUM> to the destination point (desired drop-off point) <NUM> by manned self-driving, and a return route (<NUM>; 6a to <NUM>) that travels from the destination point (desired drop-off point) <NUM> to the vehicle station <NUM> by unmanned self-driving.

Next, the planning part <NUM> executes a search for an optimal route with respect to the user travel route (5d to <NUM>) with consideration for the case in which the user <NUM> travels by manual driving (step <NUM>).

As described above, since the base routes (<NUM>, <NUM>) assume only self-driving, the links going in the opposite direction on each sidewalk are excluded from the search. However, since manual driving by the user <NUM> is also possible on the user travel route (5d to <NUM>), a route search that also includes the links going in the opposite direction on each sidewalk is performed, and there is also a possibility that travel cost will be reduced, such as by the travel route being shortened, as a result of switching from self-driving to manual driving.

For example, the base route <NUM> illustrated in <FIG> crosses a road <NUM> at an intersection <NUM>, travels along the sidewalk (forward-direction link <NUM>) along a road <NUM>, crosses the road <NUM> at an intersection <NUM> (link <NUM>), and travels on the sidewalk (forward-direction link <NUM>) on the opposite side of the road <NUM> to reach the entrance (node 72n) of the destination <NUM>.

However, if the case of traveling by manual driving is considered, as illustrated in <FIG> which is an enlarged view of the main portion of <FIG>, the user could switch to manual driving at a point 66a after crossing the road <NUM> at the intersection <NUM>, cross a crosswalk (link 5p), and drive on the sidewalk (backward-direction link 5q) on the opposite side of the road <NUM> to reach the entrance (node 72n) of the destination <NUM>.

The user <NUM> can accept manual driving and change to such an alternative route 5X (5p, 5q) to thereby shorten the route (shorten the time required). Moreover, since there is a possibility that the user may incorrectly think that by traveling on the base route (<NUM> to <NUM>) prioritizing the forward direction, the vehicle will pass by the destination <NUM> without noticing, it is preferable to notify the user in advance that a circle-around will occur as described above when presenting the base routes (<NUM>, <NUM>) as the optimal route. This arrangement makes it possible to avoid a situation in which the user who did not select the alternative route 5X feels uncomfortable during actual travel or unexpectedly disengages self-driving and drops off.

Next, the minimum of the desired pick-up point <NUM> (71n) of the user <NUM> is changed, that is, the unmanned driving segments (dispatch route 5a to 5c) adjacent to the node 71n is changed to <NUM> or <NUM> nodes (alternative nodes), and a search for an optimal route is executed (step <NUM>).

The desired pick-up point <NUM> is designated according to the desires of the user <NUM>, but as a result, there is also a possibility that the point is not an optimal point given the circumstances (such as the location of the vehicle station <NUM> and the transportation conditions) on the service-providing side, and in some cases, the user <NUM> may designate a point without a definite reason. Consequently, in some cases, a slight change in the pick-up point may be expected to reduce costs and shorten the route (shorten the time required) by more than the cost of accepting the cost of travel by the user <NUM> for the change.

For example, as illustrated in <FIG>, by searching for an optimal route with the node set at the corner of the intersection <NUM> adjacent to the desired pick-up point <NUM> (71n) of the user <NUM> treated as an alternative node 71n' (alternative pick-up point candidate), an alternative route 5Y (5r) that crosses (link 5r) the intersection <NUM> directly from the point is generated.

The alternative route 5Y requires movement 7c equivalent to one link 5c of the user <NUM>, but having the user <NUM> accept this cost has the advantage of shaving off the cost of circle-around on a route that travels on the sidewalk (forward-direction link 5d) along the road <NUM> in the direction away from destination <NUM>, crosses (link 5e) the road <NUM> at an intersection <NUM>, travels on the sidewalk (forward-direction link 5f) on the opposite side of the road <NUM>, crosses (link <NUM>) the road <NUM> at the intersection <NUM>, and crosses (link <NUM>) the road <NUM> again, and two road crossings on the base route <NUM>.

Note that it is obvious that additional burdens on the user <NUM> should be minimized as much as possible, but depending on the status of the dispatch route adjacent to the desired pick-up point, a shorter route (shorter time required) is expected in some cases by further changing the pick-up point.

Accordingly, the travel cost is recorded as a provisional value for the case of treating the first alternative node 71n' described above as a primary alternative node, a search for an optimal route is performed with the secondary alternative node (the node adjacent to the intersection <NUM>) adjacent to the primary alternative node 71n' treated as an alternative pick-up point candidate, and the travel cost in that case is compared to the provisional value of the travel cost associated with the primary alternative node to verify whether further cost reduction is expected. These provisional values preferably also include the travel costs of the user associated with a pick-up point change, so as to avoid over-burdening the user. Additionally, a threshold value may be imposed on the travel distance for the alternative node, and the alternative process may be terminated when the threshold value is exceeded.

For example, in the example illustrated in <FIG>, the primary alternative node 71n' is confirmed because no large cost reduction, such as avoiding a road crossing, is expected from changing from the primary alternative node 71n' to the secondary alternative node (the node adjacent to the intersection <NUM>) compared to the increased burden on the user, or because the travel distance will exceed the threshold value.

As described above, when travel plans (base plan and alternative plans) to be presented to the user <NUM> have been provisionally confirmed through the generation of the base routes <NUM> and <NUM> assuming only self-driving, the generation of the alternative route 5X considering manual driving, and the generation of the alternative route 5Y considering changes of the pick-up point, the planning part <NUM> references external information (infrastructure information) acquired through the infrastructure coordination part <NUM> and verifies whether there are any obstacles such as traffic congestion or weather conditions in each provisionally defined route plan (step <NUM>).

If infrastructure information to be considered exists on the base route <NUM> (step <NUM>; NO), the base routes <NUM> and <NUM> are generated again with consideration for the infrastructure information. If infrastructure information to be considered exists only on the alternative route 5X, only the alternative route 5X is generated again, and depending on the circumstances, the presentation of a travel plan is performed without including a presentation of the alternative route.

For example, <FIG> illustrates a case in which, on the day in question, the user <NUM> has requested a vehicle dispatch from near the pick-up point <NUM> using a mobile terminal or the like as the user terminal <NUM>, and the generation of a travel plan was executed, but when there is a road closure 53X due to a traffic accident or the like on the road <NUM>, routes <NUM>' and <NUM>' are generated to bypass the road closure 53X through links <NUM> and 5t and links 6p, 6q, and 6r instead of the base routes <NUM> and <NUM>.

The case in which infrastructure information to be considered exists only on the base route <NUM> (return route) is handled by, for instance, comparing the travel cost associated with returning to the vehicle station <NUM> by the re-generated return route <NUM>' to the travel and retrieval costs to another station or retrieval point. The return routes <NUM> and <NUM>' are not presented to the user <NUM>, and are displayed only on a management screen of the operator <NUM> or the like.

If the travel plans (base plan, alternative plans) to be presented are confirmed via verification according to infrastructure information (step <NUM>; YES), the planning part <NUM> presents the travel plans (base plan, alternative plans) to the user <NUM> (step <NUM>).

That is, each of the following travel plans is presented to the user:.

These travel plans are presented to the user in a state with, for example, the nodes and links and the return routes <NUM> and <NUM>' hidden from the administrative map (map for route search) illustrated in <FIG> or <FIG>, with the travel route <NUM> and the alternative routes 5X and 5Y superimposed onto the road map data for display, and with captions such as estimated time required (estimated arrival time) for each of the travel plans added. The travel plans may also be accompanied by voice guidance.

If the user <NUM> selects one of the travel plans (step <NUM>; YES), the user travel plan is confirmed, and an order is confirmed on the basis of registration information pertaining to the user <NUM> (step <NUM>).

On the other hand, if the user <NUM> does not select any of the travel plans or has performed a cancel operation, the process is canceled (step <NUM>).

Next, dispatch and route traveling assuming the case in which the user <NUM> has selected a travel plan including both of the alternative routes 5X and 5Y will be described with reference to the flowchart in <FIG> and <FIG>.

If the user travel plan is confirmed and an order by the user <NUM> is confirmed (step <NUM>), the operation server <NUM> proceeds to dispatch preparation of the small electric vehicle <NUM> selected for dispatch (hereinafter simply referred to as the subject vehicle <NUM>). First, the operation server <NUM> performs a download of navigation data pertaining to the confirmed travel plan, user authentication information, and the like to the navigation device <NUM> of the subject vehicle <NUM> through the communication system <NUM> and the communication terminal <NUM> (step <NUM>).

If the download (information registration) to the subject vehicle <NUM> is completed and a dispatchable state is achieved, the subject vehicle <NUM> stands by at the vehicle station <NUM> until a departure time back-calculated from the pick-up time of the date of use (step <NUM>). Note that in the case of an immediate dispatch request, the subject vehicle <NUM> departs the vehicle station <NUM> toward the pick-up point (71n') as soon as the dispatch preparation is completed. In this case, the user <NUM> is notified of the expected arrival time as the expected pick-up time. Note that although the three travel plans described above are displayed in <FIG>, routes other than the confirmed travel plan are not displayed on the communication terminal <NUM> of the user <NUM> (HMI device of the subject vehicle <NUM>).

The subject vehicle <NUM>, under monitoring by the operator <NUM>, travels on the dispatch route (links 5a, 5b) from the vehicle station <NUM> toward the pick-up point (71n') by unmanned self-driving (step <NUM>). In the case of an immediate dispatch request, the user <NUM> travels (7c) from the original desired pick-up point (71n) to the changed pick-up point (71n') on foot during this time. Note that the changed pick-up point (71n') in the example illustrated in the drawing is set to a corner of the intersection <NUM>, but since there is a possibility that this location may be crowded with other pedestrians and the like, the subject vehicle <NUM> stops shortly before the changed pick-up point (71n') and gives notice of its arrival to the user <NUM> by flashing the blinkers or the like. In addition, the user communication terminal <NUM> of the user <NUM> is notified of the arrival of the subject vehicle <NUM> at the changed pick-up point (71n').

The vehicle <NUM>, having arrived at the changed pick-up point (71n'), enters a state of standing by for authentication by the user <NUM>, and driving functions are locked until an authentication operation is performed by the user <NUM>. If authentication (lock release) by the user <NUM> is completed, the subject vehicle <NUM> enters a state of standing by to depart, and if the pick-up of the user <NUM> onto the subject vehicle <NUM> is completed (step <NUM>) and the user <NUM> performs a departure operation such as by operating a start button on the HMI device of the subject vehicle <NUM> or on the user communication terminal <NUM>, the subject vehicle <NUM> initiates manned self-driving toward the destination point <NUM> (step <NUM>).

Immediately after starting off, the subject vehicle <NUM> changes direction to cross the crosswalk (link 5r) at the intersection <NUM>, checks for a green light to cross the road <NUM> at the crosswalk (link 5r), travels on the sidewalk (link 5i) along the road <NUM>, and turns right at the corner of the intersection <NUM> to travel on the roadside strip (link 5j) of the road <NUM>.

During manned driving, too, the driving status (such as driving and stopping, location, and SOC) of the subject vehicle <NUM> is monitored by the operation server <NUM> (operator <NUM>) through the communication system <NUM> (<NUM>). The operation server <NUM> records the driving location and time of the subject vehicle <NUM> in the vehicle management part <NUM> (user management part <NUM>). The operator <NUM> can check the location and status of the subject vehicle <NUM> through navigation information displayed on the monitor <NUM>, such as a vehicle indicator on a map screen, and can check the status of the subject vehicle <NUM> and the user <NUM> through an image from a camera (external sensor <NUM>). With this arrangement, in the event of a driving failure or a significant deviation from the route during travel in the manual driving mode (described later), the operator <NUM> can communicate with the user <NUM> through the communication terminal <NUM> of the subject vehicle <NUM> or the communication terminal <NUM> of the user <NUM>, and if necessary, remotely control the subject vehicle <NUM> with the remote control part <NUM> while checking a forward video (and a surrounding video) of the subject vehicle <NUM> on the monitor <NUM>.

If the travel plan includes a switchover to manual driving (step <NUM>; YES, the present example corresponds to this case), at a predetermined timing, such as when the subject vehicle <NUM> approaches the switchover point (intersection <NUM>) for switching over to manual driving, the user <NUM> is given advance notice of the imminent arrival at the switchover point for switching over to manual driving from the HMI device of the subject vehicle <NUM> (or the user communication terminal <NUM>). Thereafter, the subject vehicle <NUM> stops after crossing the intersection <NUM>, the user <NUM> is notified of the switchover to the manual driving mode, and the subject vehicle <NUM> enters a state of standing by for an operation by the user <NUM>.

If the user <NUM> performs a prescribed operation, such as operating a start button, the manual control part <NUM> goes into an operable state, the navigation device <NUM> (or navigation through the user communication terminal <NUM>) is initiated, and driving is switched to the manual driving mode by the user <NUM> (step <NUM>).

Through manual driving by the user <NUM>, the subject vehicle <NUM> crosses the road <NUM> at the crosswalk (link 5p) of the intersection <NUM>, turns right, and travels on the sidewalk (link 5q) along the road <NUM>, thereby arriving at the destination <NUM> (node 72n) (step <NUM>; YES) and also ending the manual driving mode of the subject vehicle <NUM>, and if the user <NUM> completes drop-off (step <NUM>), the subject vehicle <NUM> travels on the return route (<NUM>; 6a to <NUM>) by unmanned self-driving to return to the vehicle station <NUM> (step <NUM>).

Note that in the time between giving advance notice of approaching the switchover point (intersection <NUM>) for switching over to the manual driving until notifying the user of the switchover to the manual driving mode, or after switching over to the manual driving mode, if the user <NUM> issues a self-driving request to the operator <NUM>, it is also possible to switch to self-driving under remote control by the operator <NUM>. Also, when presenting the travel plan <NUM>, an option for such self-driving under remote control may also be selectable.

Next, the retrieval support function for the case in which insufficient battery power is predicted during route traveling and autonomous return will be described with reference to the flowchart in <FIG> and <FIG>.

As illustrated in step <NUM> of <FIG>, during manned driving also, the driving status (such as driving/stopped, location, and SOC) of the subject vehicle <NUM> is monitored by the operation server <NUM> through the communication system <NUM> (<NUM>). In particular, at the same time as when the subject vehicle <NUM> initiates manned self-driving toward the destination point <NUM>, the vehicle management part <NUM> (battery power monitoring part) estimates the drivable distance from the battery power (SOC) of the subject vehicle <NUM> and compares the drivable distance to the scheduled remaining driving distance on the travel route <NUM> and the return route <NUM> according to the travel plan to initiate monitoring of whether the battery power is sufficient (step <NUM>).

When dispatching the subject vehicle <NUM>, the battery power is confirmed to be sufficient for the scheduled travel plan, and thus, insufficient battery power does not occur immediately after the start of manned self-driving, but as described already, the addition of the manual driving option means that the possibility of running out of battery power before returning to the vehicle station <NUM>, due to the driving style and increased travel distance during manual operation, cannot be ruled out. In particular, the situation in which the vehicle stops in the middle of the traffic flow due to insufficient battery power during autonomous return by unmanned driving should be avoided.

Accordingly, if the remainder of the drivable distance with respect to the scheduled remaining driving distance falls to zero or to a threshold value or below, the vehicle management part <NUM> (battery power monitoring part) predicts that (there is a high probability that) autonomous return to the vehicle station <NUM> will be impossible due to insufficient battery power at that time (step <NUM>; YES).

In this case, the vehicle management part <NUM> (battery power monitoring part) activates the retrieval support function and begins preparing for retrieval with consideration for the drivable distance according to the battery power (SOC) at that time (step <NUM>).

For example, as described previously, if the user <NUM> has selected the travel plan including both of the alternative routes 5X and 5Y so as to switch to autonomous return when the user <NUM> drops the vehicle off at the destination point <NUM> (72n) after driving close to the destination point <NUM> by manual driving, assuming that autonomous return from the scheduled drop-off point (72n) to the vehicle station <NUM> is predicted to be impossible during the manual driving mode, a search is performed for an alternative retrieval point existing in the map data for route search within the drivable distance of the subject vehicle <NUM>, with the scheduled drop-off point (72n) set as the starting point.

On the administrative map (map for route search) illustrated in <FIG>, if an adjacent vehicle station <NUM> near the intersection <NUM>, a public space <NUM>, and an empty lot <NUM> near the intersection <NUM> are detected as candidate spots for the alternative retrieval point (step <NUM>; YES), the adjacent vehicle station (<NUM>) is more preferably set as the alternative retrieval point than the public space <NUM> and the empty lot <NUM>, as long as sufficient battery power remains.

However, with route generation assuming travel by unmanned self-driving, a retrieval route that proceeds from the starting point <NUM> to the intersection <NUM> in the opposite direction from the alternative retrieval point <NUM>, crosses the crosswalk (link 6i), proceeds to the intersection <NUM> (link 6j) along the road <NUM>, crosses the road <NUM> (link <NUM>), and additionally crosses (<NUM>) the road <NUM> is recommended, and thus, it is problematic in that the retrieval route is actually a large circle-around and includes three road crossings. The case of the public space <NUM> has a lower travel cost than the adjacent vehicle station <NUM>, but is similar in being a large circle-around.

On the other hand, the empty lot <NUM> has a longer straight-line distance than the adjacent vehicle station <NUM> and the public space <NUM>, but can be reached by crossing (6a, 6p) the roads <NUM> and <NUM> at the intersection <NUM> and proceeding straight (link 6q) along the road <NUM>, and has a travel cost even lower than the public space <NUM>, and therefore, the empty lot <NUM> is selected as the alternative retrieval point (step <NUM>).

If the alternative retrieval point <NUM> is confirmed, the expected arrival time of the subject vehicle <NUM> at the alternative retrieval point <NUM> by unmanned self-driving is calculated (step <NUM>). If the subject vehicle <NUM> has not arrived at the destination point <NUM>, the expected arrival is taken to be at or after an expected arrival time based on the travel time from the destination point <NUM> to the alternative retrieval point <NUM> at that time, and is displayed on the monitor <NUM> together with the travel route to the alternative retrieval point <NUM> to give notice to the operator <NUM>.

The operator <NUM>, having obtained the alternative retrieval point <NUM> and expected arrival time of the subject vehicle <NUM>, contacts a retriever <NUM> through the communication terminal <NUM>, directly or via the operation server <NUM>, and transfers the alternative retrieval point <NUM> and expected arrival time of the subject vehicle <NUM> to a communication terminal <NUM> of the retriever <NUM> to arrange for retrieval of the subject vehicle <NUM> (step <NUM>).

As above, by executing a search for an alternative retrieval point on the basis of the drivable distance at the time when autonomous return of the subject vehicle <NUM> to the scheduled return spot (vehicle station <NUM>) is predicted to fail, the alternative retrieval point <NUM> and estimated arrival time of the subject vehicle <NUM> can be transmitted in advance to the retriever <NUM>, and the subject vehicle <NUM> can be retrieved rapidly and reliably upon its arrival at the alternative retrieval point <NUM> in a state with battery power to spare. With this arrangement, the time that the subject vehicle <NUM> is detained at the alternative retrieval point <NUM> instead of the schedule return spot can be shortened, and a situation in which the subject vehicle would be detained in an inappropriate place, such as partway up a hill or in the middle of an intersection, can be avoided.

Note that in step <NUM>, if a candidate spot for an alternative retrieval point satisfying the conditions is not detected, the subject vehicle <NUM> is moved by remote control by the operator <NUM> and is stopped in a place that does not obstruct the flow of traffic, the location is treated as an extraordinary alternative retrieval point (step <NUM>), and the location information is transferred to the retriever <NUM> to arrange for retrieval.

As above, in the case in which the autonomous return of the subject vehicle <NUM> to the schedule return spot (vehicle station <NUM>) fails and the retriever <NUM> retrieves the subject vehicle <NUM> at an alternative retrieval point, retrieval is also assumed to be burdensome due to reasons such as the retriever <NUM> not being familiar with the alternative retrieval point or having difficulty in locating the stopped location of subject vehicle <NUM> at the alternative retrieval point. Accordingly, it is preferable to have an additional retrieval support function for the retriever <NUM> as follows.

For example, besides displaying the relative distance as a numerical value, the emitted light intensity of a light-emitting part such as the screen may be changed progressively (from a weak light to a bright light), the color of the light-emitting part may be changed, or the periodicity of an intermittent signal such as a flash of light or a buzzer may be shortened progressively, according to the relative distance. A signal that changes depending on the relative bearing may also be emitted instead of the relative distance or simultaneously with the relative distance.

There is an advantage in that, even if the alternative retrieval point is a place with poor visibility or is a dark place, or if the retrieval time is after sunset, the retriever <NUM> can check the change in the signal outputted from the communication terminal <NUM> to easily determine whether the retriever <NUM> are approaching or moving away from the subject vehicle <NUM>, making it easy to find the subject vehicle <NUM> as a result.

Claim 1:
An operation system for an electric personal mobility vehicle (<NUM>), the operation system including:
an operation server (<NUM>) connected to a communication system (<NUM>) and comprising a map database (<NUM>) which includes links set for pedestrian traffic zones including sidewalks; and
an electric personal mobility vehicle (<NUM>) which is adapted to connect to the operation server (<NUM>) through the communication system (<NUM>), and which has a self-driving mode for traveling following a predetermined route and a manual driving mode for traveling under user control,
the operation server (<NUM>) comprises:
a route generation part (<NUM>) that generates a plurality of travel routes based on the data in the map database (<NUM>), in response to a dispatch request from a user communication terminal (<NUM>) connected through the communication system (<NUM>), the travel routes include a travel route by manned driving from a pick-up location for a user (<NUM>) associated with the user communication terminal (<NUM>) to a destination location and a return route by unmanned driving from a drop-off location for the user (<NUM>) to a vehicle station; and
a vehicle management part (<NUM>) that monitors a location and status of the vehicle (<NUM>) through the communication system (<NUM>), and
the operation server (<NUM>) is configured to perform a download of the travel routes to the user communication terminal (<NUM>) via the communication system (<NUM>), characterized in that
the operation system has a retrieval support function that, in a case in which the vehicle management part (<NUM>) predicts that the return to the vehicle station will fail while the vehicle (<NUM>) is returning to the vehicle station from the pick-up location via the destination location, includes:
selecting a vehicle retrieval point within a range of a drivable distance of the vehicle (<NUM>) according to the remaining battery power;
generating a retrieval route by unmanned driving to the retrieval point;
calculating an anticipated arrival time at the vehicle retrieval point;
presenting the retrieval route and the anticipated arrival time to an operator (<NUM>) of the operation server (<NUM>); and
transferring, by the operator, the vehicle retrieval point and the anticipated arrival time to a communication terminal (<NUM>) associated with a person (<NUM>) in charge of retrieval of the vehicle.