U.S. patent application number 13/768515 was filed with the patent office on 2013-08-22 for team-oriented human-vehicle interface for adaptive cruise control system and methods for using same.
This patent application is currently assigned to GM GLOBAL TECHNOLOGY OPERATIONS LLC. The applicant listed for this patent is GM GLOBAL TECHNOLOGY OPERATIONS LLC. Invention is credited to Asaf Degani, Claudia V. Goldman-Shenhar, Christopher T. Thibodeau, Omer Tsimhoni.
Application Number | 20130219294 13/768515 |
Document ID | / |
Family ID | 48983327 |
Filed Date | 2013-08-22 |
United States Patent
Application |
20130219294 |
Kind Code |
A1 |
Goldman-Shenhar; Claudia V. ;
et al. |
August 22, 2013 |
Team-Oriented Human-Vehicle Interface For Adaptive Cruise Control
System And Methods For Using Same
Abstract
A team-oriented adaptive cruise control system, for use in
support of operations of a vehicle. The system includes
instructions that cause a processor to perform operations including
communicating, to a human user, via a vehicle-user interface, a
request to participate regularly, actively, and collaboratively as
a member of a collaborative adaptive-cruise-control (ACC) team, to
include the system, in an ongoing team relationship of cooperation
regarding operating the team-oriented ACC system over time. The
operations further include providing, to the user, a commitment
communication advising the user that the system will be dedicated
to participating regularly, actively, and collaboratively as a team
member. The operations also include receiving, from the user, an
agreement communication to participate as a member of the
collaborative ACC team. And the operations include forming,
responsive to receiving the agreement communication, the
collaborative ACC team including the user and team-oriented ACC
system.
Inventors: |
Goldman-Shenhar; Claudia V.;
(Mevasseret Zion, IL) ; Degani; Asaf; (Raanana,
IL) ; Tsimhoni; Omer; (Herzliya, IL) ;
Thibodeau; Christopher T.; (Plymouth, MI) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
GM GLOBAL TECHNOLOGY OPERATIONS LLC; |
|
|
US |
|
|
Assignee: |
GM GLOBAL TECHNOLOGY OPERATIONS
LLC
Detroit
MI
|
Family ID: |
48983327 |
Appl. No.: |
13/768515 |
Filed: |
February 15, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61599521 |
Feb 16, 2012 |
|
|
|
Current U.S.
Class: |
715/751 |
Current CPC
Class: |
G06F 3/0484 20130101;
B60H 1/00757 20130101; B60H 1/0073 20190501; B60H 1/00742
20130101 |
Class at
Publication: |
715/751 |
International
Class: |
G06F 3/0484 20060101
G06F003/0484 |
Claims
1. A team-oriented adaptive cruise control system, for use in
support of operations of a vehicle, comprising: a computer
processor; and a computer-readable medium comprising supporting
information and computer-executable instructions that, when
executed by the processor, cause the processor to perform
operations comprising: communicating, to a human user being a
driver of the vehicle, via a vehicle-user interface, a request to
participate regularly, actively, and collaboratively as a member of
a collaborative adaptive-cruise-control (ACC) team, to include the
team-oriented ACC system, in an ongoing relationship of cooperation
regarding operating the team-oriented ACC system over time;
providing, to the human user, via the vehicle-user interface, a
commitment communication advising the user that the team-oriented
ACC system would be dedicated to participating regularly, actively,
and collaboratively as a team member should the collaborative ACC
team be formed; receiving, from the human user, via the human-user
interface, an agreement communication by which the human user
commits to participating regularly, actively, and collaboratively
as a member of the collaborative ACC team; and forming, responsive
to receiving the agreement communication, the collaborative ACC
team including the human user and the team-oriented ACC system.
2. The team-oriented adaptive cruise control system of claim 1,
wherein the request is a contract including multiple clauses to be
agreed to, including clauses referring to regular, active, and
collaborative participation in activities of the collaborative ACC
team.
3. The team-oriented adaptive cruise control system of claim 1,
wherein forming the collaborative ACC team includes establishing at
least one model selected from a group consisting of: a user model,
the user model being a representation, stored at the team-oriented
ACC system, representing the human user, for use by the system in
performing collaborative functions of the team; a machine model,
the machine model being a representation, stored at the
team-oriented ACC system, representing the system and its control
logic, for use by the system in performing collaborative functions
of the team; an interface model, the interface model, being stored
at the team-oriented ACC system, relating to presentation of the
system to the user team member, for use by the system in performing
collaborative functions of the team; and a mental model, the mental
model being a representation, stored at the team-oriented ACC
system, representing a perspective of the machine from a
perspective of the human user team member, for use by the system in
performing collaborative functions of the team.
4. The team-oriented adaptive cruise control system of claim 1,
wherein the operations further comprise establishing, subsequent to
forming the collaborative team, data items for use as inputs to an
algorithm of the system in making team-based determinations during
operation of the vehicle.
5. The team-oriented adaptive cruise control system of claim 4,
wherein the data items include user preferences.
6. The team-oriented adaptive cruise control system of claim 5,
wherein at least one of the user preferences is communicated
expressly to the system by the user and at least one of the user
preferences is derived by the processor based on user behavior.
7. The team-oriented adaptive cruise control system of claim 1,
wherein the operations further comprise: determining that a person
has entered the vehicle; identifying, using feedback from a vehicle
sensor, the person as the human user team member; receiving a
trigger, following identification of the user team member,
triggering activation of at least one team-based ACC function; and
activating, responsive to the trigger, the team-based ACC
function.
8. The team-oriented adaptive cruise control system of claim 1,
wherein the team-based ACC function includes pre-action
determination processing, comprising collecting relevant data
needed for making a determination on what ACC action to take and/or
how to perform the ACC action.
9. The team-oriented adaptive cruise control system of claim 1,
wherein: the team-based ACC function includes making a
pre-action-determination communication, comprising communicating
with the human user team member; and the pre-action-determination
communication is directed to an entity selected from a group
consisting of: the human user team member; a passenger of the
vehicle; a remote party; and a remote automated device.
10. The team-oriented adaptive cruise control system of claim 9,
wherein the processor, executing the computer-executable
instructions, forms the pre-action-determination communication
based on at least one characteristic selected from a group
consisting of: a timing at which the pre-action-determination
communication is provided; a tone in which the
pre-action-determination is provided; and a substance of the
pre-action-determination communication.
11. The team-oriented adaptive cruise control system of claim 1,
wherein the team-based ACC function includes determining the action
based on data collected in pre-action determination processing
and/or pre-action determination communications, wherein the
determining is performed according to one or more
computational-decision-making algorithms embodied in the
instructions.
12. The team-oriented adaptive cruise control system of claim 11,
wherein: the operations further comprise performing the action
determined; the action comprises transferring control of an ACC
task, either from automatic system control to user manual control,
or from user manual control to automatic system control; and the
computer-executable instructions are configured to cause the
processor to transfer the control in a predetermined manner based
on at least one characteristic selected from a group consisting of:
a timing at which the control is transferred; and a manner by which
the control is transferred.
13. The team-oriented adaptive cruise control system of claim 11,
wherein: the team-based ACC function further includes performing
post-action processing; and the post-action processing includes
establishing, in response to express or inferred concurrence to a
determination basis, the determination basis as a rule for
automatic future use in a similar situation.
14. The team-oriented adaptive cruise control system of claim 11,
wherein: the team-based ACC function further includes making a
post-action communication; and the post-action communication is
directed to an entity selected from a group consisting of: the
human user team member; a passenger of the vehicle; a remote party;
and a remote automated device.
15. The team-oriented adaptive cruise control system of claim 14,
wherein the processor, executing the computer-executable
instructions, forms the post-action communication based on at least
one characteristic selected from a group consisting of: a timing at
which the post-action communication is provided; a tone in which
the post-action communication is provided; and a substance of the
post-action communication.
16. The team-oriented adaptive cruise control system of claim 1,
wherein: the request is a first request and the agreement
communication is a first agreement communication; the operations
further comprise: communicating, to an other entity, a second
request to participate regularly, actively, and collaboratively as
a member of the collaborative ACC team, to include the
team-oriented ACC system and the human user member, in an ongoing
team relationship of cooperation regarding operating the
team-oriented ACC system over time; providing, to the other entity,
the commitment communication advising the other entity that the
team-oriented ACC system is dedicated to participating regularly,
actively, and collaboratively as a member of the collaborative ACC
team; and receiving, from the other entity, a second agreement
communication by which the human user commits to participating
regularly, actively, and collaboratively as a member of the
collaborative ACC team; and the operation of forming the
collaborative ACC team comprises establishing, responsive to
receiving the second agreement communication, the other entity as a
member of the team.
17. The team-oriented adaptive cruise control system of claim 1,
wherein: the system maintains a pre-determined level of system
control vis-a-vis user team member control; and the system includes
or is in communication with a selector by which the user team
member can control the level.
18. The team-oriented adaptive cruise control system of claim 1,
wherein the system is part of a computer device remote to the
vehicle.
19. A tangible computer-readable storage device, for use in
team-oriented adaptive cruise control system in support of
operations of a vehicle, comprising computer-executable
instructions that, when executed by a processor, cause the
processor to perform operations comprising: communicating, to a
human user being a driver of the vehicle, via a vehicle-user
interface, a request to participate regularly, actively, and
collaboratively as a member of a collaborative
adaptive-cruise-control (ACC) team, to include the team-oriented
ACC system, in an ongoing team relationship of cooperation
regarding operating the team-oriented ACC system over time;
providing, to the human user, via the vehicle-user interface, a
commitment communication advising the user that the team-oriented
ACC system would be dedicated to participating regularly, actively,
and collaboratively as a team member should the collaborative ACC
team be formed; receiving, from the human user, via the human-user
interface, an agreement communication by which the human user
commits to participating regularly, actively, and collaboratively
as a member of the collaborative ACC team; and forming, responsive
to receiving the agreement communication, the collaborative ACC
team including the human user and the team-oriented ACC system.
20. A method, for supporting team-oriented adaptive cruise control
operations of a vehicle, comprising: communicating, by a processor
of a tangible automated team-oriented adaptive cruise control
system, to a human user being a driver of the vehicle, via a
vehicle-user interface, a request to participate regularly,
actively, and collaboratively as a member of a collaborative
adaptive-cruise-control (ACC) team, to include the team-oriented
ACC system, in an ongoing team relationship of cooperation
regarding operating the team-oriented ACC system over time;
providing, by the processor of a tangible automated team-oriented
ACC system, to the human user, via the vehicle-user interface, a
commitment communication advising the user that the team-oriented
ACC system would be dedicated to participating regularly, actively,
and collaboratively as a team member should the collaborative ACC
team be formed; receiving, by the processor of a tangible automated
team-oriented ACC system, from the human user, via the human-user
interface, an agreement communication by which the human user
commits to participating regularly, actively, and collaboratively
as a member of the collaborative ACC team; and forming, by the
processor of a tangible automated team-oriented ACC system,
responsive to receiving the agreement communication, the
collaborative ACC team including the human user and the
team-oriented ACC system.
Description
TECHNICAL FIELD
[0001] The present disclosure relates generally to team-oriented
human-vehicle interfaces and system and, more particularly, to
team-oriented human-vehicle interfaces of adaptive cruise control
systems.
BACKGROUND
[0002] Automobiles are becoming increasingly automated. Functions
such as cruise control and anti-lock brakes are all but standard on
most modern vehicles.
[0003] Automated applications of these conventional vehicles are
not programmed to be aware of the user in the control loops of the
system, and so not to react to or consider the user in a
collaborative manner. The applications, rather, operate according
to a uni-directional, supervisory model, wherein the human user is
considered supervisor of the application. The users enter their
input to these applications and then they run as standalone
programs.
[0004] Research reveals numerous historical events and every-day
circumstances that would have been or would be benefitted from a
more-collaborative framework between users and their vehicles. Some
of these instances are safety-related, and some relate more to
convenience, utility, and others.
[0005] In one event, an autopilot system of an aircraft was
programmed to release control to the pilots automatically and
immediately upon a determination that the aircraft steering had
changed by a certain amount. In the unexpected instance, the
autopilot system began auto-steering the craft to counter effects
of ice developing on a wing of the aircraft. Because the system was
not designed with consideration to receiving input from the pilots,
or more importantly in this case, to advising the pilots why
actions were being taken and what actions were planned, likely,
and/or imminent, the flight crew was not aware that the ice was
forming, or that the autopilot was adjusting increasingly craft
steering in compensation.
[0006] When the pre-set amount was reached, the autopilot system,
accordingly to its programming, immediately and without warning
relinquished control. The flight crew, knowing that they were
flying in rough conditions, and following protocol, unexpectedly
needed to deal with a sudden emergency condition. An improved
interface, promoting improved user-vehicle communications, would
avoid such problems.
[0007] On an every-day basis, people use newly-developed in-vehicle
automations. Research has shown that users are adopting many
automations slowly because the users, understandable, do not know
how they work and/or are not comfortable giving up control to the
automation.
[0008] Conventional vehicle automation does not go far, if
anywhere, to explain its behavior, and is generally inconsiderate
of the human state. Therefore, it does not do much to promote
trust, or do well at predicting user behavior or reacting
appropriately.
[0009] In uni-directional interaction, the human also treats the
vehicle as a subordinate, disregarding its physical limitations and
computational needs and constraints.
[0010] There is a need for vehicle systems that are aware of the
user, user desires or preferences, and user needs. The sought
systems would also combine this data with situational awareness to
determine best courses of action and timing, and assist the user in
understanding system operations, trusting the system, and feeling
comfortable with the ongoing user-system relationship.
[0011] The solution involves creating and implementing a
team-oriented, collaborative framework. The solution was created in
part with some consideration given to findings in a variety of
fields of thought, including social science (philosophy, sociology,
social psychology), computer science, artificial intelligence, and
human factors.
SUMMARY
[0012] As referenced, conventional systems are not programmed to
react or to consider their users in a collaborative manner, but
rather according to a supervisory model whereby human users are
considered application supervisors. The user provides input to the
applications, which then run as standalone programs.
[0013] Collaborative applications, operating according to
computational algorithms, perform actions including making
decisions, making recommendations to the user, assisting the user,
acting as a resource for the user, allocating tasks, and scheduling
vehicle activities, with consideration given to the user as a team
member, or peer. The team, or peer group, in one contemplated
embodiment, includes, in addition to the vehicle agent and user
team member (e.g., human driver), one or more other persons or
devices, such as a parent or human supervisor of the driver, a
passenger of the vehicle, or a remote system, such as remote
customer-service center personnel and/or server, as described in
more detail below.
[0014] Other aspects of the present invention will be in part
apparent and in part pointed out hereinafter.
DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 schematically illustrates an on-board computer
architecture, according to an embodiment of the present
disclosure.
[0016] FIG. 2 illustrates in more detail example memory components
of the computer architecture of FIG. 1.
[0017] FIG. 3 shows an exemplary method 300 for forming a
collaborative team, including a user team member account or
profile, and any ancillary accounts and sub-accounts, according to
embodiments of the present technology.
[0018] FIG. 4 shows an exemplary method 400 for determining present
team members for a current vehicle operation within the
collaborative team framework, according to embodiments of the
present technology.
[0019] FIG. 5 shows an exemplary method 500 for performing general
functions of the collaborative team framework, using the team
determined in the method 400 illustrated in FIG. 4, according to
embodiments of the present technology.
[0020] FIG. 6 shows an exemplary method 600 for performing
functions of the collaborative team framework in connection with a
particular, example, application, being an adaptive cruise control
system, according to embodiments of the present technology.
[0021] FIG. 7 shows schematically a model of a collaborative
adaptive cruise control system and select functions associated
therewith called out for description below in connection with the
algorithm of FIG. 6.
[0022] FIG. 8 shows the model of FIG. 7 with the select and other
functions called out for further description below.
DETAILED DESCRIPTION
[0023] As required, detailed embodiments of the present disclosure
are disclosed herein. The disclosed embodiments are merely examples
that may be embodied in various and alternative forms, and
combinations thereof. As used herein, for example, "exemplary," and
similar terms, refer expansively to embodiments that serve as an
illustration, specimen, model or pattern.
[0024] The figures are not necessarily to scale and some features
may be exaggerated or minimized, such as to show details of
particular components.
[0025] In some instances, well-known components, systems, materials
or methods have not been described in detail in order to avoid
obscuring the present disclosure. Specific structural and
functional details disclosed herein are therefore not to be
interpreted as limiting, but merely as a basis for the claims and
as a representative basis for teaching one skilled in the art to
employ the present disclosure.
I. OVERVIEW OF THE DISCLOSURE
[0026] In various embodiments, the present disclosure describes a
team-oriented, collaborative, solution for use in an automotive
context. More particularly, the technology is directed to an
improved autonomous or adaptive-cruise control (ACC) automotive
system.
[0027] A team-oriented human-vehicle interactive system is an
automated system that acts as a team member, collaborating with
other team members toward joint goals. A simple example goal is
parking the vehicle or exiting a highway on which the vehicle is
driving. As described further below, in addition to the human
driver and vehicle agent as team members, the team can include one
or more other persons and/or devices, such as a parent of the
drive, a child of a driver, a tourist (using, e.g., a rental car),
a supervisor of the driver, a passenger of a chauffeured car or
other passenger, a remote system, such as a person or server of a
remote customer-service center with which the vehicle agent team
member communicates, or an application (app), or another in-vehicle
or external system of an infrastructure or another vehicle.
[0028] An example remote customer-service center is the control
center of OnStar.RTM.. OnStar is a registered trademark of the
OnStar Corporation, which is a subsidiary of the General Motors
Company.
[0029] And the vehicle agent team member collaborates with the user
team member. That is the team members work jointly, according to
pre-prescribed protocols, towards a joint, or team, goal.
[0030] The system is computerized, including a processor and a
computer-readable medium having stored thereon computer-executable
instructions that, when executed by the process, cause the
processor to perform the operations of the solution. The system can
be a sub-system of the vehicle, and the computerized aspects
thereof can be, or be a part of, a primary vehicle control
unit--e.g., vehicle electronic control unit (ECU). In one
embodiment, the medium resides on a remote server. Along with the
instructions, or code, the medium can include supporting data, as
described further herein.
[0031] The solution, which is largely software based, defines a
framework for collaborative human-vehicle interactions, between an
automated system of the vehicle and the human, user team member.
Therein, the user team member and vehicle team member interact
repeatedly throughout an ongoing team relationship.
[0032] The system, including the computer-executable
instructions/code, is configured so that the interactions promote
perception, by both the user team member and the vehicle team
member, of the other as part of facilitating and nurturing a
long-term collaborative relationship. User team members and
automated applications are conceived as team members and, as such,
are aware of each other and committed mutually to their
collaborations and support of each other's needs and
preferences.
[0033] To achieve the collaborative, team-based type of
relationship, the automated features provide a team-based
human-machine interface (HMI) and system framework. The team-based
HMI framework includes three modules. The three modules include: 1.
a team-oriented interface module; 2. a machine-and-user
representation model module, including four models relating to the
machine and user; and 3. a team-based computational module.
[0034] Adaptive cruise control (ACC) provides a specific,
automated, aid to driving. The aid is provided along a full speed
range (e.g., from low, traffic, city, or stop-and-go, speeds to
higher, highway speeds), and so can be referred to as full speed
range ACC, or FSR-ACC.
[0035] While the present technology can be applied to a variety of
vehicle sub-systems, the present application is directed to
application of the technology in support o ACC, and more
particularly, in some embodiments, in support of FSR-ACC.
[0036] Other applications for the technology include
implementations with any of the following vehicle sub-systems:
navigation, headlights, other lights, adaptive infotainment
(broadcast radio, satellite radio, digital radio, videos, etc.),
power management, dialogue systems, and parking assist. The
concepts can also be used to provide contextual and personalized
help functions (or, simply, contextual help), including
bi-directional communication supporting help requests and feedback
provision (e.g., help features: electronic user manual and other
help functions, whether driving), and automated driving features
such as automated steering, semi-autonomous driving functions,
lane-centering (LC), lane-changing (LX), and transfer of control
(TOC).
[0037] Other example vehicle systems and sub-systems into which the
present collaborative framework can be implemented include security
(including cyber-security and lock/start/remote interaction with
the car by WIFI/internet/mobile; implementation including
team-oriented communications will increase the trust of the user of
the team and vehicle agent and the vehicle agent will be sensitive
to abnormal requests or events, and communicate with user, etc.
(e.g., police, parent, or other authority), power management
(including fuel efficiency or other fuel-related considerations,
battery state of charge (SOC), environmental considerations, hybrid
vehicle, electric vehicle, or fuel-cell characteristics and
considerations, fuel cell, gear shifts, modes of drive; e.g., the
system can cooperate with the driver to optimize fuel economy
and/or battery state of charge based on user
profile/preferences/path, etc.), environmental considerations
outside of power management, navigation (e.g., based on GPS or
other, e.g., social-media based, vehicle-to-vehicle (V2V)
interaction, relation to land marks such as cell stations or other
infrastructure (V2I)), and management and user interaction with
location-based services (LBS; such regarding stores, services,
coupons).
[0038] Still other example implementations of the present
technology include with systems of sub-systems relating to radio
and other means of entertainment (including or distinct from
infotainment functions), web management (e.g., e-mail,
short-message system (SMS) messaging, social networking and social
interaction), learning systems (e.g., educational system
facilitating user learning about environment, museums, touristic
information), vehicle health management system (VHMS, which can
provide, e.g., warnings, messages to the driver or other interested
parties or devices (e.g., server)), phone, V2V connectivity,
general interaction with vehicle (e.g., relating to operation of
windows, wipers, lights, headlights, tires, engine), radio or other
audio-related settings or preferences, and seat belt operation
(driver and/or front or back-seat passengers).
[0039] In each implementation (i.e., for any of the uses, or
applications, described herein above), the seven (7) teamwork
features (or, collaboration features) of the cooperative HMI
described herein are applied.
[0040] The framework of the present technology includes and uses
certain types of information, including information representing
user-vehicle interactions, important to creating a user-vehicle
agent team for operation of a system, such as the adaptive cruise
control (ACC), or full speed range (FSR) ACC system, of the vehicle
over time.
[0041] While the present technology is described primarily herein
in connection with automobiles, the technology is not limited by
the focus. Rather, it will be appreciated that the concepts, of a
cooperative, team-oriented human-vehicle (or human-machine, or the
like) interface and system, and supporting modules, models, and
encompassing computer-executable instructions or code, can be
extended to a wide variety of applications. The applications
include aircraft, marine craft, manufacturing, education, home
appliances, entertainment, consumer electronics, the like, and
other.
II. FIG. 1
On-Board Computing Architecture
[0042] Turning now to the figures, and more particularly the first
figure, FIG. 1 illustrates a computer 100, such as an on-board
computer (OBC) of a subject, or host vehicle 102, according to an
embodiment of the present disclosure. The OBC 100 can be, or be a
part of, a primary computing unit of the vehicle 102, such as a
primary electronic control unit (ECU) of the vehicle 102.
[0043] The OBC 100 includes a computer-readable storage medium, or
memory 104 and a processor 106 in communication with the memory 104
by way of a data bus 108.
[0044] In various embodiments, the memory is any of a volatile
medium, a non-volatile medium, a removable medium, and a
non-removable medium.
[0045] The term computer-readable media and variants thereof, as
used in the specification and claims, refer to tangible storage
media. The media can be a device, and can be non-transitory.
[0046] In some embodiments, the storage media includes volatile
and/or non-volatile, removable, and/or non-removable media, such
as, for example, random access memory (RAM), read-only memory
(ROM), electrically erasable programmable read-only memory
(EEPROM), solid state memory or other memory technology, CD ROM,
DVD, BLU-RAY, or other optical disk storage, magnetic tape,
magnetic disk storage or other magnetic storage devices.
[0047] The memory 104 includes one or more storage modules storing
computer-readable instructions executable by the processor 106 to
perform the functions of the OBC 100 described herein.
[0048] For instance, the memory 104 includes team-based
vehicle-machine framework modules 110. The memory 104 in some
embodiments also includes ancillary or supporting components 112,
such as additional software and/or data supporting performance of
the methods of the present disclosure.
[0049] The vehicle 102 also includes a communication sub-system 114
for communicating with external devices. The communication
sub-system 114 can include a wire-based input/output (i/o) 116, at
least one long-range wireless transceiver 118, and at least one
short-range wireless transceiver 120. Two other ports 122, 124 are
shown by way of example to emphasize that the system can be
configured to accommodate other types of wired or wireless
communications.
[0050] The vehicle 102 also includes a sensor sub-system 126
comprising sensors providing information to the OBC 100 regarding
items such as vehicle operations, vehicle position, vehicle pose,
and/or the environment about the vehicle 102. The vehicle 102 can
be configured so that the OBC 100 communicates with, or at least
receives signals from sensors of the sensor sub-system 122, via
wired or short-range wireless communication links 116, 120.
[0051] In some embodiments, the sensor sub-system 126 includes at
least one camera 128 and at least one range sensor 130, such as
radar. The camera 128 may include a monocular forward-looking
camera, such as those used in lane-departure-warning (LDW)
systems.
[0052] Such sensor sensing external conditions may be oriented in
any of a variety of directions without departing from the scope of
the present disclosure. For example, cameras 128 and radar 130 may
be oriented at each, or a select, position of, for example: (i)
facing forward from a front center point of the vehicle 102, (ii)
facing rearward from a rear center point of the vehicle 102, and
(iii) facing laterally of the vehicle from a side position of the
vehicle 102.
[0053] Accordingly, the descriptions below, made primarily with
respect to forward-facing sensors, may be applied with respect to
rearward and/or side facing sensors, independently or in
combination with forward-facing sensors.
[0054] The range sensor 130 may include a short-range radar (SRR),
an ultrasonic sensor, a long-range RADAR, such as those used in
autonomous or adaptive-cruise-control (ACC) systems, or a Light
Detection And Ranging (LiDAR) sensor, for example.
[0055] Other sensor sub-systems include an inertial-momentum unit
(IMU) 132, such as one having one or more accelerometers, and/or
other such dynamic vehicle sensors 134, such as a wheel sensor or a
sensor associated with a steering system (e.g., steering wheel) of
the vehicle 102.
[0056] The long-range transceiver 118 is in some embodiments
configured to facilitate communications between the OBC 100 and a
satellite and/or a cellular telecommunications network.
[0057] The short-range transceiver 120 is configured to facilitate
short-range communications, such as communications with other
vehicles, in vehicle-to-vehicle (V2V) communications, and
communications with transportation system infrastructure (V2I).
[0058] To communicate V2V, V2I, or with other extra-vehicle
devices, such as local communication routers, etc., the short-range
communication transceiver 120 may be configured to communicate by
way of one or more short-range communication protocols. Example
protocols include Dedicated Short-Range Communications (DSRC),
WI-FI.RTM., BLUETOOTH.RTM., infrared, infrared data association
(IRDA), near field communications (NFC), the like, or improvements
thereof (WI-FI is a registered trademark of WI-FI Alliance, of
Austin, Tex.; BLUETOOTH is a registered trademark of Bluetooth SIG,
Inc., of Bellevue, Wash.).
[0059] The extra-vehicle, or external, devices to which the OBC 100
can communicate in execution of the functions of the present
technology, can include a remote control center. An example control
center is the control center of OnStar.RTM., having facilities for
interacting with vehicle agent team members and their user team
members via long-range communications, such as satellite or
cellular communications. As provided, OnStar is a registered
trademark of the OnStar Corporation, which is a subsidiary of the
General Motors Company.
III. MEMORY COMPONENTS
FIG. 2
[0060] FIG. 2 shows in more detail the memory 104 of FIG. 1. The
components of the memory 104 are now described further with
reference to the figure.
[0061] III.A. Memory Components
[0062] As provided above regarding FIG. 1, the memory 104 includes
one or more team-based vehicle-machine framework modules 110. And
the memory may also include ancillary components 112, such as
additional software and/or data supporting performance of the
methods of the present disclosure.
[0063] The ancillary components 112 can include, for example, user
and other team-member accounts and profiles, and also pre-agreed
terms of coordination for use, for example, when the user is
irresponsive. The components 112 can also include collaboration
triggers for triggering entering of a collaboration, team-oriented
mode for the vehicle in connection with one or more established
collaboration applications (e.g., team-oriented adaptive cruise
control (ACC) system and team-oriented HVAC system). These and
other data components are described elsewhere, herein, including
below in connection with the methods 300, 400, 500, 600, of
operation.
[0064] As shown in FIG. 2, the modules 110 can include at least
three (3) modules 202, 204, 206, described further in the next
section. In one embodiment, the modules 110 include one or more
additional modules. Some instructions can be part of more than one
module, and functions described herein can be performed by
processor execution of the corresponding more than on module.
Functions described herein, but not in connection expressly with
one of the three modules 202, 204, 206 can be a part of one of the
three modules and/or a part of an additional module 208. The
supporting module(s) 208 can include, for example, a
user-identification module and/or a passenger-identification
module.
[0065] The modules include a team-oriented interface module 134, a
machine-and-user-representation model module 136, and a team-based
computational module 138. Each of these modules is described in
more detail next.
[0066] III.B. Team-Based Modules
[0067] As provided above, to achieve the collaborative, team-based
type of relationship, of the present automotive technology the
automated functions provide a team-oriented, collaborative,
framework. The team-based framework components or modules include
1. a team-oriented interface 202 (FIG. 2), 2. a user-machine
representation models module 204, including four models 210, 212,
214, 216, and 3. a team-based computational module 206.
[0068] The modules are related to the technology in any one or more
of a variety of ways. In one embodiment, one or more of the modules
are components of the computer-executable code or instructions,
described above in connection with the computer or controller
illustrated in FIGS. 1 and 2.
[0069] In one embodiment, one or more of the modules are used in
configuring the algorithm outlining the functions and operations
described herein, including those of the method described below in
connection with FIG. 3. Any function or operation described herein,
for instance, is in some embodiments configured based on one or
more of these modules. This foundational consideration is given by
a designer or maker of the system, by the user team member, and/or
by the vehicle system itself.
[0070] III.B.i. Team-Oriented Interface Module
[0071] The first module 202 (FIG. 2) of the three (3) team-based or
collaborative modules or components referenced above is the
team-oriented interface module. The team-oriented interface (or
TOI), includes any of a wide variety of concepts and interaction
protocols configured to promote collaborative, efficient, and
effective interactions between the user team members (e.g., human
driver of the vehicle and the vehicle system).
[0072] The interactions are configured to allow the vehicle-agent
team member (or VATM) and the user team member (UTM; or user agent
team member (UATM), or the like) to share information and learn
from each other, so they can use the shared information toward
improved, collaborative, team-based operation of the vehicle.
[0073] Example TOI features include or use audio, visual, and
tactile communication hardware, and the supporting protocols. The
TOI hardware includes allows the vehicle agent team member to
communicate messages and inquiries to the user team member, e.g.,
vehicle driver, and to receive comments and inquiries from the user
team member.
[0074] The hardware and supporting protocols include, for instance,
a speaker-microphone system, and underlying protocols, a
display-input system, and underlying protocols, a light-input
system, and underlying protocols, a tactile-feedback system, and
underlying protocols, the like, and other as may be desired by a
designer or maker of the system.
[0075] In a speaker-microphone arrangement, the computer processor
described above, executing computer-executable code embodying
algorithms of the present technology (e.g., a speaker-microphone
interface protocol and the decision-making algorithm), provides
data and questions to the vehicle user team member via a speaker of
the vehicle.
[0076] The content and format of the data and questions are
determined based on operation of the other two primary (2) modules
and, in some embodiments, the additional technology considerations,
including the seven teamwork (7) features (or commitment, or
collaborative features), which can be referred to in other
ways--e.g., data features, algorithm features, components, data
components, attributes, data attributes, attribute data, feature
data, etc., and which are described further below.
[0077] The data and questions are configured, for instance, to
advise the user team member of vehicle agent team member needs,
initiatives, and goals, and possibly reasons for the same. As
described further herein below, the vehicle system uses feedback
received from the user team member via the speaker-microphone
system, and/or other communication channels described herein (e.g.,
touch-sensitive display), in determining which of the user team
member and vehicle agent team member will perform select tasks.
[0078] While the vehicle agent team member may determine initially
that the vehicle agent team member should control performance of an
action automatically, for instance, the vehicle may, based at least
in part on user team member input via the microphone, determine to
allow the user team member to self-control the action. The vehicle
agent team member would in some such cases provide an advance
communication to the user team member of such decision, possibly
advising the user team member of a change in plans based on the
user team member feedback.
[0079] Or, vice-versa--i.e., the vehicle agent team member may
determine initially that the user team member should perform an
action, and then, based at least in part on user team member input
via the microphone, determine that the vehicle should perform the
action automatically. Again, the vehicle agent team member would in
some cases provide an advance communication to the user team member
of such decision, possibly advising the user team member of a
change in plans based on the user team member feedback.
[0080] Similarly, in the converse, the user team member may
initially determine that the user team member will perform an
action, but based on vehicle communication provided to the user
team member via the speaker, determine that it is better for, or
for other reason allow, the vehicle to perform the action. Again,
the vehicle agent team member would in some such cases provide an
advance communication to the user team member of system
acquiescence to the user team member decision, possibly advising
the user team member that the change in plans is based on the user
feedback.
[0081] Completing these example scenarios, the user team member may
initially determine or understand that the vehicle agent team
member will perform an action, but based on vehicle communication
provided to the user team member via the speaker, determine that it
is better for, or for other reason determine, that the user team
member should or will execute the action. And once again, the
vehicle agent team member would in some such cases provide an
advance communication to the user team member of system
acquiescence to the user team member decision, possibly advising
the user team member that the change in plans is based on the user
team member feedback.
[0082] An example action can include any of performing a parking
maneuver, (into or out of a parking place), other
possibly-autonomous driving functions, including switching lanes,
driving to a destination (e.g., home or office), the like or other,
including ACC maneuvers described herein.
[0083] As provided, another input/output configurations can include
a visual sub-system. The visual sub-system can include a display,
such as a display screen, holographic display, etc. The sub-system
can also be configured to receive user team member input, such as
via the display being touch-sensitive--e.g., a touch-sensitive
display screen. The vehicle agent and user team members can
interact via the visual sub-system in generally the same manners
described above in connection with the speaker-microphone
system.
[0084] As also provided, another input/output configurations can
include a light sub-system. The visual sub-system can include one
or more lights, such as light-emitting diodes (LEDs). The
sub-system can also be configured to receive user team member
input, such as via buttons, switches, etc. The vehicle agent team
member and user team member can interact via the visual sub-system
in generally the same manners described above in connection with
the speaker-microphone system.
[0085] In one embodiment, the system includes or is in
communication with a selector (e.g., dial, switch, pull-down menu,
slider, etc. (hardware or displayed via hardware, such as a
touch-sensitive display)) by which the user can control a level of
control, or authority given to the user and/or the vehicle agent
team member. The system can have, for instance, a default setting
of 50/50, or a level of 65% user authority, and the user can adjust
the setting as desired.
[0086] The input/output configurations in one embodiment include
one or more tactile features, such as a tactile-communicating
steering wheel or driver seat. In one example, the vehicle and
agent thereof are configured to provide to the user team member a
tactile signal, such as vibration or slight other movement via the
steering wheel, to advise the user team member of a certain
condition. As with all communications, a tactile communication can
be accompanied by one or more other communications to the user team
member, such as a light indicator illuminating and/or synthetic
voice or other audible message provided to the user team member in
combination with the tactile communication.
[0087] As referenced, the vehicle and agent thereof can be
configured in any of a variety of ways in order to provide and
receive input to/from the human team member. The agent may, for
example, provide a visual inquiry to the user team member, to which
the human team member can reply by voice. The vehicle or agent
designer or maker can implement any such channels of communication,
and combinations thereof for inter-team communications.
[0088] In operation, the team-oriented interface (TOI) generally
acts as a buffer between the vehicle agent team member and the user
team member. In doing so, the TOI facilitates the team, group
process in practice.
[0089] III.B.ii. Models Module, Including Four (4) Models
[0090] The second module 204 (FIG. 2) of the three (3)
above-outlined modules can be referred to generally as a behavior
module. The module includes, or is based on, any of four (4)
supporting models 210, 212, 214, 216 (FIG. 2).
[0091] The behavior module, generally, defines, outlines, and uses
behavior models of both the vehicle agent and user team members.
The models are used in configuring communications to the user team
member, interpreting feedback from the user, and making decisions
based on the algorithms of the present technology in combination
with the consideration given to any user team member feedback and
known underlying user team member expectations and psychology.
[0092] As a general example, while the vehicle agent team member
may otherwise determine that it is best for the vehicle to complete
a maneuver of approaching a destination and parking, based on user
team member feedback and the collaborative principles of the
algorithm, the agent may change the determination to allow the user
team member to perform the task.
[0093] The feedback may include, for example, the user team member
simply saying that the user would like to perform the maneuver, or
the user team member providing more details, such as explaining to
the vehicle that the user team member is not sure on how he/she
wishes to approach the destination, such as that they may want to
see how long a line is outside of a theater before actually
parking, or may wish to, before actually parking, see on a theater
billboard what shows are showing or whether a play is already sold
out, what a price of parking is, whether there is valet, whether an
acquaintance is noticed, etc.
[0094] As described further below, the vehicle system is further
configured to store aspects of such interactions with the driver,
and consider them in future situations. The next time this or
another theater is being approached (e.g., but not necessarily,
while the vehicle is in an autonomous mode), the vehicle may, e.g.,
ask the driver whether they would like, before parking, to ensure
any of these aspects--e.g., the shows playing, the price of
parking, whether there is valet, etc.
[0095] As another example, the vehicle agent team member may
determine initially that the driver should perform a maneuver
manually, such as exiting a crowded highway from a central lane.
The agent may, subsequently, though, based on user team member
feedback and/or agent sensing of present conditions in the vehicle,
determine that the user team member has commenced a phone call and
that it is best for the vehicle to autonomously perform the
maneuver. Again, the vehicle agent team member would in some such
cases provide an advance communication to the user team member of
the vehicle decision, and possibly reasons therefore.
[0096] In a follow-on example, the vehicle system may receive input
from the user advising that the user team member wishes to perform
the maneuver, and may provide supporting details processed by the
vehicle, such as that the user team member phone call is ending
immediately or that the user team member is not actually on the
phone, but rather verbally speaking to a note-taking, transcribing
program, or that a passenger is in a phone call, not the
driver.
[0097] These are just a few of a myriad of scenarios in which the
vehicle and user team member collaborate to determine and execute
best actions.
[0098] III.B.ii.a. Machine Behavioral Model
[0099] The first model 210 (FIG. 2) of the four (4) models, of the
second module 204 of the three (3) collaborative modules for the
present framework, is the machine behavioral model.
[0100] The machine, or behavioral model models the physical machine
and its control logic. The model serves as an input to the
algorithm, which uses it to make control decisions and initiate
automation actions.
[0101] III.B.ii.b. Interface Model
[0102] The second model 212 (FIG. 2) of the four (4) models, of the
second module 204 of the three (3) collaborative modules for the
present framework, is the interface model.
[0103] The interface model relates to the projection, or
presentation, of the machine, as provided to the user team member.
The interface model, in other words, outlines how the vehicle agent
team member presents itself to the user team member.
[0104] The interface model, or vehicle projection, is used as a
basis for user team member interaction and the associated user
interface(s).
[0105] The interface model relates to how the machine explains
itself, through the interface, to the user team member, and
presents the user with information about the machine in an
understandable manner.
[0106] The interface model is not the same as the interface module
(e.g., section III.B.i., herein). Generally, the model relates to
the representation, and the module, including a set of algorithms
and related methods (e.g., in the form of computer-executable
instructions or code) implements the model (representation).
[0107] III.B.ii.c. User Team Member Model
[0108] The third model 214 (FIG. 2) of the four (4) models, of the
second module 204 of the three (3) collaborative modules for the
present framework, is user team member behavioral model, or user
model.
[0109] The user team member model is built, maintained, and updated
by the vehicle agent team member. The model is then considered,
e.g., presented to itself (the machine), in order to best process
user team member input and make determinations with apt
consideration given to the user team member condition--e.g., user
needs, initiatives, goals, feelings, etc.
[0110] More particularly, the vehicle agent team member builds the
user team member model, about behavior of the human user, to
include data points such as user team member characteristics. User
team member characteristics include, e.g., user gender and physical
characteristics, such as user height, weight, etc. The user team
member characteristics can also include user life characteristics,
such as socio-economic status, marital status, other demographics,
the like and other. Embodiments provide the user team member with
control over what user characteristics he/she would like to share
with the vehicle agent team member and would like the vehicle agent
team member to consider in operation of the relationship.
[0111] Still other user team member characteristics that the
vehicle agent team member may include in the representation of the
user team member includes user preferences, moods, and patterns of
behaviors. The vehicle agent team member may determine user team
member preferences and moods, like many other characteristics
described herein, based on one or more historic interactions with
the user team member or other input to the agent indicating user
team member preferences, mood, pattern of behavior, etc.
[0112] In some embodiments, the vehicle uses one or more of the
modules and models described herein in the building, executing
(using), or maintaining (e.g., updating or otherwise adjusting) any
of the other modules or models. In one embodiment, for instance,
the vehicle agent team member uses the user team member model(s) to
build the interface module, described above under section
III.B.i.
[0113] The vehicle agent team member may in so doing, build the
interface module with consideration to ensuring that the interface
module is suitable to the user team member preferences, needs, and
desires. This type of custom building of the algorithm, or data,
protocols, or other factors underlying the algorithm, is provided
with the understanding that each vehicle user team member is
different, and so is best interacted with in a manner custom to
them.
[0114] As another example of one module or model affecting others,
in one embodiment, the vehicle agent team member, in building,
executing (using), or maintaining (e.g., updating or otherwise
adjusting) the computational module, described more below under
Section III.B.iii., the user team member model of present section,
III.B.ii.c.
[0115] III.B.ii.d. Mental Model
[0116] The fourth model 216 (FIG. 2) of the four (4) models, of the
second module 204 of the three (3) collaborative modules for the
present framework, is the mental model.
[0117] The mental model includes, for use by the vehicle agent team
member, a representation of the machine from a perspective of the
user team member. The mental model can be viewed to codify an
image, or operations (initiatives, goals, functions, etc.) of the
system, as the vehicle agent team member understands the same to be
viewed by the user team member.
[0118] As with any of the other models and modules described
herein, the vehicle agent team member in some embodiments builds,
executes (e.g., uses), and/or maintains (e.g., updates or otherwise
adjusts) the mental model. And as in those cases, formation, use,
or maintenance of the user team member model can be in part
affected by user input. In reply to the vehicle communicating an
aspect of the to-them configured user team member model, the user
team member can, for instance, advise the vehicle agent team member
of a misunderstanding or correction needed, and the vehicle agent
team member would amend the user team member model accordingly.
[0119] III.B.iii. Team-Based Computational Module
[0120] The third module 206 (FIG. 2) of the three (3)
above-outlined modules can be referred to generally as the
computational module, or team-based computational module.
[0121] In one embodiment, the team-based computational module
defines or controls how roles amongst team members are allocated.
This can be referred to as a role allocation function. The module
can prescribe, for instance, which roles or tasks are to be
performed by the vehicle agent team member and which by the user
team member.
[0122] For embodiments in which the team includes a remote user or
device, such as a remote customer service system or computer server
(e.g., OnStar.RTM.), the module prescribes which roles are
allocated to it. The system can be configured, e.g., such that
heavy, non-time-sensitive computations, are performed remote to the
vehicle, with results returned to the vehicle.
[0123] Similarly, in one embodiment, the team-based computational
module defines or controls how resource amongst team members are
allocated, used, accessed, and the like. This can be referred to as
a resource allocation function. The module can prescribe, for
instance, which resources are to be maintained by the vehicle agent
team member, and which by a remote team member, such as a remote
team member or server--e.g., OnStar.RTM..
[0124] The system can be configured, e.g., such that large,
cumbersome resources are kept in part or in full remote, and
accessible by or provided to the vehicle. Such provision can be
made according to a push and/or pull arrangement. In an example
push arrangement, the vehicle agent team member receives resource
data automatically, such as in response to a source of the data
(e.g., OnStar.RTM.) determining that a predetermined condition or
trigger exists--e.g., weather-related, date related, time-related,
vehicle location-based. In an example pull scenario, the vehicle
agent team member receives the resource data in response to a
request from the vehicle agent team member for the same (e.g., a
pull scenario).
[0125] In these ways, and/or in any one or more of a number of
other ways, the decision making of the automated partner--i.e., the
vehicle agent team member, is based on collaboration principles. To
the contrary, conventional automated systems are merely
supervisory, whereby users only activate the supervisory system,
and may monitor behavior of the system.
[0126] The team-based human-machine interface is based rather on
mutual commitment, support, and responsiveness of each team member,
human and automated. The collaborative focus includes the vehicle
agent team member being user-aware--i.e., aware of user team member
characteristics, needs, desires, initiatives, preferences, etc.),
the automated system will be aware real-time of their needs and
intentions. Users and machines need a common grounding language and
the automated behavior is based on some human behavioral model to
consider the user in the control loop.
[0127] The module in some embodiments includes an interaction
protocol, or protocol of interaction. The protocol can be generated
and/or include default features, which can or cannot be altered.
The user team member can have input into the formation or
alteration of protocol features, such as selecting from amongst
multiple protocol options presented to the user team member.
[0128] The protocol can control, e.g., who communicates when. As an
example, in one embodiment, the protocol developed or selected,
prescribes that the user team member can communicate to the vehicle
agent team member at any time, and the vehicle agent team member
communicates to the user team member only when the user team member
is not actively communicating to the agent.
[0129] Other example protocol variables includes whether the team
members can communicate offline, whether explicit or implicit
learning is enabled (e.g., whether the vehicle agent team member is
to develop a history and conclusions based on explicit user team
member input to the system and/or implicit input, such as
behaviors, user team member conditions (e.g., talking on the phone
or drinking coffee while driving), etc.
[0130] The vehicle agent team member thus operates as a team
member, and views the user team member (e.g., driver) as a team
member as well. The team makes decisions, and all or most all
decisions are not made by a single member alone without any
consideration for the conditions of the other member(s).
[0131] III.C. Additional Considerations for System Development and
Operation
[0132] The above-described computer-executable code or
instructions, including the three (3) modules described above in
section III.B., are in various embodiments configured to consider
in the algorithms and method of the present technology, any of a
wide variety of supporting concepts.
[0133] The concepts include, generally, the user team member and
the automated suite according to the present technology working
together as a team.
[0134] The concepts considered in the configuration of the code or
instructions include seven (7) teamwork or collaboration attributes
or features associated with developing a team comprised of both a
human and machine agent--i.e., the vehicle. The attributes or
features include 1. commitment, 2. models and transparency, 3.
common language, 4. coordination, 5. responsiveness, 6. intimacy,
and 7. satisfaction.
[0135] Generally, the first, commitment attribute, or feature,
relates to a mutual obligation, on behalf of the user and vehicle
team members, to engage and maintain joint activity toward a joint
goal. The second, models-and-transparency, feature relates to
functions configured to promote understandings, on behalf of the
vehicle and the user team members, of beliefs, intentions, history,
states, and actions of the vehicle agent and the user team
members.
[0136] The third, common-language, feature is configured to best
promote, maintain, and support effective and grounded
communications between the user and vehicle team members. The
fourth, coordination, feature, contributes to joint-planning
efforts, between the user and vehicle team members, and
synchronization of such efforts.
[0137] The fifth, responsiveness, feature promotes respect,
support, and positive reactions on behalf of each of the vehicle
and the user team members with regard to the other. The sixth,
intimacy, feature, further promotes ease and elegance of
communications between the team members (user and vehicle) and more
particularly toward goals of increasing levels of trust and
sensitivity of each member regarding the other. And the seventh,
satisfaction, feature promotes effective uses of the collaborative
system by promoting contentment, reward, celebration, joy,
recognition, and fulfillment in system usage.
[0138] The seven (7) collaboration features, or attributes, are
described in further detail below under the fourth section (IV) of
the present disclosure.
[0139] Considerations used in designing and operating the
computer-executable instructions, including the three (3) primary
modules described above, also include components related to
commitments expected on behalf of the user and the vehicle team
members.
IV. SEVEN (7) TEAMWORK FEATURES
[0140] The disclosure now presents in more detail the seven (7)
attributes or features referenced above under section III,
associated with developing a team comprised of at least the human
user team member and the vehicle agent team member. The teamwork
features, which can also be referred to by other names, such as
collaboration features, commitment features, etc., cover
characteristics determined important to the framework toward
meeting the goals of the present technology.
[0141] Because the seven (7) features are also algorithm and/or
data based in implementation, they can be described as algorithmic
features, data features, algorithm and data features,
algorithm/data features, algorithm and/or data features, the like,
or other without departing from the scope of the present
disclosure.
[0142] While traditionally, authority has been singular, with the
human (supervisor), the present technology is configured away from
unilateral, supervisory, or slave-master formats. The technology,
rather, provides a framework by which the human user and the
vehicle agent are team members, or peers. According to the
framework, decisions as to which team member (user or vehicle) will
have authority over and control any particular action, task, or
activity incorporate a team approach and can, e.g., emanate from a
shared-decision making process.
[0143] IV.A. Mutual Obligation Feature
[0144] The first of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, is mutual obligation. This data
feature prescribes mutual obligations and commitments amongst
respective team members to engage together and work together toward
a joint activity. As provided an example activity is operating the
vehicle, generally or, more particularly, performing a specific
maneuver such as parking the vehicle or exiting a busy highway.
[0145] In one embodiment, the vehicle agent team member is
configured to request, or at least receive, a confirmation or
obligation communication from the user team member indicating that
the user team member will participate in the team relationship. The
confirmation can in some embodiments be an inherent acquiescence,
such as by the user team member interacting ongoingly with the
vehicle agent team member. In one embodiment, the confirmation is
explicit, such as the use team member providing a verbal or
touch-screen `yes` response to a request for confirmation from the
vehicle agent team member.
[0146] In one embodiment, the vehicle agent team member, in
response to determining that a user team member confirmation of
participation exists, creates a team-member profile for the user
team member. The vehicle agent team member populates the profile
with data procured in any of a variety of ways, including from the
user team member explicitly, in response to sensed user actions or
behavior, according to system defaults pre-programmed into the
vehicle agent team member, etc. The vehicle agent team member
maintains the profile over time, such as updating or otherwise
adjusting the profile.
[0147] The profile includes, for instance, any of personal
preferences of the user team member, and demographic information
about the user team member, such as age, gender, weight, height.
Example preferences include music genre preferences, system
operation preferences, such as how the user team member would like
the vehicle team member to act or react in certain situations.
[0148] In one embodiment, the vehicle agent team member, in
response to determining that a user team member confirmation of
participation exists, binds itself to acting jointly with the user
team member, i.e., to the joint activity. In some embodiments, the
vehicle agent team member communicates to the user advising that
the vehicle agent team member considers itself so bound to the team
and its joint activity.
[0149] In one embodiment, the vehicle agent team member, in
response to determining that a user team member confirmation of
participation exists, considers the user team member bound to
acting jointly with the vehicle agent team member. In some
embodiments, the vehicle agent team member communicates to the user
team member advising that the vehicle agent team member considers
the user team member so bound to the team and its joint
activity.
[0150] Once the vehicle agent team member determines that it is
engaged, i.e., engaged in the joint activity, the vehicle agent
team member therein commits to not exiting the venture, such as by
quitting without warning.
[0151] In one embodiment, a level of such commitment is
communicated to the user team member by the vehicle agent team
member. Results of such communication include fostering or
increasing allegiance on behalf of the user to the joint
activities, fostering or increasing trust in the user team member
of the team, the team concept, and of the operations of the vehicle
agent team member toward the team goals.
[0152] As an example of the vehicle agent team member commitment in
operation, in response to the vehicle agent team member determining
that a limit of operation (e.g., a predetermined vehicle speed, or
other operational limit) is reached, the vehicle agent team member
will annunciate such determination, or a result of the
determination (e.g., manual control to be re-instituted
imminently), to the user team member in a timely manner.
[0153] The vehicle agent team member is in some cases configured
to, if the resulting action indeed includes the vehicle agent team
member relinquishing some control, degrade from automatic vehicle
control as gracefully as possible, and with the initial and any
additional feedback or parallel communications to the user agent
team member deemed appropriate by the vehicle agent team
member.
[0154] The team can also be configured to address potential safety
concerns. As an example, and as another example of potential
transfer of control between the user and vehicle agent team
members, consider a situation in which the vehicle agent team
member determines that the user team member is in a detrimental
state, such as being under the influence of alcohol or drugs,
falling asleep, or having a sudden medical attach. The vehicle
agent team member is in some embodiments configured to take any of
a variety of actions in such cases. The actions can include
temporarily exiting the team relationship, and taking supervisory
control at that point, such as to pull the vehicle over to a safe
parking location, to a hospital, etc.
[0155] In one embodiment, the vehicle agent team member is
configured to perform the actions including communicating with one
or more external entities or parties. The external parties can
include, e.g., a parent of the user team member, authorities, such
as the police, hospital, fire department, the like, or other.
[0156] In one embodiment, the vehicle agent team member is
configured to perform the actions including staying in the team
relationship, but taking at least one supervisory-type action, with
less or no consideration being given to the user team member (e.g.,
for the safety of the user).
[0157] IV.B. Models and Transparency Feature
[0158] The second of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to models and
transparency.
[0159] The models and transparency data feature includes two
primary aspects: (1) consideration to a need or desire on behalf of
each team member to understand and appreciate the belief system of
the other of the team members, and (2) transparency and visibility
of the states (or conditions), intentions (or goals), and
computations (or functions or thought processes) of each team
member to the other team member.
[0160] Regarding the first, (1) consideration to a need or desire
on behalf of each team member to understand and appreciate the
belief system of the other of the team member, in one embodiment it
is assumed by the vehicle agent team member, based on the user team
member having committed to the joint activity, i.e., to the team
framework, that the user team member will continuously during
vehicle operation, or at least substantially or generally, be
seeking when able to understand the context from which the vehicle
agent team member operates. The context can include, e.g., the
reasons that the vehicle agent team member does what it does, goals
or initiatives of the vehicle agent team member, needs for
operation of the vehicle team member.
[0161] Moreover as part of the first item, regarding the
consideration toward a need to understand the belief system of the
other member, the vehicle agent team member builds and maintains
(e.g., updates or otherwise adjusts) a model of a context of
operation of the user team member. This model might be extended to
include ontologies--e.g., more general information about the world.
Example user team member context can include user preferences, user
demographics (age, gender, etc.), and historic user behavior (e.g.,
patterns of user actions taken in the vehicle during or outside of
the joint operations). The ontology can include, e.g., weather
conditions, traffic conditions, mass or crowd activity or trends,
geographic location, local events (e.g., concert or sporting
event), local characteristics (e.g., topography), and general human
characteristics, such as an aversion to noises above a certain
decibel level, light above a certain level of brightness, etc.
[0162] Regarding the second item, regarding transparency and
visibility of states, intentions, computations, activities, etc.,
an underlying goal includes promoting trust and candor within the
team and its activities, thereby inhibiting hidden agendas on
behalf of any of the team members. In one embodiment, the vehicle
agent team member receives input from the user team member about a
belief system of the user team member. The input can be express, or
direct, or it can be indirect, or inferred. As an example of
indirect communication, the input can be inferred by the user
giving to the vehicle agent team member permission to be perceived
by one or more sensors, such as a camera, of the vehicle. As
another example of assumed approval, the vehicle agent team member
can infer a belief of the user team member in response to the user
team member reacting to the system, such as continuing to answer
helpfully inquiries provided to the user team member by the vehicle
agent team member.
[0163] Further regarding the second item, regarding transparency
and visibility of states, intentions, computations, activities,
etc., with the underlying goal of promoting trust and candor, in
one embodiment, the vehicle agent team member provides, to the user
team member, information about the configuration or operation of
the vehicle team member. The information can include, e.g.,
information about states of the vehicle agent team member,
intentions of the vehicle agent team member, or explanations about
how the vehicle makes decisions, such as by an explanation about
how the vehicle agent team member will react in certain
circumstances, or why the vehicle agent team member has acted in a
certain manner recently or in the past.
[0164] It will be appreciated that sharing and processing usefully
information about team members is not a trivial task. The task
involves information abstraction, information integration, such as
by integration tools or sub-processes of computer-executable code,
into existing data and algorithm components, and subsequent
interpretation, or understanding, of the new data in combination
with existing algorithms and data.
[0165] IV.C. Common Ground Feature
[0166] The third of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to building, or building
and maintaining (e.g., updating or otherwise adjusting) a common or
basic ground for communications, and shared communication
language.
[0167] In operation, the vehicle agent team member receives from
the user team member, with information indicating how the user
communicates. As an example, the user may advise the vehicle
expressly of a preferred language (e.g., English, French, Spanish),
or indirectly, such as by speaking the language in communicating
with the vehicle agent team member.
[0168] As for its output in this way, the vehicle agent team member
(VATM) communicates to the user team member (UTM) information
regarding preferences of the VATM. The preferences include, e.g.,
data about a VATM optimization scheme, including pre-programmed
preferences. The VATM thereafter communicates with the user team
member in a way that the VATM has determined that the UTM will
comprehend and feel comfortable with.
[0169] IV.D. Coordination Feature
[0170] The fourth of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to coordinating plans
and activities of the team members. The data feature also includes
establishing new automated behaviors.
[0171] In one embodiment, the vehicle agent team member (VATM) is
configured to establish a new automated behavior in any of a
variety of circumstances. An example circumstance includes the VATM
proposing an action (such as that the vehicle automatically turn
off bright headlight and/or turn on fog lights, in response to
determining that the vehicle is driving in the fog), and the user
team member (UTM) agreeing to the proposal. This feature includes
the computational process of arriving at the action, in addition to
executing the action itself. In one embodiment, the VATM is
configured to establish the new automated behavior in such
situation if the UTM does not express disagreement with the
proposed course of action.
[0172] In one embodiment, the VATM is configured to provide to the
UTM pre-generated advice for consideration by the UTM. The advice
may be generated by the VATM and may be stored at the VATM. In one
implementation, the advice is received from a remote source, such
as a remote customer-service center, e.g., OnStar.RTM.. In
operation, the UTM may find such advice persuasive, and alter
his/her behavior, or be influenced to agree to or deny a related
VATM-suggested action. Such automated advice may be especially
informative or persuasive to the user, e.g., when time and/or
information is limited, or when a complexity of a decision that the
UTM is faced with is relatively high.
[0173] The VATM is also configured to take into account a model and
predicted behavior of the UTM. And the VATM is further configured
with data indicating that the UTM will plan and act with
consideration given, or appreciation of, plans and goals of the
VATM.
[0174] This mutual awareness, or coordination, of the team members
leads to a condition whereby partial plans and activities can be
meshed by one or both team members to form sufficiently complete
action decision. And the resulting decision will be holistic,
respectful of the context of the team members
[0175] IV.E. Mutual-Responsiveness Feature
[0176] The fifth of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to a mutual
responsiveness between the user team member (UTM), the vehicle
agent team member (VATM), and any other members.
[0177] The responsiveness includes, on behalf of each team member,
respect for, support of, and responsiveness to the needs and goals
of the other team member. For instance, the VATM conducts its
action while being supportive to the activities and goals of the
UTM. Similarly, the VATM is in some embodiments configured in part
based on an assumption that the UTM will be conducting his/her
actions while being supportive of the activities of the VATM and
responsive to the needs (e.g., information from the UTM) of the
VATM.
[0178] Based on this data and these configurations, VATM can
recognize when the user may be having trouble acting or responding.
The VATM may notice such inconsistency, or abnormalcy, in, e.g., a
delay on the part of the UTM in responding to a trigger or
condition, or a failure of the UTM to take an expected or needed
action. The VATM is configured to, in response to the recognizing
the apparent trouble, take appropriate action, such as communicate
with the UTM regarding the same, perform a supervisory function
(e.g., taking control and parking the vehicle without user input),
or contact a parent or supervisor of the user, contact a hospital,
authorities, etc.
[0179] IV.F. Sensitivity Feature
[0180] The sixth of the seven (7) data features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to promoting a
sensitivity among members of the team to the other member(s) of the
team.
[0181] The sensitivity can be referred to as a social sensitivity,
and the vehicle agent team member configured to consider
sensitivity toward promoting a sense of intimacy within the
team.
[0182] The VATM is in one embodiment configured to be sensitive to
subtleties of the condition or state of mind of the UTM, whether
that state is communicated to the VATM directly, and the VATM is
familiar with operations of the UTM.
[0183] The VATM may use information about a mental state of the UTM
and/or about an interaction style of the UTM toward engendering a
comfortable atmosphere for the UTM.
[0184] The VATM is in one embodiment configured with an
understanding that the UTM will be sensitive to subtleties of the
state of the VATM, whether that state is communicated to the UTM
directly, and that the UTM is familiar with operations of the
VATM.
[0185] The framework is arranged in some embodiments with an
understanding that each team member will attempt to understand and
accommodate the needs and actions of the other in a favorable and
elegant manner. The goal is an overall, team behavior that is
non-fragmented, harmonious, symbiotic, and holistic.
[0186] IV.G. Satisfaction Feature
[0187] The seventh of the seven (7) features, associated with
developing a team comprised of at least the human user team member
and the vehicle agent team member, relates to promoting a sense of
accomplishment.
[0188] The VATM is in one embodiment configured to provide feedback
to the UTM about his/her performance so as to encourage better,
more social-like, interaction.
[0189] The VATM is in one embodiment configured to provide the
feedback so as to encourage a healthy and long-terms relationship
amongst the team members.
[0190] The human acknowledges when the machine performs
satisfactorily, or not (and the machine can take this feedback to
update its model and adjust its behavior accordingly).
V. METHODS OF OPERATION
FIGS. 3-6
[0191] FIG. 3 shows an exemplary method 300 for forming a
collaborative team, including a user team member account or
profile, and any ancillary accounts and sub-accounts, according to
embodiments of the present technology.
[0192] FIG. 4 shows an exemplary method 400 for determining present
team members for a current vehicle operation within the
collaborative team framework, according to embodiments of the
present technology.
[0193] FIG. 5 shows an exemplary method 500 for performing general
functions of the collaborative team framework, using the team
determined in the method 400 illustrated in FIG. 4, according to
embodiments of the present technology.
[0194] FIG. 6 shows an exemplary method 600 for performing
functions of the collaborative team framework in connection with a
particular, example, application, being an adaptive cruise control
system, according to embodiments of the present technology.
[0195] It should be understood that the steps, operations, or
functions of the methods 300, 400, 500, 600 are not necessarily
presented in any particular order and that performance of some or
all the steps in an alternative order is possible and is
contemplated. The methods can also be combined or overlap, such as
one or more steps of one of the methods being performed in the
other method.
[0196] The steps have been presented in the demonstrated order for
ease of description and illustration. Steps can be added, omitted
and/or performed simultaneously without departing from the scope of
the appended claims. It should also be understood that the
illustrated methods 300, 400, 500, 600 can be ended at any
time.
[0197] In certain embodiments, some or all steps of the processes
300, 400, 500, 600 and/or substantially equivalent steps are
performed by a processor, e.g., computer processor, executing
computer-executable instructions stored or included on a
computer-readable medium, such as the memory 104 of the system 100
described above.
[0198] Some or all of the operations are in some embodiments
performed by a processor of a remote machine, such as of another
vehicle, or a remote control center system or server, as referenced
above. For instance, in one embodiment the user team member account
can be created or modified by the user, or supervisor of the user
(e.g., parent or boss), such as via a separate computer (e.g., home
computer) communicating selectively with the vehicle agent team
member and/or a control center server and/or personnel, by such
center or server, etc.
[0199] Aspects of the methods described herein, including rules or
protocols that could underlie the various operations presented, are
in various embodiments configured with consideration given to
(e.g., based on, or relate to) the precepts outlined herein,
including, for example, any combination of the data items described
herein--e.g., any of the seven (7) teamwork or collaboration
features, any of the data outline in connection with the four (4)
team-oriented modules, including the four (4) models therein,
and/or any of the general concepts described further below.
[0200] V.A. Establishing UTM and Related Accounts and
Profiles--FIG. 3
[0201] The method 300 begins 301 and flow proceeds to block 302,
whereat a processor, such as a processor of the vehicle agent team
member (VATM) and/or a processor of a remote device (e.g., e.g.,
server of a remote customer-service center), establishes a user
team member (UTM) account.
[0202] The establishing can include creating or forming the
account, or building the account, selecting the account, such as by
identifying a user of the vehicle to a remote machine already
having an account in connection with the user.
[0203] The UTM account can be stored in the local memory 104, in
full or in part, and/or partially or fully at a remote device, such
as a server of a remote control center (e.g., OnStar.RTM.). In the
local memory 104, the account or parts thereof are in some
embodiments stored in the supporting data component, indicated by
reference numeral 112 in FIGS. 1 and 2, and accessed selectively by
the processor of the vehicle agent team member (VATM)
[0204] In one embodiment, establishing the account includes
receiving user information from the user. The user information can
include a name, name of any other potential drivers of the vehicle,
and other personal information. The user information can also
include preference information, such as about preferences for how
the vehicle should operate--e.g., preferred highway speeds,
in-vehicle temperature(s), radio stations, etc.
[0205] The UTM account can include any of the data described
herein, including UTM feedback to the VATM. The VATM uses the data
in operation of the system, in performance of operations in a
collaborative manner, according to the present technology, as
described above and further below herein.
[0206] Establishing the UTM account in some cases includes
establishing a UTM profile. The profile can include any of the
aforesaid information. In one embodiment, the profile is one part
of the account, and the account includes other, non-profile,
parts.
[0207] In some embodiments, the profile includes, for example,
identifying information (e.g., name, account number, e.g.,
identification for OnStar.RTM.) and preferences received from the
user, such as preferred highway cruise speed, radio and temperature
settings, etc., and the non-profile parts include other data
associated with the user, such as data provided by the UTM to the
VATM during operation of the team framework in preparing to operate
the vehicle and in operating the vehicle.
[0208] The UTM account and/or profile can also include
identification data other than user name. The data can include data
for use in identifying the user when the user enters the vehicle,
such as data indicating fingerprint, weight in seat, eye features
(e.g., iris or retina), voice, breath, etc.
[0209] In one embodiment, the memory of, or used by, the vehicle
agent team member (VATM) includes a identification module.
Operation of the driver identification module is described further
below.
[0210] In establishing the UTM account, or thereafter, the
processor establishes the UTM as a member of a collaborative,
team-oriented/based/focused team including the vehicle agent team
member (VATM). The team formation is indicated in FIG. 3 by
reference numeral 304. The team formation 304 can precede or
include the subsequent team-related functions.
[0211] Forming the team can include other functions, including any
of the related functions described herein. The functions can
include, e.g., requesting and receiving confirmation from the user
of their commitment to participate in the team framework, with at
least the VATM, going forward for operating the vehicle, or at
least an aspect of such operation, such as the adaptive cruise
control, HVAC, navigation, radio, etc. The functions can also
include providing, to the user, a like confirmation that the VATM
will be dedicated or committed to the same.
[0212] As with all aspects of the methods described herein, the
rules or protocols for this part, regarding obtaining and providing
commitments, are in various embodiments configured with
consideration given to (e,g., based on, or relate to) the precepts
outlined herein, including, for example, any combination of the
data items described herein--e.g., any of the seven (7) teamwork or
collaboration features, any of the data outline in connection with
the four (4) team-oriented modules, including the four (4) models
therein, and/or any of the general concepts described further
below.
[0213] Establishing commitments from team members, up front or
initially and again after initiation, has benefits including the
many described throughout the present disclosure. Example benefits
include promoting trust in the team concept and members of the
team, commitment to participate as needed, etc.
[0214] In one contemplated embodiment, the algorithm includes an
operation 306 of establishing, as part of the UTM account or
profile, a sub-account, or sub-profiles identifying likely
passengers of the vehicle. In a particular embodiment, one or more
of the sub-accounts can be indicated and processed as members of
the team, and in another data associated with one or more such
sub-accounts is considered in performance of the team framework
without the sub-accounts being considered as members of the
team.
[0215] The sub-account/sub-profile can be built and maintained in
many of the ways that the UTM account/profile for a driver can be.
The corresponding data can include, e.g., name, other personal and
demographic data, preferred radio stations, preferred radio volume,
preferred temperature, whether the passenger is likely to be a
front-seat passenger and/or rear-seat passenger, etc.
[0216] In a particular embodiment, the VATM considers at least one
passenger as part of the team including the VATM and the driver
UTM, and so considers input from the passenger. In another
embodiment, the VATM does not consider the passenger as a part of
the collaborative team, but does consider input from, or previously
established data relating to, the passenger in making one or more
VATM decisions.
[0217] For cases in which the passenger is to be considered a part
of the team, the processor takes appropriate team-formation steps,
such as any of the related functions described herein. Example
steps include, as provided, e.g., requesting and receiving
confirmation from the passenger of their commitment to participate
in the team framework for the vehicle, with at least the VATM and
UTM, going forward in connection with ongoing operations of the
vehicle, or at least an aspect of such operation, such as the
adaptive cruise control, HVAC, navigation, etc. The functions can
also include providing, to the passenger to have a passenger team
member account associated with them in the system, a like
confirmation that the VATM will be dedicated or committed to the
same.
[0218] Again, establishing commitments from team members, up front
or initially and again after initiation, has benefits including the
many described throughout the present disclosure. Example benefits
include promoting trust in the team concept and members of the
team, commitment to participate as needed, etc.
[0219] The memory of, or used by, the VATM in one embodiment uses
the same identification module referenced above to identify a
passenger, and in another the memory of, or used by the VATM
includes a separate passenger identification module for use in
identifying one or more passengers.
[0220] In one embodiment, a second driver UTM account or profile is
maintained for a person other than that associated with the first
UTM. In some instances, a likely passenger is also sometimes a
second driver of the vehicle (e.g., a spouse). For such cases, the
VATM can be configured to link the passenger account/profile
associated, who is also sometimes a driver, with a second UTM or
profile for that person. Thus, data of the passenger account for
that person can be imported or pulled from the passenger account in
establishing, maintaining, or using the second UTM, and vice
versa--i.e., data for the second UTM can be used in establishing,
maintaining, or using the corresponding passenger account.
[0221] At operation 308 of the algorithm 300, the processor (e.g.,
VATM processor) establishes as a member of the team one or more
other parties. As described elsewhere herein, the other team
members can include, beyond passengers, a parent of the UTM driver,
a supervisor of the UTM driver, a remote device, or such as a
remote customer service system or server (e.g., OnStar.RTM.). The
other team members can also include authorities, such as police,
transportation authorities, environmental authorities (e.g., EPA),
traffic-related entities, weather-related service providers, etc.
In some embodiments, the VATM is configured to consider input from
any of such parties or entities, without considering the party or
entity as a part of the collaborative team.
[0222] For cases in which the additional party (e.g., parent) or
entity (e.g., traffic authority) is to be considered a part of the
team, the processor takes appropriate team-formation steps, such as
any of the related functions described herein. Example steps
include, as provided, e.g., requesting and receiving confirmation
from the party or entity of their commitment to participate in the
team framework for the vehicle, with at least the VATM and UTM,
going forward in connection with ongoing operations of the vehicle,
or at least an aspect of such operation, such as the adaptive
cruise control, HVAC, navigation, etc.
[0223] The functions can also include providing, to the party or
entity to have a party/entity team member account associated
therewith, a like confirmation that the VATM will be dedicated or
committed to the same. As referenced, establishing commitments from
team members, up front or initially and again after initiation, has
benefits including the many described throughout the present
disclosure. Example benefits include promoting trust in the team
concept and members of the team, commitment to participate as
needed, etc.
[0224] In addition to obtaining commitments to the team, and joint
activity, from each team member, at operation 310, the processor,
in connection with each team member, further establishes rapport
and common ground with each member.
[0225] Establishing further rapport and common ground includes, in
some embodiments, establishing preferred communication styles of
the VATM, the UTM, and any other team members or team contributors
(e.g., weather or traffic server). Establishing communication
preferences or standards can involve variables such as language,
values, voice-type, volume, number of repetitions or reminders,
timing of notifications, rate of communication (e.g., text or
audio), the like, and other.
[0226] Preferences can include a UTM preference for channel or
modality by which to receive notifications, such as via a display
screen, speaker, tactile seat or steering wheel, etc. The
preferences can identify one or more channels for some situations,
e.g., types of communications, and one or more other channels for
other situations.
[0227] In establishing the rapport and common ground, VATM default
settings may have priority over a requested or suggested UTM
preference. The UTM may propose, for instance, that the VATM
provide an alertness test communication, to see if the driver is
alert while driving, only via a visual display; but a VATM default
setting requiring, e.g., that such alerts be provided by audible
communication, or audible and tactile communication, may take
precedent for safety reasons, to accommodate the possible scenarios
in which the alertness test may be needed.
[0228] The rules or protocols for this part, regarding establishing
rapport and common ground, are in various embodiments configured
with consideration given to (e.g., based on, or relate to) the
precepts outlined herein, including, for example, any combination
of the data items described herein--e.g., any of the seven (7)
collaboration features, any of the data outline in connection with
the four (4) team-oriented modules, including the four (4) models
therein, and/or any of the general concepts described further
below.
[0229] The rules or protocols, here regarding building rapport and
common ground, can be based or relate, for instance, at least in
part on the data items relating to efficiency and effectiveness of
communications, building confidence in the team and the VATM,
mutual respect, intimacy, satisfaction, and healthy, effective, and
efficient feedback loops.
[0230] The method 300 can be repeated or end 311.
[0231] V.B. Determination of Collaborative Team--FIG. 4
[0232] As provided, FIG. 4 shows a method 400 for performing
general functions of the collaborative team framework, according to
embodiments of the present technology.
[0233] The method 400 begins 401 and flow proceeds to operation
402, whereat a processor, executing a driver identification module,
identifies a driver who has entered the vehicle. The identification
can use any of a variety of vehicle sensors, which may be
considered a part of or in communication with the VATM, such as a
camera, a proximity sensor, a weight sensor, iris/retina scanner,
breath sensor, etc.
[0234] As described above, driver identification can be performed
using data provided by the person, such as their name, and perhaps
also a password, pass code, or other authenticating data. The
identification can also or instead be based on driver physical
characteristics such as voice, weight, iris or retina
characteristics, etc.
[0235] Flow of the algorithm proceeds to operation 404 whereat the
processor accesses the user team member (UTM) account and profile
associated with the driver identified. As provided above, the
account and profile can reside in the supporting data indicated by
reference numeral 112 in FIGS. 1 and 2.
[0236] Flow of the algorithm proceeds to decision diamond 406
whereat the processor determines whether there are any passengers
in the vehicle. The determination can be based on input from the
UTM and/or from feedback from one or more sensors. As provided, the
sensors can include a weight sensor, a voice sensor, a camera, an
iris/retina scanner, etc.
[0237] In response to a positive determination at decision 406,
i.e., a passenger is determined to be in the vehicle, flow proceeds
to operation 408 whereat the processor determines whether a
passenger account exists. If not, the method may include inquiring
of the UTM driver whether they would like to establish a passenger
account.
[0238] In establishing the passenger account, the processor can
determine whether the passenger account is to be linked to an
existing other UTM account associated with the passenger, and
linking the two accounts if so, which can include the functions of
operation 306, referenced above in connection with FIG. 3.
[0239] The operation 408 can further include determining whether
such passenger user account, whether pre-established or presently
established, is or should be stored in the system as a team-member
account. If not, data associated with the passenger (e.g., radio
volume preferences, temperature preferences), can still be
considered in the collaborative operation of the vehicle, though
the passenger is not considered a team member. A distinction would
be that the processor (e.g., VATM processor) would not regularly,
or as frequently, consider the preferences, data, or needs about,
of, or from the passenger, provide information to the passenger,
request or receive input from the passenger regarding team-related
functions, and/or other.
[0240] Operations 406 and 408 are performed with respect to each
passenger.
[0241] Following operation 408, or in response to a negative
determination at operation 406, flow of the algorithm proceeds to
decision diamond 410, whereat the processor determines whether
there are any other accounts associated with the UTM. As referenced
above, such other accounts can include a present or non-present
parent account, a supervisor account, a governmental authority or
agency, a remote service center server (e.g., OnStar.RTM.), the
like, or other. The other accounts can thus include persons and/or
automated devices.
[0242] The operations 410, 412 can include functions like those of
steps 406, 408, but with respect to the one or more other accounts.
The operations 410, 412 can include, e.g., determining whether the
other account(s) is established or should be established and linked
to the UTM account, and whether the account(s) is or should be
considered as a member of the UTM-VATM collaborative team. And even
it is not, the processor (e.g., VATM processor) can still consider
input from the associated entity/ies, whether requested or pushed
to the processor, in performance of the team functions.
[0243] As with non-team-member passenger accounts vis-a-vis
team-member passenger accounts, one difference, between a
non-team-member other-entity account and a team-member other-entity
account, would be that the processor (e.g., VATM processor) would
not regularly, or as frequently, consider preferences, data, or
needs of, about, or from the other entity, provide information to
the other entity, request or receive input from the other entity
regarding team-related functions, and/or other.
[0244] The method 400 can be repeated or end 413.
[0245] V.C. Operation of Collaborative System--FIG. 5
[0246] As provided, FIG. 5 shows an exemplary method 500 for
performing general functions of the collaborative team framework,
using the team or participating team members determined in the
method 400 illustrated in FIG. 4, according to embodiments of the
present technology.
[0247] The method 500 begins 501 and flow proceeds to decision
diamond 502, whereat the processor determines whether a
collaboration trigger has occurred. The collaboration trigger can
include, for instance, determining that a driver of the vehicle has
indicated a desire to enter a collaboration vehicle mode. As
provided the driver may have already been identified by the vehicle
agent team member (VATM) as being associated with a user-team
member (UTM) account.
[0248] The vehicle and VATM thereof can be configured to receive
such indication from the driver in any of a variety of ways, such
as via a collaboration, or team-function hard button or switch, via
a voice detection and interpretation sub-system (e.g., the
microphone-speaker system), or a touch-screen button or other
indicator. Any of the triggering interfaces (camera, microphone,
button, switch, etc.), as with any interface described herein, can
be considered one of the components linked to processor in the
schematic illustration of FIG. 1.
[0249] In one embodiment, the collaboration trigger includes simply
starting a motor or engine of the vehicle, or just powering on the
vehicle such as by turning the key to an on position.
[0250] The collaboration trigger can be associated with all
team-based applications of the vehicle or just one or more
established team-based applications. The association can be
determined by the VATM in any of many ways, such as according to a
default rule, a preference pre-set by the user to the VATM (e,g.,
always upon initial trigger (e.g., vehicle start, or collaboration
button press) launch collaboration mode for all established
team-based applications, or rather for just pre-identified
applications, such as just for a team-oriented adaptive cruise
control (ACC) system and/or a team-oriented HVAC system.
[0251] Another example collaboration trigger is a triggering signal
received at the processor (e.g., VATM or remote service center
processor). The triggering signal can be received, e.g., at the
VATM processor from a server or other computer of a remote service
center (e.g., OnStar.RTM.), or from computer or other automated
system (E.g., phone system, smart-phone application, etc.), such as
from a parent or supervisor of the driver associated with the
UTM.
[0252] In one embodiment, the collaboration trigger includes a
triggering condition. An example triggering condition is a location
of the vehicle, such as the vehicle being near home, away from a
home area (e.g., home metropolitan area), on the highway, in the
city, etc.
[0253] Another example triggering condition is a vehicle-operation
condition. The vehicle-operation condition can be, for instance,
the vehicle being driven at a certain speed, cruise-control being
activated, HVAC being activated, the radio being activated, the
like, or other. In one embodiment, the VATM is configured so that a
certain vehicle-related condition triggers activation of only a
certain one or more team-oriented applications.
[0254] The UTM activating cruise control can, for example, be a
vehicle-operation condition triggering the collaboration mode with
respect to only the team-oriented ACC system (or, TOACC system, or
TOACCS) and a team-oriented navigation system. Similarly, the UTM
activating or adjusting the vehicle HVAC can be a vehicle-operation
condition triggering the collaboration mode with respect to only
the team-oriented HVAC, or of the TOHVAC along with one or more
other team-oriented applications.
[0255] Responsive to a negative determination at decision 502,
e.g., a collaborative trigger is not determined present at the
time, flow can return along path 503 to re-performing the decision
502, or flow of the algorithm can hold at the step 502 until a
trigger is determined present
[0256] Responsive to a positive determination at decision 502, the
VATM at operation, or routine, 504 enters the collaboration mode in
connection with the one or more respective vehicle application
associated with the trigger, as described above.
[0257] In the collaboration mode, flow of the algorithm proceeds to
operation, or sub-routine 506 whereat the processor performs one or
more collaborative functions, and related pre- and
post-communications and processing.
[0258] It is noted, as an aside, that some collaborative functions
are not viewed as relating to a corresponding or analogous
non-collaboration function, while some collaborative functions can
be seen as related to a corresponding or analogous
non-collaboration function. For instance, a collaborative function
of determining whether and how much to accelerate the vehicle for a
highway passing maneuver can be viewed as related to a
non-collaborative function performed by conventional vehicles of
accelerating in a passing maneuver.
[0259] The non-collaborative passing maneuver can include, e.g.,
the driver causing acceleration by pressing harder on the gas or
acceleration pedal, or pressing a cruise-control acceleration
button or switch. Performance of a collaborative function is
generally different than performance. For the most part,
collaborative functions differ in one or more ways from any
non-collaborative analogy.
[0260] The operation or routine 506 of performing one or more
collaborative functions can include a plurality of sub-operations
or sub-routines. In various embodiments, the sub-routines include
any of the following six (6) sub-routines: (i)
pre-action-determination processing (508 in FIG. 5), (ii)
pre-action-determination communications (510), (iii) action
determination (512), (iv) action execution (514), (v)
post-action-execution communications (516), and (vi) post-action
execution processing (518). Each of these routines are described
further below in turn.
[0261] V.C.i. Pre-Action Determinations and Processing
[0262] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 508 of
collecting and using data need to identify what action or actions
should be taken, and how, in connection with the one or more
applications for which the team mode is activated.
[0263] The VATM is configured (e.g., computer-readable code
outlining aspects of the algorithm is such) to based on its
programming determine actions needed, and how the actions should be
performed, based on data such as UTM preferences, VATM preferences
or defaults, UTM input, vehicle conditions, vehicle location, and
data related specifically to the application(s) for which the
vehicle is in team mode.
[0264] Relevant data can include historic data regarding team
performance. Historic data includes, e.g., previous decisions made
by the user in the same, similar, or related circumstances.
[0265] Relevant data can also include, for instance, a current
temperature of the vehicle and UTM-preferred temperature of the
vehicle in connection with team-oriented HVAC. Regarding
team-oriented ACC, the relevant data can include, e.g., an
indication that the vehicle is on the highway with no traffic
(e.g., using location data, traffic data, vehicle proximity
sensors, inter-vehicle data, etc.), a current speed of the vehicle,
and a UTM preferred on-highway/no-traffic speed.
[0266] The VATM may according to its programming determine that
data is needed from the UTM or other team member. The VATM requests
such data or otherwise operates to obtain the data needed. The VATM
may, for instance, require or recognize as helpful (e.g., desire)
data from the driver, such as a target goal, whether the user would
like to pass a vehicle being approached in a center lane of the
highway, whether the user would like the vehicle parked, etc. In
that case, the VATM would communicate a request for the data to the
user, such as via the vehicle speaker or display system referenced
above.
[0267] The required or desired data can also be that accessible
from another entity or party, such as a weather service, a traffic
authority, or a parent of the driver. As provided above, such
entity or party may or may not be a member of the team. The
processor proceeds to operate toward obtaining the needed data.
[0268] The pre-action determinations and processing can also
include updating system data, such as user or system preferences,
or system models (e.g., user model, mental model, etc.).
[0269] V.C.ii. Pre-Action Communications
[0270] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 510 of
performing pre-action communications.
[0271] In addition to any of the communications described in the
immediately preceding sub-section, the VATM here may initiate or
otherwise participate in communications with one of the team
members. Some communications can be considered as falling under
this pre-action communications sub-routine and also under the
previously-described pre-action determinations sub-routine.
[0272] According to one embodiment, these communications are
focused on providing polite advance notice to the UTM of an action
determined to be taken. The VATM may determine tentatively an
action to take or determine finally an action to take. The VATM can
communicate whether the determination is tentative, e.g., a
proposed or suggested course of action, or supervisory.
[0273] As an example of a suggestion, the VATM may propose to the
UTM that the VATM cause the vehicle to perform an action such as
initiating passing of a vehicle being approached, or advise that
the VATM will do so (e.g., to maintain generally a consistent set
speed) unless the user would prefer not to, etc.
[0274] As an example of a supervisory communication, the VATM may
advise the driver that the VATM is or will be initiating a slowing
and parking maneuver, such as may be called for in an emergency
situation within the vehicle, such as based on a determination that
the driver is inebriated or experiencing a sudden medical
episode.
[0275] The communications can include the processor receiving an
inquiry from the UTM. For example, the UTM may enquire, "how do I
get closer to the vehicle in front of me?" Or advise, "in such
turns, I would like to take manual control."
[0276] Or the VATM may enquire, e.g., "would you prefer to take
manual control in the next segment?" Or advise, "my sensors are
having some trouble, please continue manually." Or advise, "you are
driving faster than your set speed; in case you want to resume,
please say or press resume."
[0277] In some embodiments, the VATM is programmed to, as part of
pre-action communications, communicate with entities or parties
other than the driver. Example parties include a passenger, a
traffic authority, parent, police, hospital or other medical
entity, etc. As provided, such entities and parties may or may not
be members of the collaborative team.
[0278] The VATM is further programmed so that, in communications to
the team members, the VATM uses rules or protocols prescribing
pre-sent manners of communication. As provided herein, the VATM
preferably communicates in ways--e.g., timing, tone, and
content--that is respectful, socially pleasing or pleasant,
intimate, rather than coarse, etc. The rules or protocols are in
some embodiments programmed into the VATM by a designer or maker of
the VATM system, or vehicle on a whole.
[0279] As with all aspects of the methods described herein, the
rules or protocols for this part are in various embodiments
configured with consideration given to (e.g., based on, or relate
to) the precepts outlined herein, including, for example, any
combination of the data items described herein--e.g., any of the
seven (7) collaboration features, any of the data outline in
connection with the four (4) team-oriented modules, including the
four (4) models therein, and/or any of the general concepts
described further below.
[0280] The rules or protocols, here regarding pre-action
communications can be based or relate, for instance, at least in
part on the data items relating to building trust, mutual respect,
transparency, responsiveness, established and agreed-upon
communication and language preferences and protocols, and healthy,
effective, and efficient feedback loops.
[0281] The rules or protocols here can call out timing, such as
providing information to the UTM relatively well in advance of the
action to be taken, or with as much time as reasonable and possible
to allow the UTM to provide feedback, such as a reply communication
agreeing to or disagreeing with a VATM proposal or inquiry.
[0282] The rules or protocols, depending on the circumstances, can
include one or more reasons explaining to the UTM basis(es) for
VATM determinations. The explanation can include support for a
presented proposal--e.g., "passing the vehicle being approached on
the right is proposed because your exit is coming up in one mile."
Or the explanation can relate to road conditions, weather, etc.
[0283] The rules or protocols, here regarding pre-action
communications can again be based or relate, for instance, at least
in part on the data items relating to building trust, mutual
respect, transparency, responsiveness, intimacy, satisfaction, and
healthy, effective, and efficient feedback loops.
[0284] The rules or protocols also can prescribe that the VATM
communicate with the UTM in an appropriate tone. The tone in some
embodiments, is preferably generally or usually gentle or gentile,
but can be more direct based on the circumstances, such as if
determined needed to gain the attention of a driver who is
apparently drowsy or experiencing some sort of medical episode
resulting in delayed UTM response.
[0285] V.C.iii. Action Determination
[0286] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 512 of
determining the action. The determination 512 is based on the data
collected in the pre-action determinations and communications, the
processor (e.g., VATM or other processor) determines how to perform
one or more pre-determined actions. Some computation may be done
off line and some online.
[0287] The VATM may in this operation 512 consider feedback from
the UTM, other members, or other parties or entities, in
determining whether an initial or preliminary action, whether
presented to any such parties, should be a final action. For
instance, the VATM may in the first sub-routine 508 determine to
propose to the UTM to pass another vehicle being approached on the
right of the vehicle, in the second sub-routine 510 communicate the
proposal to the UTM and receive a disagreeing reply, or counter
instruction or suggestion, from the UTM indicating that the user
would like to pass on the right. Here in the action determination
sub-routine 512, the processor thus considers the feedback and
supporting data (e.g., vehicle spacing, navigation data indicating
the approaching exit, etc.) and determines how to pass or even
whether to pass.
[0288] As with all aspects of the methods described herein, the
rules or protocols for this part, regarding action or function
determination, are in various embodiments configured with
consideration given to (e.g., based on, or relate to) the precepts
outlined herein, including, for example, any combination of the
data items described herein--e.g., any of the seven (7)
collaboration features, any of the data outline in connection with
the four (4) team-oriented modules, including the four (4) models
therein, and/or any of the general concepts described further
below.
[0289] The rules or protocols, here regarding action or function
determination can be based, for instance, at least in part on the
data items relating to building trust, mutual respect, and shared
authority. The decision is of course also based on safety
considerations when appropriate.
[0290] The VATM can, in any event, explain the final decision in
the post-action communication sub-routine 516, described further
below.
[0291] V.C.iv. Action Execution
[0292] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 514 of
executing or performing the action, or function.
[0293] As referenced above, the processor can determine that more
than one collaborative function or action should be performed
sequentially or in parallel, or some sequentially and some in
parallel or generally simultaneously.
[0294] V.C.v. Post-Action Communications
[0295] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 516 of
participating in post-action communications.
[0296] As provided, the VATM is programmed to, in circumstances
that are deemed appropriate according to the algorithm,
user-preferences, or other basis, to communicate with the UTM or
other entities at any time, including during or after action
performance.
[0297] The communication can explain to the UTM, for instance, a
level of success of the action (e.g., "because that vehicle
unexpectedly braked, we ended up closer than desired to them in the
passing maneuver"), proposals for the future (e.g., "next time
we'll be more conservative"), inquiries of the UTM (e.g., "was that
a pleasant maneuver for you" or "did you like the way we performed
that (xyz) maneuver?"), etc.
[0298] The communications can include, e.g., the VATM advising the
UTM, "you approached the car in front of us too quickly."
[0299] The VATM can also provide communications to appropriate
entities or other parties, whether team members, such as a parent,
a school, a traffic authority, etc. (e.g., advising a parent that a
high school student's vehicle has been parked at school, advising a
hospital that a vehicle of a UTM having a medical emergency has
been pulled over and parked, and where, or is on its way to the
nearest hospital, etc.)
[0300] The communications can include the VATM receiving feedback,
instructions, or inquiries from the UTM, or other party or entity,
and responding accordingly.
[0301] The rules or protocols for this part, regarding post-action
communications, are in various embodiments configured with
consideration given to (e.g., based on, or relate to) the precepts
outlined herein, including, for example, any combination of the
data items described herein--e.g., any of the seven (7)
collaboration features, any of the data outline in connection with
the four (4) team-oriented modules, including the four (4) models
therein, and/or any of the general concepts described further
below. The rules or protocols, here regarding post-action
communications can be based or relate, for instance, at least in
part on the data items relating to building trust, mutual respect,
transparency, responsiveness, intimacy, satisfaction, established
and agreed-upon communication and language preferences and
protocols, and healthy, effective, and efficient feedback
loops.
[0302] The rules or protocols also can prescribe that the VATM
communicate with the UTM in an appropriate tone. The tone in some
embodiments, is preferably generally or usually gentle or gentile,
but can be more direct based on the circumstances, such as if
determined needed to gain the attention of a driver who is
apparently drowsy or experiencing some sort of medical episode
resulting in delayed UTM response.
[0303] V.C.vi. Post-Action Processing
[0304] As part of the operation 506 of performing one or more
collaborative functions, the processor performs an operation 518 of
performing processing after the determined collaboration function
or action is taken.
[0305] The processing in one embodiment includes establishing a
user decision or instruction for future use in like circumstances.
If the user, for instance, suggested, requested, or agreed to
perform a certain action, such as parking backward in a parking
place, the VATM will remember the maneuver as a preference for
parking. The preference may be qualified, such as by a location, a
time, relation to an event, etc.--for example, the vehicle may be a
police vehicle and the UTM, the office, and the maneuver remembered
as a preference being to park backward when parking at the police
station in the morning or during the day.
[0306] In one embodiment, the VATM advises the UTM of some or all
such new preferences being or having been stored. In a particular
embodiment, the VATM advises the UTM that the new preference will
be stored unless the UTM disagrees. Making new preferences, or
amending a preference, as such can be referred to as adapting, or
an adaptation function.
[0307] This arrangement, whereby new proposed preference presented
by the VATM will become a stored new preference unless the UTM
communicates disagreement, can also be a system default. In this
case, the VATM would not need to remind the UTM in connection with
each new preference being stored that the user can provide a veto.
Such default setting can be communicated to a user with other
commitments, communication bases, etc.
[0308] The rules or protocols for this part, regarding post-action
processing, are in various embodiments configured with
consideration given to (e.g., based on, or relate to) the precepts
outlined herein, including, for example, any combination of the
data items described herein--e.g., any of the seven (7)
collaboration features, any of the data outline in connection with
the four (4) team-oriented modules, including the four (4) models
therein, and/or any of the general concepts described further
below. The rules or protocols, here regarding post-action
communications can be based or relate, for instance, at least in
part on the data items relating to building trust, mutual respect,
transparency, intimacy, satisfaction, and healthy, effective, and
efficient feedback loops.
[0309] The post-action processing can also include updating system
data, such as user or system preferences, or system models (e.g.,
user model, mental model, etc.).
[0310] Flow of the algorithm proceeds to repeat acts, as indicated
by arrow 520, or proceeds to repeat the entire method or to end
521.
[0311] V.D. Operation of Collaborative ACC System--FIG. 6
[0312] As provided, FIG. 6 shows a method 600 for performing
functions of the collaborative team framework in connection with a
particular, example, application, being an adaptive cruise control
system, according to embodiments of the present technology.
[0313] Before describing the method in detail, some general aspects
of the method are described. As provided adaptive cruise control
(ACC) provides a specific, automated, aid to driving. The aid is
provided along a full speed range (e.g., from low, traffic, city,
or stop-and-go, speeds to higher, highway speeds), and so can be
referred to as full speed range ACC, or FSR-ACC.
[0314] Conventional ACC systems are not aware of its user, do not
react to road conditions, traffic, and do not alert the user based
on real-time situations and personal driving patterns of the user.
Conventional ACC has a constant behavior pattern, reacting to all
users and settings in the same way. These characteristics lead to
user confusion, uncertainty, and reduced use of ACC.
[0315] The team-oriented ACC on the other hand is collaborative.
Collaboration is achieved by allowing and promoting bi-directional
communications between at least the driver (UTM) and the VATM. The
collaboration is promoted by transparency of critical values
between the team members, and by adapting team-oriented ACC
behavior to repetitive patterns of driver behavior.
[0316] The collaboration also includes adaptation. Adaptation is
achieved by collecting information on UTM settings and situational
conditions--e.g., road conditions, location, weather. Particular to
team-oriented ACC also include processing gap settings and speed
values, which can be adjusted to keep the user driving without
disengaging the system. A gap setting is a setting indicating a
preferred, desired, or required gap distance between the subject
vehicle and nearby vehicles--e.g., a leading vehicle or a trailing
vehicle. These and related aspects are described further below.
[0317] The VATM maintains a model of constraints it encounters,
e.g., as a result of traffic, road conditions and the speed and gap
values set by the driver. The VATM system behavior is configured to
be responsive to UTM requests and other feedback, e.g., regarding
speed or gap, with apt consideration to VATM constraints.
[0318] The VATM plans and coordinates, given the constraints and
UTM requests and other feedback, and is configured to communicate
opportunities to the UTM--e.g., provide advice to the UTM regarding
certain roads or fuel economy given these constraints--e.g. when
the system needs to drive slower than the user set speed.
[0319] The VATM may also communicate reasons for its actions, e.g.,
why it cannot drive at a UTM-set speed, and can communicate a
corrected or new target speed. In such ways, the VATM behaves
responsively by showing its intentions and plans to its user.
[0320] In another example implementation, if current road
conditions and team-oriented ACC parameters might cause a risky
maneuver, the VATM advises the UTM of the conflict ahead of
time.
[0321] In another example, if vehicle sensors are not working, the
VATM automatically transfers control to manual as gracefully as
possible, within safe range, and communicates the transfer to the
UTM.
[0322] As another example, if user becomes irresponsive, the VATM
takes control autonomously, and may communicate the same to the UTM
and any other members, parties, or entities deemed appropriate.
[0323] The VATM can also extend ACC to include adaptation e.g.,
modifying system operation based on present or current operations
and conditions. For instance, as provided above in connection with
the method of FIG. 4, the VATM may establish as a new system
setting or preference, a present decision or pattern of decisions
made by the UTM, for use in similar future situations. The decision
or pattern can include, e.g., conditions under which the UTM
engages or disengages the team-oriented ACC, or certain settings
that the UTM sets the team-oriented ACC to.
[0324] As further example of a noticed behavior or pattern, the
VATM may recognize that by decreasing the speed, the UTM will tend
to remain engaged (e.g., maintain team interactions and/or continue
TOACC driving) for longer periods, drive safer, etc.
[0325] In one embodiment, as referenced above in a few places, the
VATM can, in response to suggesting to the UTM a change--e.g.,
change in speed and the user replying approving the change, or not
responding negatively, store the behavior for use in a like future
situation automatically.
[0326] The method 600 of FIG. 6 is described below with reference
to the illustration of FIG. 7. FIG. 7 shows schematically a model
700 of a collaborative adaptive cruise control system and functions
associated therewith.
[0327] FIG. 8 shows the same model 700 of FIG. 7, but separately in
order to identify features of the model 700 in support of the
description of the method 600 of FIG. 6 and references to FIG. 7.
As shown in FIG. 8, the model 700 includes: [0328] Engine status
item 802 [0329] An ignition-off reference 804 [0330] An ignition-on
reference 806 [0331] An FSR-ACC-off reference 808 [0332] An
FSR-ACC-status item 810 [0333] An FSR-ACC-on reference 812 [0334]
An FSR-ACC-on portion 814 [0335] A disengaged (manual) section 816
[0336] A standby item 818 [0337] A canceled item 820 [0338] A first
"set"-selected reference 822 [0339] A standby/"resume"-selected
reference 824 [0340] A canceled/"resume"-selected reference 826
[0341] A brake-pressed or canceled reference 828 [0342] An engaged
(automatic) section 830 [0343] A speed sub-section 832 [0344] A
gap-setting sub-section 834 [0345] An active sub-part 836 [0346] A
current-speed reference 837 [0347] A trend reference 838 [0348] A
capture-current-speed item 839 [0349] A stored-speed-setting item
840 [0350] A store-current-speed reference 842 [0351] A
decrease-speed reference 844 [0352] An increase-speed reference 846
[0353] A vehicle-stop item 848 [0354] A manual-override item 850
[0355] A gas-pedal-selected/elec-hand-brake-released reference 852
[0356] A vehicle-halt reference 854 [0357] A gas-pedal-released
reference 856 [0358] A second "set"-selected reference 858 [0359]
Gap stage items (e.g., sequential distance settings) 860 [0360] A
decrease-gap reference 862 [0361] An increase-gap reference 864
[0362] A brake g reference 866 [0363] An on item 868 [0364] An off
item 870
[0365] These and other features of the model 700 are described
further below with reference to FIG. 7 and the method 600 of FIG.
6.
[0366] With continued reference to FIG. 6, the method 600 begins
601 and flow proceeds to operation 602, whereat the processor
receives an indication from the user to initiate collaborative
activity. In one embodiment the indication includes the UTM
pressing an on button 702 of the ACC, or more particularly, in some
cases, a team or collaboration button.
[0367] In one embodiment, the indication is meant and interpreted
by the VATM to communicate UTM intention to be bound into
collaborative team operations. The VATM can in response consider
the UTM and VATM to have entered into an agreement, or contract, to
the team relationship. The contact may be actual, communicated to
the UTM, and include, e.g., clauses providing that, should the UTM
become insufficiently responsive and respectful of the relationship
(e.g., not responding to or ever accepting VATM inquiries or
recommendations, or e.g., in an emergency situation), the VATM will
either quit the relationship altogether or take full autonomous
control of the operations.
[0368] In one embodiment, these such consequences of the agreement
are made explicit--e.g., if the UTM is having a heart attack the
VATM takes fully automatic control until it reaches a safe stopping
spot and the car may also contact emergency services.
[0369] If the UTM has stated that he does not desire such a close
contract with the VATM, the VATM may operate under looser
standards, but may still quit if the UTM does not respond
sufficiently under the looser standards of the agreement. The
commitment described is indicated in FIG. 7 by reference numeral
704.
[0370] Following activation of the system at step 602, the
team-oriented cruise control system can at block 604 operate in a
STANDBY mode. In this state, the UTM manually controls vehicle
speed, e.g., via the throttle. However, the protections discussed
above are, if system settings call for it, still in place. For
example, when in STANDBY, and the UTM is having a medical
emergency, the VATM will take control of the speed, etc., toward
safely parking the vehicle or directing the vehicle to a hospital,
etc.
[0371] Flow of the algorithm proceeds to block 606, whereat the
VATM transitions from the STANDBY mode to an ACTIVE mode.
[0372] At block 608, the VATM in this portion provides one or more
of variety of communications. The VAT may, e.g., communicate (e.g.,
displays) to the UTM a current state of the VATM--i.e., ACTIVE. In
one embodiment, while in STANDBY and/or ACTIVE modes, the VATM
communicates consequences of engagement of the collaborative ACC
operations, such as settings for speed, ACC gap, speed limit (upper
bound), etc.
[0373] If the VATM has a-priori information about UTM behavior or
preferences--e.g., a UTM gap setting preference, this information
could be presented to the UTM as well. Such information share
promotes transparency, common ground, and other advantages of
collaboration outlined herein.
[0374] At block 610, the VATM processes other settings,
preferences, or conditions that may affect team-oriented ACC
operation. The VATM, e.g., may consider any history of interactions
and operation in the team, between the VATM and UTM, and any
related conditions. The VATM can also consider any relevant
attributes of the team agreement.
[0375] The VATM may also here process any information on hand or
otherwise available related to recommendations already provided to
the UTM and/or to other drivers, perhaps in like circumstances.
Regarding providing advice regarding other drivers, the VATM can
also communicate to the UTM any relevant similarities between the
UTM and the other driver(s) and between a present condition (e.g.,
weather, location) and the similar other conditions.
[0376] All information can be considered part of the model of the
team-oriented ACC system.
[0377] At block 612, the VATM determines whether any predetermined
settings or courses of action should be modified based on present
conditions. The conditions may include, e.g., environmental
conditions (e.g., rainy day).
[0378] An example modification is changing a previously determined
setting or recommendation for team-oriented gap.
[0379] At block 614, the VATM communicates any modification made to
the UTM, in the interest of transparence, responsiveness,
team-commitment, promoting trust, and any other related team-based
attributes described herein. The communications, as all
communications to team members, are provided in the pre-determined
common language and modalities preferred, as described above in
connection with other communications (e.g., in connection with the
method 500 of FIG. 5).
[0380] The potential and opportunity for the VATM to provide advice
and recommendations to the UTM as to the activation of the
team-oriented system, for instance, is depicted in FIG. 7 by
reference numerals 706.sup.1-9. The interactions can be referred to
as coordination. A similar circle is indicated in FIG. 7, at a
transition from system OFF to ON, by reference numeral 708, which
can be referred to as a fulfillment.
[0381] At block 616, the VATM receives indication from the UTM of a
desire speed. In the interest of transparency and other
collaborative properties, the VATM at block 618 communicates the
desired speed(s) set to the UTM. In this way, the UTM is confided,
more confident, knowing that the VATM received, stored, and
acknowledged the limit set by the UTM.
[0382] At block 618, if the VATM needs to for some reason drive at
a different, e.g., slower, speed, the UTM should understand why,
and/or the VATM will communicate to the user the reason and that
the VATM when return to the UTM set speed when appropriate and,
perhaps, what that appropriate condition is. The VATM may also in
the interim advise the UTM what the interim settings are--e.g.,
temporary lowered speed setting.
[0383] The VATM at block 620 notes any further or new appropriate
constraint(s) it identifies or encounters, for example, as a result
of traffic, road conditions, and determines how they may affect UTM
settings, e.g., UTM speed and gap values. The VATM can also
communicate any further changes, and underlying reasons to the
UTM.
[0384] At block 622, the VATM is responsive to any UTM requests,
such as regarding speed and gap settings or temporary modifications
thereto based, e.g., on constraints currently determined relevant
by the VATM. Responsiveness promotes collaboration concepts
including those described herein, including transparency,
responsiveness, generally, trust, etc.
[0385] At block 624, the VATM communicates any recommendations or
opportunities to change a setting to the UTM. An example is
providing the UTM with advice regarding speed and fuel economy.
This transparency is indicated at two places in FIG. 7 by reference
numeral 710.sup.1, 2, indicating relevant states of the VATM.
[0386] Relevant speed responsiveness is indicated by reference
numeral 712.
[0387] And relevant collaborative communications are indicated in
FIG. 7 by reference numeral 714, referencing a speed trend, e.g.,
at 714 adjacent indication 706.sup.4.
[0388] At block 626, the VATM processes and learns, based on the
afore-mentioned information, about the UTM and UTM preferences,
such as regarding speed, gap settings, engagement and disengagement
patterns demonstrated, etc. The VATM, e.g., determines based on the
learning how to better utilize the team-oriented ACC effectively
and efficiently, including ways to keep the TOACC engaged for
longer periods of time, toward goals such as promoting safer and
more economical driving.
[0389] In some embodiments, the collaborative team (e.g., VATM,
etc.) considers in its determination and actions, vehicle battery
state (e.g., charge level), fuel consumption (e.g., rates of use
(e.g., fuel economy), levels, etc.) to improve vehicle operation or
life, such as by improving fuel economy, management, and/or
extending batter range or life.
[0390] In some embodiments, the collaborative team (e.g., VATM
and/or UTM, etc.) considers in its determination and actions,
vehicle battery state (e.g., charge level), fuel consumption (e.g.,
rates of use (e.g., fuel economy), levels, etc.) to improve vehicle
operation or life, such as by improving fuel economy, management,
and/or extending batter range or life.
[0391] The VATM, based on such learning, which can consider various
environmental conditions (e.g., traffic and road conditions),
determines and provides advice to the UTM regarding TOACC, such as
regarding changes to the gap and speed values that are called for
in certain future situations to coordinate and plan safer and
better trips.
[0392] An override function is now described. At block 628, while
in the ACTIVE mode, the VATM receives indication that the UTM has
pressed the acceleration pedal. The UTM action typically indicates
that the UTM desires to take manual control. In one embodiment of
the team-oriented ACC, though, the VATM remains in the ACTIVE mode,
nonetheless, in the background. By being active only in a
background manner, the VATM does not actively attempt to regulate
speed, while remaining attentive and ready to take control under
certain conditions that may arrive. An example condition is the UTM
removing his/her foot from the accelerator. The VATM can then,
e.g., return the vehicle to the previously set and agreed-upon
speed.
[0393] Protocol controlling such function can be pre-communicated
to the UTM and/or communicated at the time to the UTM, as indicated
in FIG. 7 by reference numeral 716. The understood grounds are
important especially in cases involving a shift in control, whether
to that VATM from the UTM, or vice versa.
[0394] At block 630, the VATM advises against such an action (e.g.,
against the VATM taking control at this point), as indicated in
FIG. 7 by a circle and reference numeral 718.
[0395] Manual override is indicated in FIG. 7 by reference numeral
719.
[0396] Operation of the team-oriented ACC framework with respect to
full-speed range is now described. At block 632, while driving
under team-oriented FSACC, the VATM brings the vehicle to a
complete stop, such as due to traffic conditions--for example, the
speed is decreased to zero to maintain a safe gap from the vehicle
ahead.
[0397] At block 634, the VATM, in the described collaborative
interests including transparency, makes its dynamics, including
reasons for changing vehicle operations, clear to the UTM.
[0398] In one embodiment, the vehicle or VATM in particular
includes a dedicated button or action (e.g., a quick kick of the
gas pedal) by which the UTM commands the VATM to continue driving
(i.e., to "go"). The VATM receiving such communication from the UTM
is indicated by block 636.
[0399] At block 638, the VATM, based on its programming, determines
to use the brakes in order to keep a safe gap distance from a
preceding car and, in the case of full-speed range capability, can
also slow to a stop if appropriate (e.g., approaching stopped
traffic).
[0400] At block 640, the VATM, as in all conditions, respects the
importance of communicating VATM operations under the team
framework to the UTM. The communication is indicated in FIG. 7 by
an intra or self loop and reference numeral 720.
[0401] The VATM may also use ancillary automated vehicle driving
systems or sub-systems. At block 642, in addition to the use of
brakes for collaborative ACC and collaborative FSR-ACC adaptive
cruise, the VATM may engage another active safety system, such as
an automatic braking system, such as to avoid an accident. As with
all interactions, the VATM and UTM will have pre-agreed, e.g., in
established commitments, to such VATM function and/or the VATM may
communicate with the UTM in-line regarding the function(s) being
taken and reasons therefor.
[0402] The team-oriented ACC, or team-oriented FSR-ACC, is also
configured with protocols or processes regarding disengagement of
the system. At block 644, the VATM receives indication that the UTM
has pressed the brakes or a cancel or off button. The VATM
disengages the team-oriented ACC in response and, again, remains ON
in the background. Gap and speed information, which remains set in
the VATM, in some embodiments still needs to be made transparent to
the UTM in an appropriate manner (e.g., timing, modality, etc.). In
this state, the VATM can still monitor UTM actions, in connection
with related conditions (e.g., weather, location, traffic, etc.),
and store the monitored actions and conditions for future use in
team operations.
[0403] The method 600 can be repeated or end 645.
VI. ADDITIONAL CONCEPTS
[0404] The disclosure now re-states principles and concepts
described above on which the team-oriented automated system is
based and can operate, and describes some related ancillary
principles and concepts.
[0405] The collaborative human-machine-interface (HMI) concepts
described herein can be applied to any one or more of numerous
systems. While the technology is not limited to use in connection
with automobiles, or even vehicles, generally, as referenced above,
example vehicle systems and sub-systems into which the present
collaborative framework can be implemented include ACC, HVAC,
navigation, security (including cyber-security and
lock/start/remote interaction with the car by
WIFI/internet/mobile), power management (including fuel efficiency
or other fuel-related considerations, battery state of charge
(SOC), environmental considerations, hybrid, fuel cell, gear
shifts, modes of drive), environmental considerations outside of
power management, navigation (e.g., based on GPS or other, e.g.,
social-media based, vehicle-to-vehicle (V2V) interaction, relation
to land marks such as cell stations or other infrastructure (V2I)),
management and user interaction with location-based services (LBS;
such regarding stores, services, coupons), help (e.g., electronic
user manual and additional help functions while driving), radio and
other means of entertainment, web management (e.g., e-mail,
short-message system (SMS) messaging, social networking and social
interaction), learning systems (e.g., educational system
facilitating user learning about environment, museums, touristic
information), vehicle health management system (VHMS), phone, V2V
connectivity, automation features such as ACC, lane centering (LC),
lane change (LX), automated steering related to semi-autonomous
driving, general interaction with vehicle (e.g., relating to
operation of windows, wipers, lights, headlights, tires, engine),
radio or other audio-related settings or preferences, and seat belt
operation (driver and/or front or back-seat passengers).
[0406] In each implementation (i.e., for any of the uses, or
applications, described herein above), the seven (7) teamwork, or
collaboration, features of the cooperative HMI described herein are
applied. More particularly, for example, the cooperative system can
in each instance be initiated by means of a contract between the
automated system, or vehicle agent team member (VATM), and the user
team member (UTM), which relates the first of the seven (7)
teamwork features.
[0407] In addition, the VATM and resulting teams will be built upon
the three (3) modules, including the four (4) described models,
including of user, of machine, of machine as seen by user, and of
the interface. Further, in some embodiments some information is
considered essential, or domain specific, and must be shared
appropriately to promote transparency, relating to the second
feature of the seven (7) teamwork or collaboration features--models
and transparency data feature.
[0408] Moreover, the collaborative, or cooperative, HMI is based on
a common communication language and protocol enabling
bi-directional communication, relating to the third feature of the
seven (7) teamwork features.
[0409] The automated behavior of the system will follow
coordination algorithms, referenced in the fourth feature of the
seven (7) teamwork features, which assume existence of a model of
the UTM and compute actions or decisions of the system (e.g. VATM)
accordingly.
[0410] Further, the systems according to the present technology can
be designed to be responsive to the needs, preferences, etc, of the
UTM, toward being supportive of the UTM, such as when the UTM has
input to be considered, an enquiry, or other need calling for
explanation or other information, help, or assistance. This relates
to the fifth feature of the seven (7) teamwork features.
[0411] The design of the systems will promote sensitivity between
the UTM and the machine to create a sense of intimacy between the
two, relating to the sixth feature of the teamwork features. For
example, system pitch, intonation, and use of collaborative
terminology or wording, such as "we" and "our" instead of "I" and
"you," will be designed to create a team feeling, or collaborative
environment.
[0412] And relating to the seventh teamwork features, the system
interacts with the user to promote acknowledgement and feedback
about joint performance.
[0413] As provided, the above-described computer-executable code or
instructions are in various embodiments configured to consider, in
forming and executing the algorithms and method of the present
technology, any of a wide variety of these principles and
concepts.
[0414] The concepts includes considerations originating in one or
more of a variety of fields of thought, including social science
(philosophy, sociology, social psychology), computer science,
artificial intelligence, and human factors. The framework
incorporates determinations of what defines a team, generally and
essentially, and, more particularly, corresponding understandings
of what defines good team interaction.
[0415] The concepts include data items corresponding to team
properties, such as mutual support, mutual commitment, VATM
transparency (e.g., as to machine state, behavior, control), user
transparency (again regarding, e.g., state, intent, action), and
responsiveness.
[0416] The team-based human-machine interface (e.g., human-vehicle
interface (HVI)) facilitates provision and request of feedback and
help when it is desired by team member. The interface promotes the
interaction being transparent, which allows the UTM to understand
what the VATM is doing and why, and what the VATM may need, etc.,
and allows the VATM to sense UTM state, determine user preferences,
etc.
[0417] The team-oriented interface is configured based in part on
the UTM model, the VATM model, and VATM behavioral modules.
Creating, updating, and maintaining models of the VATM and the UTM
has at least a twofold purpose. The VATM is enabled to act best
with relevant information about how the UTM behaves and thinks,
such as by using data representing the model that the VATM has
developed in working with the UTM. And the VATM can explain itself
to its UTM, providing recommendations, inquiries, and reasons for
actions, e.g., using a model of itself (VATM model) that can be
interpreted easily by the human user team member (UTM). In these
and other ways, the VATM can coordinate an effective team
framework, as compared with the conventional automated framework
involving supervisory models. And, in these ways, the team members
(at least VATM and UTM) can together invested in achieving success
in the cooperative mission, and in a smooth and efficient
manner.
[0418] Considering differences in how machines and humans process
data and function, a successful collaborative team including an
automated machine agent and a human user agent, the team-oriented
framework is configured to bring the team members together, on
common ground, for working together toward shared team goals. It
should not be assumed in the design or operation of the automated
team member that the human user agent will operate like the
automated team member, and the user agent cannot assume that the
machine member will operate based on the same belief and behavior
system that the user operates from.
[0419] As referenced, the collaborative framework is configured so
that each team member will be attentive and responsive to group
activity, the actions of the other team member(s), group processes
for selecting a recipe, and assigning agents, or members, to
constituent actions. And team members should be mutually
directable. That is, policies can be enforced on teams to
dynamically regulate behavior of the system in an external manner.
Specifically, e.g., using such policies, the human agent team
member can enforce bounds on the behavior of the automated agent.
Feedback and attention can also be used to point respective members
toward important signals, activities, changes, etc. Team members
should also contribute to lowering a cost of coordinating their
activities--e.g., the team members acting in the team framework
improve efficiency of team operation.
[0420] Another important aspect of human-automation interaction is
trust. For teams to work together there should be mutual trust
between the human team member(s) and the machine agent team
member.
VII. OUTCOMES, ADVANTAGES, AND BENEFITS
[0421] Automated agent and human user teamwork reduces overall
workload, due in large part to increased transparency, maintains
high levels of situational awareness, due in large part to the
collaborative interface approach, keeps the user agent in the
control loop, especially due to the communication channels enabled
by the team-oriented interface, and attains trust, due mostly to a
reduction in uncertainty as a result of improved
communications.
[0422] The present technology results in a variety of positive
outcomes. The outcomes include a transparency of the vehicle agent
team member to the user team member.
[0423] Another outcome is awareness of the existence, state, and
actions of all team members.
[0424] Another outcome is an ability of the VATM to provide
proactive, contextual, machine help to the UTM.
[0425] As another outcome, the framework facilitates bi-directional
communication amongst team members and, thereby, promotes free
sharing, requesting and provisioning, of information.
[0426] Advantages of the present technology include provision of a
paradigm shift in the way vehicle agent team members interact with
the users.
[0427] Another advantage of the technology is an enhanced user
experience in working with the vehicle, reducing user annoyance and
disorientation through the team experience.
[0428] Another advantage of the technology is an improvement of
user-vehicle interactions by maintaining transparency and enabling
proactive and reactive assistance.
[0429] Benefits of the present technology include enhancing user
experience by maintaining long term relationships between a human
user and the different automated systems in the car resulting from
considering both systems and users as team members.
[0430] Benefits also include reducing user annoyance and confusion
by supporting the user as an automated team member with the VATM
that is aware of the user, and his/her needs and preferences.
[0431] The benefits also include improving vehicle system
effectiveness via coordinated relationships with the user in order
to increase user satisfaction and possibly increased use of the
vehicle automation.
[0432] The benefits also include improving a vehicle-user interface
and an integrated user experience.
[0433] The benefits also include improved vehicle effectiveness by
increasing the usage of the systems and the satisfaction level of
the user.
[0434] The benefits also include a graceful accommodation of users
to a more natural interaction with the automation.
VIII. CONCLUSION
[0435] Various embodiments of the present disclosure are disclosed
herein. The disclosed embodiments are merely examples that may be
embodied in various and alternative forms, and combinations
thereof.
[0436] The law does not require and it is economically prohibitive
to illustrate and teach every possible embodiment of the present
technology. Hence, the above-described embodiments are merely
exemplary illustrations of implementations set forth for a clear
understanding of the principles of the disclosure.
[0437] Variations, modifications, and combinations may be made to
the above-described embodiments without departing from the scope of
the claims. All such variations, modifications, and combinations
are included herein by the scope of this disclosure and the
following claims.
* * * * *