US20130245857A1 - Distributed hardware architecture for unmanned vehicles - Google Patents

Distributed hardware architecture for unmanned vehicles Download PDF

Info

Publication number
US20130245857A1
US20130245857A1 US13/099,445 US201113099445A US2013245857A1 US 20130245857 A1 US20130245857 A1 US 20130245857A1 US 201113099445 A US201113099445 A US 201113099445A US 2013245857 A1 US2013245857 A1 US 2013245857A1
Authority
US
United States
Prior art keywords
hardware system
distributed hardware
enabled
modules
distributed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US13/099,445
Other versions
US8548646B1 (en
Inventor
Ryan GARIEPY
Bryan Nicholas WEBB
Patrick William Martinson
Matthew Allen Rendall
Rajan Joshua GILL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CLEAERPATH ROBOTICS Inc
Clearpath Robotics Inc
Original Assignee
Clearpath Robotics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Clearpath Robotics Inc filed Critical Clearpath Robotics Inc
Priority to US13/099,445 priority Critical patent/US8548646B1/en
Assigned to CLEAERPATH ROBOTICS, INC. reassignment CLEAERPATH ROBOTICS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MARTINSON, PATRICK WILLIAM, RENDALL, MATTHEW ALLEN, WEBB, BRYAN NICHOLAS, GARIEPY, RYAN, GILL, RAJAN JOSHUA
Publication of US20130245857A1 publication Critical patent/US20130245857A1/en
Application granted granted Critical
Publication of US8548646B1 publication Critical patent/US8548646B1/en
Assigned to Clearpath Robotics Inc. reassignment Clearpath Robotics Inc. CORRECTIVE ASSIGNMENT TO CORRECT THE RECEIVING PARTY'S NAME FROM "CLEARPATH ROBOTICS, INC." TO CLEARPATH ROBOTICS INC" PREVIOUSLY RECORDED AT REEL: FRAME: . ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: MARTINSON, PATRICK WILLIAM, RENDALL, MATTHEW ALLEN, WEBB, BRYAN NICHOLAS, GARIEPY, RYAN, GILL, RAJAN JOSHUA
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428Safety, monitoring
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/26Pc applications
    • G05B2219/2637Vehicle, car, auto, wheelchair

Definitions

  • UVs unmanned vehicles
  • distributed hardware architecture which can provide unmanned vehicles with a high degree of reliability and upgradeability.
  • the present invention is comprised of an unmanned vehicle platform with a set of components which are known to be applicable by those skilled in the art. These components may include actuators such as DC drive motors, pan/tilt sensor mounts, or standalone manipulator devices. Components may also include sensing modules such as scanning laser rangefinders, passive environmental sensors, inertial measurement units, drive encoders, camera assemblies, and global positioning systems. Finally, computing and communication modules such as processors, memory, 802.11 transceivers, point-to-point wireless control hardware, and hardwired user interfaces may also be included.
  • actuators such as DC drive motors, pan/tilt sensor mounts, or standalone manipulator devices.
  • Components may also include sensing modules such as scanning laser rangefinders, passive environmental sensors, inertial measurement units, drive encoders, camera assemblies, and global positioning systems.
  • computing and communication modules such as processors, memory, 802.11 transceivers, point-to-point wireless control hardware, and hardwired user interfaces may also be included.
  • Each component is mounted either external to or within a vehicle platform, depending on specific component requirements.
  • Sensors such as cameras or laser rangefinders tend to be mounted externally, while inertial measurement units, drive systems, and computational hardware can be mounted internally.
  • the vehicle platform should be constructed to protect any internally mounted devices from harsh environmental conditions. Methods for this protection are well known to those in the field of electromechanical design.
  • the platform itself can incorporate one of many possible methods of moving through the environment. It can be an unmanned surface vehicle capable of navigating over water, an unmanned ground vehicle based on an existing manned vehicle chassis, a custom unmanned ground vehicle, or any other type of unmanned chassis known to the field.
  • the platform is a custom all-electric 6 ⁇ 6 off-road chassis driven by brushed DC motors.
  • the platform can comprise any suitable platform including but not limited to unmanned vehicles, manned vehicles, aquatic vehicles, amphibious vehicles, aeronautic vehicles any other suitable vehicle, and/or a combination, or the like.
  • steering can be achieved by a method which is known as “differential drive” to those skilled in the art. The entirety of the internal electronics and drive train is protected from the environment.
  • the managed power system can be enabled to allow users to perform a tool less “hot-swap” of batteries if desired, allowing system runtime to be extended indefinitely with only intermittent interruptions to operation by battery changes and no interruptions to sensor or computational power.
  • the system also separates key hardware such as communications devices, power amplifiers, user interface hardware, and control processors into discrete modules linked via a central vehicle control network.
  • An example implementation of this control network uses the well-known CAN (Controller Area Network) standard, which is commonly used in the automotive and aerospace sector.
  • CAN Controller Area Network
  • Each module can communicate with any other module on the network, and the network is structured such that the highest priority messages always make it to their recipients without requiring retransmission.
  • An aspect of the specification provides a distributed hardware system for controlling a vehicle, comprising: a network; a central control module for controlling the distributed hardware system; a plurality of electronic hardware modules in communication with the central control module via the network, each of the plurality of electronic hardware modules enabled to: communicate with one another via the network; issue requests for information from the central control module via network; transmit data over the network in a common format to perform tasks respective to a respective function; and at least one of: independently sense one or more of: a respective status of the distributed hardware system and at least one respective environmental parameter; and
  • the vehicle independently control the respective function of the vehicle, and at least a portion of the plurality of electronic hardware modules enabled to: be removed and inserted from the distributed hardware system as plug and play modules; and determine when at least one of the plurality of electronic hardware modules is removed or inserted from the distributed hardware system and transition to a corresponding state.
  • the distributed hardware system can further comprise at least one power source.
  • the at least one power source can comprise at least two batteries and respective battery bins enabled to independently open such that a hot swap of a respective battery can be performed.
  • the control module can be enabled to control power to each of the plurality of electronic hardware modules.
  • the distributed hardware system can further comprise at least a first power source powering the distributed hardware system and a second power source, wherein one or more of the control module and at least one of the plurality of electronic hardware modules can be further enabled to: determine that the first power source is no longer able to power the distributed hardware system; and implement a power down transition in the distributed hardware system such that powering of the distributed hardware system is switched to the second power source and a hot swap sequence can be implemented to remove the first power source and insert a third power source.
  • the power down transition can comprise a motor power down transition,
  • the one or more of the control module and at least one of the plurality of electronic hardware modules can be further enabled to enter a low power state until the hot swap sequence occurs.
  • the distributed hardware system can further comprise at least one sensor for sensing at least one of the respective status of the distributed hardware system and the at least one respective environmental parameter, wherein a respective one of the plurality of electronic hardware modules can be enabled for communication with the at least one sensor.
  • At least one of the plurality of electronic hardware modules can comprise a radio frequency (RF) module enabled to receive command data from a remote control system, translate the command data to the common format and communicate translated command data over the network.
  • RF radio frequency
  • At least one of the plurality of electronic hardware modules can comprise a remote control receiver enabled to receive command data from an off-the-shelf remote control receiver, translate the command data to the common format and communicate translated commands over the network.
  • At least one of the plurality of electronic hardware modules can comprise a user interface module enabled to at least one of receive command data from an input device and convey system data to a user.
  • the network can comprise at least one of a vehicle control network and a communication bus.
  • the distributed hardware system can further comprise at least one of a battery charging system and at least one motor.
  • the central control module can be enabled to communicate with a high level computing system via a control link.
  • the central control module can be enabled to store at least one of: system state information received from the plurality of electronic hardware modules; setting data; setpoint data; and a combination thereof.
  • FIG. 1 depicts external characteristics features of an unmanned vehicle platform, according to non-limiting implementations.
  • FIGS. 2 a and 2 b depict two possible arrangements of internal modules of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 3 is a depiction of a possible hot-swap capable battery receptacle
  • FIG. 4 depicts configuration of electronic modules and device network of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations
  • FIG. 5 depicts a configuration of a central control module of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 6 depicts a configuration of a motor amplifier module of the unmanned vehicle platform, according to non-limiting implementations.
  • FIG. 7 depicts a process flow for a power management system that can be implemented by the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 8 depicts a remote receiver module mounted to chassis 180 of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 9 depicts a configuration of an RF module of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 10 depicts a configuration of a remote receiver module of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 11 depicts a status display of the unmanned vehicle platform of FIG. 1 , according to non-limiting implementations.
  • FIG. 12 depicts an example program layout of vehicle control firmware of each module attached to the unmanned vehicle platform of FIG. 1 via a central vehicle control network, according to non-limiting implementations.
  • FIG. 13 depicts another example program layout of vehicle control firmware of each module attached to the unmanned vehicle platform of FIG. 1 via a central vehicle control network, according to non-limiting implementations.
  • FIG. 1 depicts external features of an unmanned vehicle platform 101 , according to non-limiting implementations.
  • a chassis 180 and supporting external members 190 house or otherwise provide stable mounting points for sensors, computing systems, and other devices.
  • Unmanned vehicle platform 101 is enabled to track trajectories by way of actuating a set of wheels 200 , which in non-limiting depicted implementations are arranged in a differential-drive configuration.
  • Devices may be mounted within the chassis 180 or external to it, on removable and modular plates 100 or affixed to bumpers 90 .
  • drawers 140 are securable from opening using, for example, a set of latches 130 , and may be opened via handles 150 , springs, or the like.
  • Bumpers 90 may be designed to provide an ergonomic carrying method for the combination of the platform and any other attached devices. Batteries are accessible externally via the battery bays 210 which may incorporate a battery bay latch 230 . In some implementations, if users do not wish to remove batteries for charging, they may be charged while still in the platform via charge connectors 220 .
  • Unmanned vehicle platform 101 can comprise a set of controls mounted directly to the chassis.
  • unmanned vehicle platform 101 is enabled for activation/deactivation via a latching pushbutton 240 and can be emergency stopped manually via a safety pushbutton 170 .
  • Any other suitable method of controlling unmanned vehicle platform 101 is within the scope of present implementations, including but not limited to issuing commands from a computing system mounted within the drawers 140 and/or by sending commands to a remote control receiver module 110 .
  • a degree of feedback on the state of the system of the unmanned vehicle platform 101 can be provided via a status display 120 .
  • unmanned vehicle platform 101 can comprise a plurality of possible operational modules, each of which may provide unmanned vehicle platform 101 with a different set of capabilities.
  • FIGS. 2 a and 2 b shows two possible arrangements of internal modules.
  • FIG. 2 a depicts a central control module 30 connected to a motor amplifier module 40 and a user interface module 50 by way of a vehicle control network 60 .
  • Vehicle control network 60 can comprise any suitable network hardware and topology, including but not limited to a communication bus (e.g. as depicted), the “CANBus” standard (which can used for its speed and robustness to noise), or the like. Any other suitable network hardware and topology is within the scope of present implementations, including any suitable network hardware and topology commonly in use.
  • Modules 30 , 40 , 50 can also be enabled to receive commands from other systems not on the vehicle control network 60 .
  • the central control module 30 can be connected via a control link 20 to a high-level computing system 10 , over which it reports status, sends sensor data, and receives commands.
  • the embodiment as shown uses a wired serial point-to-point connection as the control link 20 and an off-the-shelf laptop computer as the high-level computing system 10 , but the system is not restricted to these choices.
  • the control link 20 could be a radio modem and the high-level computing system 10 could be a rack-mounted server. It is appreciated that any suitable control link and/or computing system is within the scope of present implementations.
  • FIG. 2 b is similar to FIG. 2 a , with like elements having like numbers, however the arrangement of modules of FIG. 2 b further comprises an RF (radio frequency) module 70 enabled to receive wireless emergency stop commands and an RC (radio control/radio receiver) module 80 enabled to transform signals from (for example) off-the-shelf radio control receivers to forms which are compatible with the vehicle control network 60 . Expanding the platform capabilities in this way does not necessitate any changes to the rest of unmanned vehicle platform 101 .
  • RF radio frequency
  • RC radio control/radio receiver
  • FIGS. 3 a , 3 b and 3 c depicts a toolless battery change process/sequence, according to non-limiting implementations;
  • FIG. 3 a depicts a battery bin 260 in a closed position
  • FIG. 3 b depicts the battery bin 260 in an open position
  • FIG. 3 c depicts the battery bin 260 in the open position with a battery 320 external to the battery bin 260 .
  • the battery bin 260 is secured to the chassis 180 via pivots 290 .
  • the battery bin 260 incorporates integrated terminals 270 which elastically deform under the weight of the battery to maintain electrical connectivity.
  • a battery bay latch 230 may be used to lock the battery bin 260 in the closed position by engaging with a latch slot 300 . Additionally, this battery bay latch 230 may include a sensor on it to allow the central control module 30 to determine when the battery bay 260 is opened or closed. If this is the case, the battery bay latch 230 is designed such that it cannot be closed when the battery bay 260 is open. Finally, a spring assembly 310 may add to the force keeping the battery terminals 330 mated with the integrated terminals 270 when the battery bin 260 is closed.
  • the battery 320 is removed by releasing the battery bay latch 230 and manually pivoting the battery bin 260 until the opening mechanical stop 250 makes contact with the chassis 180 , as in FIG. 3 b .
  • the central control module 30 can execute appropriate instructions to handle the opening event (for example, as described below with reference to FIG. 7 ).
  • the battery bin 260 may also be opened by a spring assembly or by other automated means.
  • the battery 320 is then removed, as in FIG. 3 c .
  • the removal process itself can be dependent on the battery form factor. In exemplary implementations, the removal process can take the form of a manually actuated pull strap.
  • the battery 320 is replaced by reversing the process.
  • the battery 320 is slid into the battery bin 260 until the battery terminals 330 mate with the integrated terminals 270 .
  • the battery bin 260 is then pivoted closed until the closing mechanical stop 280 makes contact with the chassis 180 .
  • the battery bin 260 is secured with the battery bay latch 230 . If the battery bay latch 230 includes a sensor capable of monitoring its state, the central control module 30 can now execute appropriate instructions to handle the closing event.
  • FIG. 4 depicts a system 301 of electronic modules and device network of unmanned vehicle platform 101 , according to non-limiting implementations.
  • the central control module 30 is powered by a power bus 460 which itself is fed from a plurality of power sources which may include one or more batteries 320 and/or an AC power supply 440 or the like. Batteries 320 used in unmanned vehicle platform 101 can be recharged without being removed by the battery charging system 430 .
  • the battery charging system 430 can indicate to the central control module 30 when the batteries 320 are being charged.
  • the central control module 30 can be enabled to shut off or turn on any subset of the available power sources, while the platform's power switch 470 shuts off all available power sources.
  • the central control module 30 is further enabled to power the fuse panel 360 , any internal modules 50 , 70 , 80 , low-level sensors 390 and portions of the motor amplifier module 40 .
  • Incorporated into the low-level sensors 390 are a number of control feedback sensors which can be used to perform platform state estimation.
  • Control feedback sensors can include but are not limited to inertial sensors 400 and encoders 410 , where the encoders 410 can use any suitable sensing methods (e.g. optical, magnetic, mechanical or the like).
  • the encoders 410 can be physically connected to the drive train of the chassis 180 , providing a direct observation of various speeds within the drive train. These feedback sensors 400 and encoders 410 may be used to improve the trajectory tracking performance of the unmanned vehicle platform 101 and/or may be restricted to observing changes in a state of the unmanned vehicle platform 101 .
  • the payload bay 340 is generally comprised of components that a user interacts with during operation of the unmanned vehicle platform 101 .
  • the payload bay 340 contains the high-level computing system 10 , the fuse panel 360 and a plurality of payloads 350 .
  • Payloads 350 can comprise additional sensors, additional actuators, communications devices, additional computing hardware, and any other suitable equipment, including equipment that can commonly be found on other unmanned vehicle platforms.
  • the high-level computing system 10 is connected using appropriate interfaces to the payloads 350 .
  • the fuse panel 360 routes power from the central control module 30 to the high-level computing system 10 and the payloads 350 , and may have multiple fused connectors for a variety of different voltage levels and current ratings. Any suitable software can be deployed to the high-level computing system 10 .
  • the central control module 30 communicates via the vehicle control network 60 with secondary modules 40 , 50 , 70 , 80 as appropriate. Communications may happen sporadically or at a regular frequency. When the latter, one or more modules can be enabled to require a given message frequency to remain operational, which can improve the safety of the unmanned vehicle platform 101 . For example, such an implementation can be useful when receiving commands via the remote receiver module 80 , monitoring remote switches via the RF module 50 and/or commanding motor motion via the motor amplifier module 40 . However, such a requirement on message frequency can be less useful with other modules such as the user interface module 70 . Furthermore, it is appreciated that use of the phrases “require” and “requirement” refer only to particular implementations and the given message frequency remaining operational is to be construed as being required in all implementations and/or to be unduly limiting.
  • FIG. 5 depicts a configuration of a central control module 30 of the unmanned vehicle platform 101 , according to non-limiting implementations.
  • the main components of the central control module comprise a power source selection module 490 , a power regulation module 510 and an embedded processor 530 .
  • the power source selection module 490 is enabled to select which of the available power sources within the power bus 460 is fed into the power regulation module 510 . This selection is done based on the information made available by the monitoring module 480 .
  • the power regulation module 510 powers the embedded processor 530 , the fuse panel 360 (including devices powered by the fuse panel), and any other devices which are connected to the vehicle control network 60 .
  • the battery detect switches 550 enable the power source selection module 490 to determine if the user is removing a battery 320 or if they have recently replaced one. With such information, the power source selection module 490 can minimize system downtime by ensuring that the unmanned vehicle platform 101 and/or the system 301 is powered from a reliable power source at all times.
  • Optional display indicators, such as the status panel 120 and/or the battery-in-use indicators 540 can indicate which subset of power sources are being used at any given time.
  • a soft start module 520 may be used to limit the inrush current into the fuse panel 360 and other devices powered by the power regulation module 510 .
  • the status of each power source in the power bus 460 is monitored using corresponding monitoring modules 480 .
  • the monitoring modules 480 may retrieve any subset of temperature, voltage and current draw data or the like.
  • the monitoring module 480 may also use this data to estimate the health of each power source in the power bus 460 .
  • This data can also report to the embedded processor 530 so that it can reduce power draw when necessary.
  • the data may also be forwarded to the high level computing system 10 or retransmitted along the vehicle control network 60 .
  • Each monitoring module 480 can be enabled to shut off power from its associated power source. There may also be a separate current sense module 500 that reports current draw data to the embedded processor 530 . A power switch 470 is used to shut off all available power sources.
  • the embedded processor 530 also collects sensor data 520 from a plurality of sensors, which may include, but is not limited to, devices such as a tilt-compensated compass, IR rangefinders, angular rate gyros, and wheel encoders.
  • FIG. 6 depicts a configuration of a motor amplifier module 40 of the unmanned vehicle platform 101 , according to non-limiting implementations.
  • the motor amplifier module 40 comprises an embedded processor 590 , a motor power source selection module 560 and any suitable ancillary components, for example any suitable ancillary components that can be determined according to electrical design principles.
  • the embedded processor 590 can communicate with the central control module 30 and other modules in the system 301 using the vehicle control network 60 .
  • the power regulation module 510 located in the central control module 30 provides the power necessary to run the embedded processor 590 . This power is transmitted along the same path as the vehicle control network 60 .
  • the embedded processor 590 can read battery voltages using the power monitoring system 570 and motor current draw using the current sense modules 580 .
  • the motors 380 are powered by sources selected by the motor power source selection module 560 . Power to each motor 380 is controlled by the embedded processor 590 . The embedded processor 590 can use any suitable strategy to regulate the power to each motor 380 . In exemplary implementations, as depicted, each motor 380 is driven by an H-bridge circuit 600 which is controlled by a bridge driver 610 . Each bridge driver 610 is in turn controlled by the embedded processor 590 .
  • a physical E-stop 170 can be used to cut off power to parts of the system 301 , if necessary, providing a robust safety system which is not dependent at all on firmware.
  • the physical E-stop 170 can be monitored by the motor power selection module 560 .
  • the motor power selection module 560 can shut off all power to the H-bridge circuits 600 and by extension halts the motors 380 .
  • FIG. 7 depicts a process flow for a managing a power bus 460 that can be implemented by the unmanned vehicle platform 101 , according to non-limiting implementations.
  • the unmanned vehicle platform 101 starts in a power off state 620 .
  • the main power switch 470 is turned on, a power-on transition occurs 630 and the central control module 30 , as well as every other device powered by the power regulation module 510 , is powered on.
  • the electronics are powered by all available power sources 640 .
  • the embedded processor 530 instructs the power source selection module 490 to choose a single power source and a power source selection transition 650 occurs.
  • the central control module 30 In the single-power state 660 , the central control module 30 , and every other device powered by the power regulation module 510 , is powered by a single power source (e.g. a first battery of batteries 320 ). In some configurations the system 301 will remain powered by a secondary power source, such as a second battery of batteries 320 , in addition to a source such as an AC power supply 440 in case the primary source is suddenly removed.
  • the motor power source selection module 560 turns on the power source to power the motors and a motor power transition 670 occurs. Once the motor power transition 670 has been completed, the unmanned vehicle platform 101 has entered its normal operation state 680 .
  • a number of situations can cause the unmanned vehicle platform 101 to leave the normal operation state 680 .
  • Such situations may include the triggering of the battery detect switch 550 , the battery state-of-charge dropping below a preset threshold, or the user swapping out a current power source/battery 320 . If one of these situations occurs, the unmanned vehicle platform 101 leaves the normal operation state 680 and a motor power down transition 740 occurs.
  • the motor power source selection module 560 shuts down all power to the motors 380 and the system 301 then transitions into the motors powered down state 750 . If the motor power down transition 740 occurred due to a low state-of-charge on the batteries 320 then the vehicle will undergo a state transition 730 to a low-power state 720 .
  • the unmanned vehicle platform 101 waits until the charge on the battery 320 reaches a critically low level and another transition 710 occurs to a shut down state 700 .
  • the user may add a fresh battery 320 or an additional power source such as an AC power supply 440 to prevent the system 301 from entering the shut down state 700 .
  • the system 301 switches the new power source on, undergoes a recovery transition 760 , and is powered by both the old and the new power source for a period of time 790 . From this state, the system 301 would return to being powered by one source 660 by shutting the old source off and will eventually return to normal operation 680 as it did when first starting up.
  • a secondary power source transition 770 occurs and the unmanned vehicle platform 101 is powered by two power sources for a period of time 790 . From this state 790 , the unmanned vehicle platform 101 would shut off the old power source and return to being powered by one source 660 . The unmanned vehicle platform 101 would then return to the normal operation state 680 as it did when first starting. If the user removes the only available power source, a shutdown transition 690 occurs and the unmanned vehicle platform 101 enters the shut down state 700 immediately.
  • FIG. 8 depicts detail of a remote receiver module 110 mounted to the chassis 180 , according to non-limiting implementations.
  • the remote receiver module 110 can comprise any suitable remote receivers, including but not limited to remote receivers enabled to improve performance, for example by altering an enclosure composition, adding external antennas 800 or the like.
  • FIG. 9 depicts a configuration of the RF module 70 of the unmanned vehicle platform 101 , according to non-limiting implementations, which enables direct wireless control of the central control module 30 .
  • the RF module 70 comprises an RF antenna 800 that provides a modulated signal to the RF demodulator 810 .
  • the RF demodulator 810 sends out a string of data, as received by the antenna 800 , to the decoder 820 .
  • the decoder 820 reads a serial bit stream and translates the data to a parallel bus.
  • the parallel bus is read in by the embedded processor 830 .
  • the embedded processor 830 then encodes the data and communicates the encoded data over the vehicle control network 60 .
  • the entirety of this module is powered by the power regulation module 510 .
  • This configuration is only an example and the specifics of details such as modulation, frequency, and power are not to be construed as being particularly limiting.
  • FIG. 10 depicts a configuration of the remote receiver module 80 of the unmanned vehicle platform 101 , according to non-limiting implementations.
  • Remote receiver module 80 is enabled to translate data from, for example, off-the-shelf remote receivers to a common format, which enables many off-the-shelf remote receivers to be integrated with the unmanned vehicle platform 101 without changing the firmware or electrical system of the central control module 30 . Such data can be transmitted over a 2.4 GHz band, or any other suitable radio band, or the like.
  • the remote receiver module 80 can comprise (for example) an off-the-shelf remote control receiver 840 and an embedded processor 860 .
  • the remote control receiver 840 and the embedded processor 860 are powered by the power regulation module 510 .
  • the remote control receiver 840 demodulates transmissions sent by the remote control transmitter 850 .
  • the remote control transmitter 850 can be handheld, stationary, or in any other physical configuration.
  • the remote control receiver 840 forwards the demodulated transmission to the embedded processor 860 .
  • the demodulated transmission can consist of servo pulses, pulse width modulation signals, a serial bit stream, or any other number of transmission formats as known to those skilled in the art, or the like.
  • the embedded processor 860 interprets the demodulated transmission and reformats the received data into a fowl which can be transmitted on the vehicle control network 60 .
  • the embedded processor 860 can also be enabled to conduct some filtering on the demodulated transmission. Such filtering can comprise detecting when the remote control transmitter 850 is out of range of the remote control receiver 840 . Similarly, such filtering could also serve to reject invalid transmissions and reduce noise.
  • FIG. 11 depicts a status display 120 of the unmanned vehicle platform 101 , according to non-limiting implementations, mounted on an exemplary chassis 180 by mechanical hardware 870 .
  • the status display 120 can be positioned in any suitable manner, for example such that it is visible to users from the exterior of the chassis 180 .
  • indicator lights 880 - 920 are mounted to a single printed circuit board.
  • the user interface module 50 can comprise the status display 120 .
  • Exemplary functions of the indicator lights 880 - 920 include, but are not limited to: indicating the presence of main electronics power 900 , indication of communications failure 910 , indication of use of power source selection 880 , depiction of the state of charge of an onboard power source 890 , depiction of overall system status 920 or the like.
  • the user interface module 50 can also be enabled receive inputs, and the portion of the chassis 180 to which the status display 120 is mounted can be enabled for quick replacement to match different physical layouts of the status display 120 can optionally incorporate input devices such as mode switches or adjustment knobs or the like.
  • FIG. 12 depicts a program layout of vehicle control firmware of the unmanned vehicle platform 101 , according to non-limiting implementations.
  • the control link 20 provides full-duplex serial communication to the system 301 , including error detection.
  • the system 301 of unmanned vehicle platform 101 can receive messages which make up commands 930 or data requests 960 .
  • Commands 930 can affect vehicle settings and setpoints directly or can be pre-processed by additional modules such as built-in vehicle kinematic models 950 .
  • Vehicle settings and setpoints can be verified by a set of control loops 940 before being sent to secondary modules via the vehicle control network 60 .
  • the control loops 940 may also be capable of providing some degree of autonomy, for example when the sensor data 420 includes appropriate information.
  • Settings and setpoints can be stored in a central system state 1000 .
  • System state 1000 also contains data received from other modules located on the vehicle control network 60 .
  • Sensor data 420 may be raw data as received from the hardware, or filtered via analog and/or digital
  • the system 301 of the unmanned vehicle platform 101 can be monitored remotely by issuing data requests 960 .
  • Data requests 960 can be structured to require immediate responses from the system 301 , or can be subscriptions for periodic updates of specific data.
  • the management of the varied requests and subscriptions can be handled by a subscription manager 970 .
  • the subscription manager 970 is queried by a data scheduler 990 which uses this subscription information and the system state 1000 to produce data 980 for the control link 20 . In this way, data 980 can thus be produced for the device on the other end of the control link 20 without continual requests for such data, thereby lowering the inbound bandwidth requirements.
  • FIG. 13 depicts a control flow within each module attached to the vehicle control network 60 of the unmanned vehicle platform 101 , according to non-limiting implementations.
  • a given module issues requests for information 1020 from the central control module 30 via the vehicle control network 60 .
  • this information may be system status, while for the motor amplifier module 40 , this information may be safety limits.
  • the given module may then wait for this information to be provided in a loop 1030 or may continue execution.
  • the given module may not need to wait, but can continue on and process the information as it arrives.
  • a loop is then entered, wherein the given module receives updated information and commands 1040 , performs a variety of tasks 1050 , and then transmits information over the vehicle control network 60 .
  • each module may need to specifically address the outgoing data (in the case of a Serial Peripheral Interconnect (SPI), for example), or may be able to send it out as a broadcast, receivable by any module that requires such data (in the case of CAN).
  • SPI Serial Peripheral Interconnect
  • the implementation of the loop can be performed in any suitable manner, including but not limited to using a busy-wait structure, hardware timer interrupts, or one of many more complex scheduling strategies used by computer operating systems.
  • the unmanned vehicle platform 101 comprises a wheeled land vehicle.
  • the unmanned vehicle platform 101 is an unmanned platform, systems and modules described herein can be included in unmanned vehicles, manned vehicles, aquatic vehicles, amphibious vehicles, aeronautic vehicles any other suitable vehicle, and/or a combination, or the like.
  • FIG. 14 depicts an aquatic unmanned platform 1401 , according to non-limiting implementations.
  • the aquatic unmanned platform 1401 comprises a hull 120 a and attached framework 150 a which provides a stable buoyant platform upon which the rest of the aquatic unmanned platform 1401 is mounted.
  • a primary electrical enclosure 10 a comprises the primary control board 30 a and a primary battery 20 a, while an auxiliary electrical enclosure 90 a holds the auxiliary control board 70 a and an auxiliary battery 80 a.
  • Attached via shafts 160 a to both enclosures 10 a, 90 a are thruster assemblies 100 a with appropriate propellers 110 a for propelling the aquatic unmanned platform 1401 through an aquatic environment.
  • a status display 40 a and a long-range bidirectional communications system 50 a can each be attached to the primary electrical enclosure 10 a.
  • a plurality of additional sensors such as a camera system 60 a and a GPS system 130 a may also be emplaced on the hull 120 a . Sensors 60 a, 130 a may be mounted on mounts 140 a if required. It is otherwise appreciated that aquatic unmanned platform 1401 comprises a control system similar to the system 301 , and suitable associated modules.
  • FIG. 15 depicts an electrical architecture of unmanned aquatic vehicle 1401 , according to non-limiting implementations and represents an alternative architecture of parts of system 301 .
  • Separate control modules 485 a, 515 a are electrically connected via a suitable vehicle control network 500 a.
  • each module 485 a, 515 a comprises a motor driver 36 a 0 and its associated thruster 100 a.
  • a primary module 485 a is powered by a battery 2 a which has its power filtered, monitored, and distributed by a power system 490 a. Control of the system is done by the primary control board 30 a, which itself receives information from low-level sensors 340 a and communicates with other control modules via the vehicle control network 500 a.
  • the primary control board 30 a can interface with the user and other sensors in any suitable manner.
  • Auxiliary module 515 a comprises a dedicated battery 80 and power system 510 a, and is controlled via an auxiliary control board 70 a, which itself responds to commands over the vehicle control network 500 a.
  • Each power system 490 a , 510 a is enabled for self-monitoring and safety limiting, and can provide status updates as required to the relevant control board 30 a, 70 a of FIG. 14 .
  • system 301 can be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components.
  • ASICs application specific integrated circuits
  • EEPROMs electrically erasable programmable read-only memories
  • system 301 can be achieved using a computing apparatus that has access to a code memory (not shown) which stores computer-readable program code for operation of the computing apparatus.
  • the computer-readable program code could be stored on a computer readable storage medium which is fixed, tangible and readable directly by these components, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB drive).
  • the computer-readable program can be stored as a computer program product comprising a computer usable medium.
  • a persistent storage device can comprise the computer readable program code.
  • the computer-readable program code and/or computer usable medium can comprise a non-transitory computer-readable program code and/or non-transitory computer usable medium.
  • the computer-readable program code could be stored remotely but transmittable to these components via a modem or other interface device connected to a network (including, without limitation, the Internet) over a transmission medium.
  • the transmission medium can be either a non-mobile medium (e.g., optical and/or digital and/or analog communications lines) or a mobile medium (e.g., microwave, infrared, free-space optical or other transmission schemes) or a combination thereof.

Abstract

A distributed hardware system for unmanned vehicles is provided, comprising a plurality of electronic hardware modules in communication via a vehicle control network. Each module is enabled to: communicate with one another, issue requests for information from a central control module, and transmit data over the network in a common format to perform respective tasks; and at least one of: independently sense one or more of: a respective status of the distributed hardware system and at least one respective environmental parameter; and independently control the respective function of a vehicle. A portion of the modules can enabled to: be removed and inserted from the distributed hardware system as plug and play modules; and determine when at least one of the modules is removed/inserted from the distributed hardware system and transition to a corresponding state. The system also includes a power management system which includes capacity monitoring and hot-swap capabilities.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application claims priority from U.S. Patent Application No. 61/282,991 filed on May 5, 2010, the contents being incorporated herein by reference.
  • FIELD
  • The specification relates generally to unmanned vehicles (“UVs”), and specifically to a distributed hardware architecture which can provide unmanned vehicles with a high degree of reliability and upgradeability.
  • BACKGROUND
  • Autonomous unmanned vehicle systems have existed in research labs for decades, and are now seeing increasing use outside of these controlled environments. Systems which were considered reliable from an experimental standpoint are now viewed as quite fragile when they are subjected to harsh environmental conditions and intensive use. They were originally only operated by those who designed them; they are now being placed in the hands of less technically adept individuals. Though many industrial or military grade UVs exist which can operate in such settings, they tend to be prohibitively expensive for most users.
  • Additionally, these systems were originally developed in a custom or low-production volume manner, where careful attention could be paid to individual units as they are constructed. As unmanned systems begin to be mass-produced, key components will need to be easily upgradable, without requiring major system architecture changes for each improvement. At the moment, the nature of many UVs precludes this. Many fully-closed systems exist wherein upgrades can only be performed by the manufacturer. Likewise, a great number of “modular” robotics platforms and hardware are on the market, but such hardware often requires a significant amount of effort by the user to integrate; they are not “plug-and-play”.
  • It is therefore desirable to implement a hardware system architecture which is robust to failure, easy to use, and easily upgradeable as design improvements are made.
  • SUMMARY
  • It is an object of the present invention to increase the robustness and ease of use of unmanned vehicles. As well, it is a further object to allow unmanned vehicles to be upgraded easily by the user, without requiring hardware to be returned to the manufacturer or the user to possess highly technical skills.
  • The present invention is comprised of an unmanned vehicle platform with a set of components which are known to be applicable by those skilled in the art. These components may include actuators such as DC drive motors, pan/tilt sensor mounts, or standalone manipulator devices. Components may also include sensing modules such as scanning laser rangefinders, passive environmental sensors, inertial measurement units, drive encoders, camera assemblies, and global positioning systems. Finally, computing and communication modules such as processors, memory, 802.11 transceivers, point-to-point wireless control hardware, and hardwired user interfaces may also be included.
  • Each component is mounted either external to or within a vehicle platform, depending on specific component requirements. Sensors such as cameras or laser rangefinders tend to be mounted externally, while inertial measurement units, drive systems, and computational hardware can be mounted internally. The vehicle platform should be constructed to protect any internally mounted devices from harsh environmental conditions. Methods for this protection are well known to those in the field of electromechanical design.
  • The platform itself can incorporate one of many possible methods of moving through the environment. It can be an unmanned surface vehicle capable of navigating over water, an unmanned ground vehicle based on an existing manned vehicle chassis, a custom unmanned ground vehicle, or any other type of unmanned chassis known to the field. In an exemplary implementation, the platform is a custom all-electric 6×6 off-road chassis driven by brushed DC motors. However, in other implementations the platform can comprise any suitable platform including but not limited to unmanned vehicles, manned vehicles, aquatic vehicles, amphibious vehicles, aeronautic vehicles any other suitable vehicle, and/or a combination, or the like. In the off-road chassis implementation, steering can be achieved by a method which is known as “differential drive” to those skilled in the art. The entirety of the internal electronics and drive train is protected from the environment.
  • Key in the invention is the use of a managed power system to improve robustness and usability. As well as applying known methods to estimate power usage and battery capacity, the managed power system can be enabled to allow users to perform a tool less “hot-swap” of batteries if desired, allowing system runtime to be extended indefinitely with only intermittent interruptions to operation by battery changes and no interruptions to sensor or computational power.
  • The system also separates key hardware such as communications devices, power amplifiers, user interface hardware, and control processors into discrete modules linked via a central vehicle control network. An example implementation of this control network uses the well-known CAN (Controller Area Network) standard, which is commonly used in the automotive and aerospace sector. Each module can communicate with any other module on the network, and the network is structured such that the highest priority messages always make it to their recipients without requiring retransmission.
  • These discrete modules can be upgraded in the field without requiring manufacturer service. Additionally, since they exchange information in a common, well-defined manner, users do not have to modify any of the modules in a system when upgrading
  • An aspect of the specification provides a distributed hardware system for controlling a vehicle, comprising: a network; a central control module for controlling the distributed hardware system; a plurality of electronic hardware modules in communication with the central control module via the network, each of the plurality of electronic hardware modules enabled to: communicate with one another via the network; issue requests for information from the central control module via network; transmit data over the network in a common format to perform tasks respective to a respective function; and at least one of: independently sense one or more of: a respective status of the distributed hardware system and at least one respective environmental parameter; and
  • independently control the respective function of the vehicle, and at least a portion of the plurality of electronic hardware modules enabled to: be removed and inserted from the distributed hardware system as plug and play modules; and determine when at least one of the plurality of electronic hardware modules is removed or inserted from the distributed hardware system and transition to a corresponding state.
  • The distributed hardware system can further comprise at least one power source. The at least one power source can comprise at least two batteries and respective battery bins enabled to independently open such that a hot swap of a respective battery can be performed.
  • The control module can be enabled to control power to each of the plurality of electronic hardware modules. The distributed hardware system can further comprise at least a first power source powering the distributed hardware system and a second power source, wherein one or more of the control module and at least one of the plurality of electronic hardware modules can be further enabled to: determine that the first power source is no longer able to power the distributed hardware system; and implement a power down transition in the distributed hardware system such that powering of the distributed hardware system is switched to the second power source and a hot swap sequence can be implemented to remove the first power source and insert a third power source. The power down transition can comprise a motor power down transition, The one or more of the control module and at least one of the plurality of electronic hardware modules can be further enabled to enter a low power state until the hot swap sequence occurs.
  • The distributed hardware system can further comprise at least one sensor for sensing at least one of the respective status of the distributed hardware system and the at least one respective environmental parameter, wherein a respective one of the plurality of electronic hardware modules can be enabled for communication with the at least one sensor.
  • At least one of the plurality of electronic hardware modules can comprise a motor amplifier module for controlling a motor of the vehicle.
  • At least one of the plurality of electronic hardware modules can comprise a radio frequency (RF) module enabled to receive command data from a remote control system, translate the command data to the common format and communicate translated command data over the network.
  • At least one of the plurality of electronic hardware modules can comprise a remote control receiver enabled to receive command data from an off-the-shelf remote control receiver, translate the command data to the common format and communicate translated commands over the network.
  • At least one of the plurality of electronic hardware modules can comprise a user interface module enabled to at least one of receive command data from an input device and convey system data to a user.
  • The network can comprise at least one of a vehicle control network and a communication bus.
  • The distributed hardware system can further comprise at least one of a battery charging system and at least one motor.
  • The central control module can be enabled to communicate with a high level computing system via a control link.
  • The central control module can be enabled to store at least one of: system state information received from the plurality of electronic hardware modules; setting data; setpoint data; and a combination thereof.
  • BRIEF DESCRIPTIONS OF THE DRAWINGS
  • For a better understanding of the various implementations described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which:
  • FIG. 1 depicts external characteristics features of an unmanned vehicle platform, according to non-limiting implementations.
  • FIGS. 2 a and 2 b depict two possible arrangements of internal modules of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 3 is a depiction of a possible hot-swap capable battery receptacle
  • FIG. 4 depicts configuration of electronic modules and device network of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations
  • FIG. 5 depicts a configuration of a central control module of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 6 depicts a configuration of a motor amplifier module of the unmanned vehicle platform, according to non-limiting implementations.
  • FIG. 7 depicts a process flow for a power management system that can be implemented by the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 8 depicts a remote receiver module mounted to chassis 180 of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 9 depicts a configuration of an RF module of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 10 depicts a configuration of a remote receiver module of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 11 depicts a status display of the unmanned vehicle platform of FIG. 1, according to non-limiting implementations.
  • FIG. 12 depicts an example program layout of vehicle control firmware of each module attached to the unmanned vehicle platform of FIG. 1 via a central vehicle control network, according to non-limiting implementations.
  • FIG. 13 depicts another example program layout of vehicle control firmware of each module attached to the unmanned vehicle platform of FIG. 1 via a central vehicle control network, according to non-limiting implementations.
  • DETAILED DESCRIPTION
  • FIG. 1 depicts external features of an unmanned vehicle platform 101, according to non-limiting implementations. A chassis 180 and supporting external members 190 house or otherwise provide stable mounting points for sensors, computing systems, and other devices. Unmanned vehicle platform 101 is enabled to track trajectories by way of actuating a set of wheels 200, which in non-limiting depicted implementations are arranged in a differential-drive configuration. Devices may be mounted within the chassis 180 or external to it, on removable and modular plates 100 or affixed to bumpers 90.
  • For ease of access to devices mounted within the chassis, drawers 140 are securable from opening using, for example, a set of latches 130, and may be opened via handles 150, springs, or the like. Bumpers 90 may be designed to provide an ergonomic carrying method for the combination of the platform and any other attached devices. Batteries are accessible externally via the battery bays 210 which may incorporate a battery bay latch 230. In some implementations, if users do not wish to remove batteries for charging, they may be charged while still in the platform via charge connectors 220.
  • Unmanned vehicle platform 101 can comprise a set of controls mounted directly to the chassis. In depicted example implementations, unmanned vehicle platform 101 is enabled for activation/deactivation via a latching pushbutton 240 and can be emergency stopped manually via a safety pushbutton 170. Any other suitable method of controlling unmanned vehicle platform 101 is within the scope of present implementations, including but not limited to issuing commands from a computing system mounted within the drawers 140 and/or by sending commands to a remote control receiver module 110. A degree of feedback on the state of the system of the unmanned vehicle platform 101 can be provided via a status display 120.
  • Internally, unmanned vehicle platform 101 can comprise a plurality of possible operational modules, each of which may provide unmanned vehicle platform 101 with a different set of capabilities. FIGS. 2 a and 2 b shows two possible arrangements of internal modules. FIG. 2 a depicts a central control module 30 connected to a motor amplifier module 40 and a user interface module 50 by way of a vehicle control network 60. Vehicle control network 60 can comprise any suitable network hardware and topology, including but not limited to a communication bus (e.g. as depicted), the “CANBus” standard (which can used for its speed and robustness to noise), or the like. Any other suitable network hardware and topology is within the scope of present implementations, including any suitable network hardware and topology commonly in use.
  • Modules 30, 40, 50 can also be enabled to receive commands from other systems not on the vehicle control network 60. For example, in non-limiting exemplary implementations, the central control module 30 can be connected via a control link 20 to a high-level computing system 10, over which it reports status, sends sensor data, and receives commands. The embodiment as shown uses a wired serial point-to-point connection as the control link 20 and an off-the-shelf laptop computer as the high-level computing system 10, but the system is not restricted to these choices. For example, the control link 20 could be a radio modem and the high-level computing system 10 could be a rack-mounted server. It is appreciated that any suitable control link and/or computing system is within the scope of present implementations.
  • FIG. 2 b is similar to FIG. 2 a, with like elements having like numbers, however the arrangement of modules of FIG. 2 b further comprises an RF (radio frequency) module 70 enabled to receive wireless emergency stop commands and an RC (radio control/radio receiver) module 80 enabled to transform signals from (for example) off-the-shelf radio control receivers to forms which are compatible with the vehicle control network 60. Expanding the platform capabilities in this way does not necessitate any changes to the rest of unmanned vehicle platform 101.
  • Attention is now directed to FIGS. 3 a, 3 b and 3 c depicts a toolless battery change process/sequence, according to non-limiting implementations; FIG. 3 a depicts a battery bin 260 in a closed position, FIG. 3 b depicts the battery bin 260 in an open position, and FIG. 3 c depicts the battery bin 260 in the open position with a battery 320 external to the battery bin 260. With reference to FIG. 3 a, the battery bin 260 is secured to the chassis 180 via pivots 290. The battery bin 260 incorporates integrated terminals 270 which elastically deform under the weight of the battery to maintain electrical connectivity. Also mounted to the battery bin 260 are two mechanical stops 250, 280 which constrain the pivoting of the battery bin 260 by contacting the chassis 180. A battery bay latch 230 may be used to lock the battery bin 260 in the closed position by engaging with a latch slot 300. Additionally, this battery bay latch 230 may include a sensor on it to allow the central control module 30 to determine when the battery bay 260 is opened or closed. If this is the case, the battery bay latch 230 is designed such that it cannot be closed when the battery bay 260 is open. Finally, a spring assembly 310 may add to the force keeping the battery terminals 330 mated with the integrated terminals 270 when the battery bin 260 is closed.
  • The battery 320 is removed by releasing the battery bay latch 230 and manually pivoting the battery bin 260 until the opening mechanical stop 250 makes contact with the chassis 180, as in FIG. 3 b. When the battery bay latch 230 includes a sensor capable of monitoring its state, the central control module 30 can execute appropriate instructions to handle the opening event (for example, as described below with reference to FIG. 7). The battery bin 260 may also be opened by a spring assembly or by other automated means. The battery 320 is then removed, as in FIG. 3 c. The removal process itself can be dependent on the battery form factor. In exemplary implementations, the removal process can take the form of a manually actuated pull strap.
  • The battery 320 is replaced by reversing the process. The battery 320 is slid into the battery bin 260 until the battery terminals 330 mate with the integrated terminals 270. The battery bin 260 is then pivoted closed until the closing mechanical stop 280 makes contact with the chassis 180. Finally, the battery bin 260 is secured with the battery bay latch 230. If the battery bay latch 230 includes a sensor capable of monitoring its state, the central control module 30 can now execute appropriate instructions to handle the closing event.
  • FIG. 4 depicts a system 301 of electronic modules and device network of unmanned vehicle platform 101, according to non-limiting implementations. The central control module 30 is powered by a power bus 460 which itself is fed from a plurality of power sources which may include one or more batteries 320 and/or an AC power supply 440 or the like. Batteries 320 used in unmanned vehicle platform 101 can be recharged without being removed by the battery charging system 430. The battery charging system 430 can indicate to the central control module 30 when the batteries 320 are being charged.
  • The central control module 30 can be enabled to shut off or turn on any subset of the available power sources, while the platform's power switch 470 shuts off all available power sources. The central control module 30 is further enabled to power the fuse panel 360, any internal modules 50, 70, 80, low-level sensors 390 and portions of the motor amplifier module 40. Incorporated into the low-level sensors 390 are a number of control feedback sensors which can be used to perform platform state estimation. Control feedback sensors can include but are not limited to inertial sensors 400 and encoders 410, where the encoders 410 can use any suitable sensing methods (e.g. optical, magnetic, mechanical or the like). In the latter case, the encoders 410 can be physically connected to the drive train of the chassis 180, providing a direct observation of various speeds within the drive train. These feedback sensors 400 and encoders 410 may be used to improve the trajectory tracking performance of the unmanned vehicle platform 101 and/or may be restricted to observing changes in a state of the unmanned vehicle platform 101.
  • The payload bay 340 is generally comprised of components that a user interacts with during operation of the unmanned vehicle platform 101. In depicted implementations, the payload bay 340 contains the high-level computing system 10, the fuse panel 360 and a plurality of payloads 350. Payloads 350 can comprise additional sensors, additional actuators, communications devices, additional computing hardware, and any other suitable equipment, including equipment that can commonly be found on other unmanned vehicle platforms.
  • The high-level computing system 10 is connected using appropriate interfaces to the payloads 350. The fuse panel 360 routes power from the central control module 30 to the high-level computing system 10 and the payloads 350, and may have multiple fused connectors for a variety of different voltage levels and current ratings. Any suitable software can be deployed to the high-level computing system 10.
  • The central control module 30 communicates via the vehicle control network 60 with secondary modules 40, 50, 70, 80 as appropriate. Communications may happen sporadically or at a regular frequency. When the latter, one or more modules can be enabled to require a given message frequency to remain operational, which can improve the safety of the unmanned vehicle platform 101. For example, such an implementation can be useful when receiving commands via the remote receiver module 80, monitoring remote switches via the RF module 50 and/or commanding motor motion via the motor amplifier module 40. However, such a requirement on message frequency can be less useful with other modules such as the user interface module 70. Furthermore, it is appreciated that use of the phrases “require” and “requirement” refer only to particular implementations and the given message frequency remaining operational is to be construed as being required in all implementations and/or to be unduly limiting.
  • FIG. 5 depicts a configuration of a central control module 30 of the unmanned vehicle platform 101, according to non-limiting implementations. The main components of the central control module comprise a power source selection module 490, a power regulation module 510 and an embedded processor 530. The power source selection module 490 is enabled to select which of the available power sources within the power bus 460 is fed into the power regulation module 510. This selection is done based on the information made available by the monitoring module 480. The power regulation module 510 powers the embedded processor 530, the fuse panel 360 (including devices powered by the fuse panel), and any other devices which are connected to the vehicle control network 60.
  • As well, the battery detect switches 550 enable the power source selection module 490 to determine if the user is removing a battery 320 or if they have recently replaced one. With such information, the power source selection module 490 can minimize system downtime by ensuring that the unmanned vehicle platform 101 and/or the system 301 is powered from a reliable power source at all times. Optional display indicators, such as the status panel 120 and/or the battery-in-use indicators 540 can indicate which subset of power sources are being used at any given time.
  • A soft start module 520 may be used to limit the inrush current into the fuse panel 360 and other devices powered by the power regulation module 510. The status of each power source in the power bus 460 is monitored using corresponding monitoring modules 480. The monitoring modules 480 may retrieve any subset of temperature, voltage and current draw data or the like. The monitoring module 480 may also use this data to estimate the health of each power source in the power bus 460. This data can also report to the embedded processor 530 so that it can reduce power draw when necessary. The data may also be forwarded to the high level computing system 10 or retransmitted along the vehicle control network 60.
  • Each monitoring module 480 can be enabled to shut off power from its associated power source. There may also be a separate current sense module 500 that reports current draw data to the embedded processor 530. A power switch 470 is used to shut off all available power sources. The embedded processor 530 also collects sensor data 520 from a plurality of sensors, which may include, but is not limited to, devices such as a tilt-compensated compass, IR rangefinders, angular rate gyros, and wheel encoders.
  • FIG. 6 depicts a configuration of a motor amplifier module 40 of the unmanned vehicle platform 101, according to non-limiting implementations. The motor amplifier module 40 comprises an embedded processor 590, a motor power source selection module 560 and any suitable ancillary components, for example any suitable ancillary components that can be determined according to electrical design principles. The embedded processor 590 can communicate with the central control module 30 and other modules in the system 301 using the vehicle control network 60. The power regulation module 510 located in the central control module 30 provides the power necessary to run the embedded processor 590. This power is transmitted along the same path as the vehicle control network 60. The embedded processor 590 can read battery voltages using the power monitoring system 570 and motor current draw using the current sense modules 580.
  • These measurements can be used for platform health monitoring, or can be incorporated further into the platform control system 301 to allow for more precise control strategies. The motors 380 are powered by sources selected by the motor power source selection module 560. Power to each motor 380 is controlled by the embedded processor 590. The embedded processor 590 can use any suitable strategy to regulate the power to each motor 380. In exemplary implementations, as depicted, each motor 380 is driven by an H-bridge circuit 600 which is controlled by a bridge driver 610. Each bridge driver 610 is in turn controlled by the embedded processor 590.
  • A physical E-stop 170 can be used to cut off power to parts of the system 301, if necessary, providing a robust safety system which is not dependent at all on firmware. For example the physical E-stop 170 can be monitored by the motor power selection module 560. When the physical E-stop 170 is activated, the motor power selection module 560 can shut off all power to the H-bridge circuits 600 and by extension halts the motors 380.
  • FIG. 7 depicts a process flow for a managing a power bus 460 that can be implemented by the unmanned vehicle platform 101, according to non-limiting implementations. The unmanned vehicle platform 101 starts in a power off state 620. When the main power switch 470 is turned on, a power-on transition occurs 630 and the central control module 30, as well as every other device powered by the power regulation module 510, is powered on. For a period of time, the electronics are powered by all available power sources 640. After a period of time, the embedded processor 530 instructs the power source selection module 490 to choose a single power source and a power source selection transition 650 occurs.
  • In the single-power state 660, the central control module 30, and every other device powered by the power regulation module 510, is powered by a single power source (e.g. a first battery of batteries 320). In some configurations the system 301 will remain powered by a secondary power source, such as a second battery of batteries 320, in addition to a source such as an AC power supply 440 in case the primary source is suddenly removed. After the power source selection transition 650 occurs, the motor power source selection module 560 turns on the power source to power the motors and a motor power transition 670 occurs. Once the motor power transition 670 has been completed, the unmanned vehicle platform 101 has entered its normal operation state 680.
  • A number of situations can cause the unmanned vehicle platform 101 to leave the normal operation state 680. Such situations may include the triggering of the battery detect switch 550, the battery state-of-charge dropping below a preset threshold, or the user swapping out a current power source/battery 320. If one of these situations occurs, the unmanned vehicle platform 101 leaves the normal operation state 680 and a motor power down transition 740 occurs. During the motor power down transition 740, the motor power source selection module 560 shuts down all power to the motors 380 and the system 301 then transitions into the motors powered down state 750. If the motor power down transition 740 occurred due to a low state-of-charge on the batteries 320 then the vehicle will undergo a state transition 730 to a low-power state 720.
  • In the low power state, the unmanned vehicle platform 101 waits until the charge on the battery 320 reaches a critically low level and another transition 710 occurs to a shut down state 700. The user may add a fresh battery 320 or an additional power source such as an AC power supply 440 to prevent the system 301 from entering the shut down state 700. In this case, the system 301 switches the new power source on, undergoes a recovery transition 760, and is powered by both the old and the new power source for a period of time 790. From this state, the system 301 would return to being powered by one source 660 by shutting the old source off and will eventually return to normal operation 680 as it did when first starting up.
  • In the situation where the unmanned vehicle platform 101 undergoes a motor power down transition 740 because the battery detect switch 550 had been triggered or the user is swapping out the current power source, a secondary power source transition 770 occurs and the unmanned vehicle platform 101 is powered by two power sources for a period of time 790. From this state 790, the unmanned vehicle platform 101 would shut off the old power source and return to being powered by one source 660. The unmanned vehicle platform 101 would then return to the normal operation state 680 as it did when first starting. If the user removes the only available power source, a shutdown transition 690 occurs and the unmanned vehicle platform 101 enters the shut down state 700 immediately.
  • FIG. 8 depicts detail of a remote receiver module 110 mounted to the chassis 180, according to non-limiting implementations. The remote receiver module 110 can comprise any suitable remote receivers, including but not limited to remote receivers enabled to improve performance, for example by altering an enclosure composition, adding external antennas 800 or the like.
  • FIG. 9 depicts a configuration of the RF module 70 of the unmanned vehicle platform 101, according to non-limiting implementations, which enables direct wireless control of the central control module 30. The RF module 70 comprises an RF antenna 800 that provides a modulated signal to the RF demodulator 810. The RF demodulator 810 sends out a string of data, as received by the antenna 800, to the decoder 820. The decoder 820 reads a serial bit stream and translates the data to a parallel bus. The parallel bus is read in by the embedded processor 830. The embedded processor 830 then encodes the data and communicates the encoded data over the vehicle control network 60. The entirety of this module is powered by the power regulation module 510. This configuration is only an example and the specifics of details such as modulation, frequency, and power are not to be construed as being particularly limiting.
  • FIG. 10 depicts a configuration of the remote receiver module 80 of the unmanned vehicle platform 101, according to non-limiting implementations. Remote receiver module 80 is enabled to translate data from, for example, off-the-shelf remote receivers to a common format, which enables many off-the-shelf remote receivers to be integrated with the unmanned vehicle platform 101 without changing the firmware or electrical system of the central control module 30. Such data can be transmitted over a 2.4 GHz band, or any other suitable radio band, or the like. The remote receiver module 80 can comprise (for example) an off-the-shelf remote control receiver 840 and an embedded processor 860. The remote control receiver 840 and the embedded processor 860 are powered by the power regulation module 510. The remote control receiver 840 demodulates transmissions sent by the remote control transmitter 850. The remote control transmitter 850 can be handheld, stationary, or in any other physical configuration.
  • The remote control receiver 840 forwards the demodulated transmission to the embedded processor 860. The demodulated transmission can consist of servo pulses, pulse width modulation signals, a serial bit stream, or any other number of transmission formats as known to those skilled in the art, or the like. The embedded processor 860 interprets the demodulated transmission and reformats the received data into a fowl which can be transmitted on the vehicle control network 60. The embedded processor 860 can also be enabled to conduct some filtering on the demodulated transmission. Such filtering can comprise detecting when the remote control transmitter 850 is out of range of the remote control receiver 840. Similarly, such filtering could also serve to reject invalid transmissions and reduce noise.
  • FIG. 11 depicts a status display 120 of the unmanned vehicle platform 101, according to non-limiting implementations, mounted on an exemplary chassis 180 by mechanical hardware 870. The status display 120 can be positioned in any suitable manner, for example such that it is visible to users from the exterior of the chassis 180. In exemplary depicted non-limiting implementations, indicator lights 880-920 are mounted to a single printed circuit board. Furthermore, the user interface module 50 can comprise the status display 120. Exemplary functions of the indicator lights 880-920 include, but are not limited to: indicating the presence of main electronics power 900, indication of communications failure 910, indication of use of power source selection 880, depiction of the state of charge of an onboard power source 890, depiction of overall system status 920 or the like.
  • The user interface module 50 can also be enabled receive inputs, and the portion of the chassis 180 to which the status display 120 is mounted can be enabled for quick replacement to match different physical layouts of the status display 120 can optionally incorporate input devices such as mode switches or adjustment knobs or the like.
  • FIG. 12 depicts a program layout of vehicle control firmware of the unmanned vehicle platform 101, according to non-limiting implementations. The control link 20 provides full-duplex serial communication to the system 301, including error detection. The system 301 of unmanned vehicle platform 101 can receive messages which make up commands 930 or data requests 960. Commands 930 can affect vehicle settings and setpoints directly or can be pre-processed by additional modules such as built-in vehicle kinematic models 950. Vehicle settings and setpoints can be verified by a set of control loops 940 before being sent to secondary modules via the vehicle control network 60. The control loops 940 may also be capable of providing some degree of autonomy, for example when the sensor data 420 includes appropriate information. Settings and setpoints can be stored in a central system state 1000. System state 1000 also contains data received from other modules located on the vehicle control network 60. Sensor data 420 may be raw data as received from the hardware, or filtered via analog and/or digital means.
  • The system 301 of the unmanned vehicle platform 101 can be monitored remotely by issuing data requests 960. Data requests 960 can be structured to require immediate responses from the system 301, or can be subscriptions for periodic updates of specific data. The management of the varied requests and subscriptions can be handled by a subscription manager 970. The subscription manager 970 is queried by a data scheduler 990 which uses this subscription information and the system state 1000 to produce data 980 for the control link 20. In this way, data 980 can thus be produced for the device on the other end of the control link 20 without continual requests for such data, thereby lowering the inbound bandwidth requirements.
  • FIG. 13 depicts a control flow within each module attached to the vehicle control network 60 of the unmanned vehicle platform 101, according to non-limiting implementations. Upon module start-up 1010, a given module issues requests for information 1020 from the central control module 30 via the vehicle control network 60. For the user interface module 50, this information may be system status, while for the motor amplifier module 40, this information may be safety limits. The given module may then wait for this information to be provided in a loop 1030 or may continue execution.
  • For non-critical information, the given module may not need to wait, but can continue on and process the information as it arrives. A loop is then entered, wherein the given module receives updated information and commands 1040, performs a variety of tasks 1050, and then transmits information over the vehicle control network 60. Depending on the specifics of the vehicle control network 60, each module may need to specifically address the outgoing data (in the case of a Serial Peripheral Interconnect (SPI), for example), or may be able to send it out as a broadcast, receivable by any module that requires such data (in the case of CAN). The implementation of the loop can be performed in any suitable manner, including but not limited to using a busy-wait structure, hardware timer interrupts, or one of many more complex scheduling strategies used by computer operating systems.
  • Referring briefly back to FIG. 1, it is appreciated that the unmanned vehicle platform 101 comprises a wheeled land vehicle. However, in other type of vehicles are within the scope of present implementations. For example, while the unmanned vehicle platform 101 is an unmanned platform, systems and modules described herein can be included in unmanned vehicles, manned vehicles, aquatic vehicles, amphibious vehicles, aeronautic vehicles any other suitable vehicle, and/or a combination, or the like.
  • For example, attention is next directed to FIG. 14 which depicts an aquatic unmanned platform 1401, according to non-limiting implementations. The aquatic unmanned platform 1401 comprises a hull 120 a and attached framework 150 a which provides a stable buoyant platform upon which the rest of the aquatic unmanned platform 1401 is mounted. A primary electrical enclosure 10 a comprises the primary control board 30 a and a primary battery 20 a, while an auxiliary electrical enclosure 90 a holds the auxiliary control board 70 a and an auxiliary battery 80 a. Attached via shafts 160 a to both enclosures 10 a, 90 a are thruster assemblies 100 a with appropriate propellers 110 a for propelling the aquatic unmanned platform 1401 through an aquatic environment. A status display 40 a and a long-range bidirectional communications system 50 a can each be attached to the primary electrical enclosure 10 a. A plurality of additional sensors such as a camera system 60 a and a GPS system 130 a may also be emplaced on the hull 120 a. Sensors 60 a, 130 a may be mounted on mounts 140 a if required. It is otherwise appreciated that aquatic unmanned platform 1401 comprises a control system similar to the system 301, and suitable associated modules.
  • In particular, attention is directed to FIG. 15 which depicts an electrical architecture of unmanned aquatic vehicle 1401, according to non-limiting implementations and represents an alternative architecture of parts of system 301. Separate control modules 485 a, 515 a are electrically connected via a suitable vehicle control network 500 a. In each module 485 a, 515 a comprises a motor driver 36 a 0 and its associated thruster 100 a. A primary module 485 a is powered by a battery 2 a which has its power filtered, monitored, and distributed by a power system 490 a. Control of the system is done by the primary control board 30 a, which itself receives information from low-level sensors 340 a and communicates with other control modules via the vehicle control network 500 a. The primary control board 30 a can interface with the user and other sensors in any suitable manner. Auxiliary module 515 a comprises a dedicated battery 80 and power system 510 a, and is controlled via an auxiliary control board 70 a, which itself responds to commands over the vehicle control network 500 a. Each power system 490 a, 510 a is enabled for self-monitoring and safety limiting, and can provide status updates as required to the relevant control board 30 a, 70 a of FIG. 14.
  • Those skilled in the art will appreciate that in some implementations, the functionality of system 301 can be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components. In other implementations, the functionality of system 301 can be achieved using a computing apparatus that has access to a code memory (not shown) which stores computer-readable program code for operation of the computing apparatus. The computer-readable program code could be stored on a computer readable storage medium which is fixed, tangible and readable directly by these components, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB drive). Furthermore, it is appreciated that the computer-readable program can be stored as a computer program product comprising a computer usable medium. Further, a persistent storage device can comprise the computer readable program code. It is yet further appreciated that the computer-readable program code and/or computer usable medium can comprise a non-transitory computer-readable program code and/or non-transitory computer usable medium. Alternatively, the computer-readable program code could be stored remotely but transmittable to these components via a modem or other interface device connected to a network (including, without limitation, the Internet) over a transmission medium. The transmission medium can be either a non-mobile medium (e.g., optical and/or digital and/or analog communications lines) or a mobile medium (e.g., microwave, infrared, free-space optical or other transmission schemes) or a combination thereof.
  • While the foregoing written description enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The present specification should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the claims appended hereto.

Claims (16)

1. A distributed hardware system for controlling a vehicle, comprising:
a network;
a central control module for controlling the distributed hardware system;
a plurality of electronic hardware modules in communication with the central control module via the network, each of the plurality of electronic hardware modules enabled to:
communicate with one another via the network;
issue requests for information from the central control module via network;
transmit data over the network in a common format to perform tasks respective to a respective function; and at least one of:
independently sense one or more of: a respective status of the distributed hardware system and at least one respective environmental parameter; and
independently control the respective function of the vehicle, and at least a portion of the plurality of electronic hardware modules enabled to:
be physically removed and physically inserted from the distributed hardware system as plug and play modules; and
determine when at least one of the plurality of electronic hardware modules is physically removed or physically inserted from the distributed hardware system and transition to a corresponding state.
2. The distributed hardware system of claim 1, further comprising at least one power source.
3. The distributed hardware system of claim 2, wherein the at least one power source comprises at least two batteries and respective battery bins enabled to independently open such that a hot swap of a respective battery can be performed.
4. The distributed hardware system of claim 1, wherein the control module is enabled to control power to each of the plurality of electronic hardware modules.
5. The distributed hardware system of claim 4, further comprising at least a first power source powering the distributed hardware system and a second power source, wherein one or more of the control module and at least one of the plurality of electronic hardware modules is further enabled to:
determine that the first power source is no longer able to power the distributed hardware system; and
implement a power down transition in the distributed hardware system such that powering of the distributed hardware system is switched to the second power source and a hot swap sequence can be implemented to remove the first power source and insert a third power source.
6. The distributed hardware system of claim 5, wherein the power down transition comprises a motor power down transition,
7. The distributed hardware system of claim 5, wherein the one or more of the control module and at least one of the plurality of electronic hardware modules is further enabled to enter a low power state until the hot swap sequence occurs.
8. The distributed hardware system of claim 1, further comprising at least one sensor for sensing at least one of the respective status of the distributed hardware system and the at least one respective environmental parameter, wherein a respective one of the plurality of electronic hardware modules is enabled for communication with the at least one sensor.
9. The distributed hardware system of claim 1, wherein at least one of the plurality of electronic hardware modules comprises a motor amplifier module for controlling a motor of the vehicle.
10. The distributed hardware system of claim 1, wherein at least one of the plurality of electronic hardware modules comprises a radio frequency (RF) module enabled to receive command data from a remote control system, translate the command data to the common format and communicate translated command data over the network.
11. The distributed hardware system of claim 1, wherein at least one of the plurality of electronic hardware modules comprises a remote control receiver enabled to receive command data from an off-the-shelf remote control receiver, translate the command data to the common format and communicate translated commands over the network.
12. The distributed hardware system of claim 1, wherein at least one of the plurality of electronic hardware modules comprises a user interface module enabled to at least one of receive command data from an input device and convey system data to a user.
13. The distributed hardware system of claim 1, wherein the network comprises at least one of a vehicle control network and a communication bus.
14. The distributed hardware system of claim 1, further comprising at least one of a battery charging system and at least one motor.
15. The distributed hardware system of claim 1, wherein the central control module is enabled to communicate with a high level computing system via a control link.
16. The distributed hardware system of claim 1, wherein the central control module is enabled to store at least one of:
system state information received from the plurality of electronic hardware modules;
setting data;
setpoint data; and
a combination thereof.
US13/099,445 2010-05-04 2011-05-03 Distributed hardware architecture for unmanned vehicles Active 2031-07-20 US8548646B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/099,445 US8548646B1 (en) 2010-05-04 2011-05-03 Distributed hardware architecture for unmanned vehicles

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28299110P 2010-05-04 2010-05-04
US13/099,445 US8548646B1 (en) 2010-05-04 2011-05-03 Distributed hardware architecture for unmanned vehicles

Publications (2)

Publication Number Publication Date
US20130245857A1 true US20130245857A1 (en) 2013-09-19
US8548646B1 US8548646B1 (en) 2013-10-01

Family

ID=49158400

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/099,445 Active 2031-07-20 US8548646B1 (en) 2010-05-04 2011-05-03 Distributed hardware architecture for unmanned vehicles

Country Status (1)

Country Link
US (1) US8548646B1 (en)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150134199A1 (en) * 2013-11-08 2015-05-14 The U.S.A. As Represented By The Administrator Of The National Aeronautics And Space Administration Component control system for a vehicle
WO2015076736A1 (en) 2013-11-21 2015-05-28 Scania Cv Ab System configuration and method to make possible the autonomous operation of a vehicle
WO2016057277A1 (en) * 2014-10-08 2016-04-14 Faro Technologies, Inc. Coordinate measurement machine with redundant energy sources
US10504306B1 (en) 2014-05-20 2019-12-10 State Farm Mutual Automobile Insurance Company Accident response using autonomous vehicle monitoring
US10500955B2 (en) * 2014-12-30 2019-12-10 Visteon Global Technologies, Inc. Automatic upgrade of a vehicle-based processor based on a physical component change
US10545024B1 (en) 2016-01-22 2020-01-28 State Farm Mutual Automobile Insurance Company Autonomous vehicle trip routing
US10679497B1 (en) 2016-01-22 2020-06-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle application
US10719886B1 (en) 2014-05-20 2020-07-21 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
US10723312B1 (en) 2014-07-21 2020-07-28 State Farm Mutual Automobile Insurance Company Methods of theft prevention or mitigation
US10748419B1 (en) 2015-08-28 2020-08-18 State Farm Mutual Automobile Insurance Company Vehicular traffic alerts for avoidance of abnormal traffic conditions
GB2564473B (en) * 2017-07-13 2020-09-16 Blue Bear Systems Res Ltd Unmanned air vehicles
US10793369B2 (en) 2017-07-12 2020-10-06 A9.Com, Inc. Conveyor system for autonomous robot
US10821971B1 (en) 2014-11-13 2020-11-03 State Farm Mutual Automobile Insurance Company Autonomous vehicle automatic parking
US10880412B1 (en) * 2017-08-21 2020-12-29 Clearpath Robotics Inc. Systems and methods for communicating between a fleet of robots and a fleet manager
US11086328B2 (en) 2016-08-23 2021-08-10 A9.Com, Inc. Autonomous cart for manufacturing and warehouse applications
US11242051B1 (en) 2016-01-22 2022-02-08 State Farm Mutual Automobile Insurance Company Autonomous vehicle action communications
US11282143B1 (en) 2014-05-20 2022-03-22 State Farm Mutual Automobile Insurance Company Fully autonomous vehicle insurance pricing
US11441916B1 (en) 2016-01-22 2022-09-13 State Farm Mutual Automobile Insurance Company Autonomous vehicle trip routing
US11580604B1 (en) 2014-05-20 2023-02-14 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11669090B2 (en) 2014-05-20 2023-06-06 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11719545B2 (en) 2016-01-22 2023-08-08 Hyundai Motor Company Autonomous vehicle component damage and salvage assessment
US11760221B2 (en) 2017-06-27 2023-09-19 A9.Com, Inc. Charging systems and methods for autonomous carts

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9511639B2 (en) 2014-02-20 2016-12-06 Ontario Drive and Gear, Ltd. Vehicle drive unit and remotely controllable vehicle therewith
US10058031B1 (en) 2015-02-28 2018-08-28 Hydro-Gear Limited Partnership Lawn tractor with electronic drive and control system
US9980434B1 (en) 2015-02-28 2018-05-29 Hydro-Gear Limited Partnership Network for placing a plurality of lawnmower components in operative communication
US10656932B2 (en) * 2016-07-12 2020-05-19 United Radio, Inc. Radio updating method
DE102016116128A1 (en) 2016-08-30 2018-03-01 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Apparatus and method for integrating an electrical element into an electrical circuit under load

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668318B1 (en) * 2000-05-31 2003-12-23 Xybernaut Corp. System and method for loading one of a plurality of operating systems and adjusting the operating frequency accordingly using transferable core computer that recognizes a system environment
US20080009965A1 (en) * 2006-07-05 2008-01-10 Battelle Energy Alliance, Llc Autonomous Navigation System and Method
US20080009966A1 (en) * 2006-07-05 2008-01-10 Battelle Energy Alliance, Llc Occupancy Change Detection System and Method
US20080028237A1 (en) * 2006-07-26 2008-01-31 Roadnarrows, Llc Power Management Using Integrated Data and Power Interfaces
US20080291879A1 (en) * 2007-05-22 2008-11-27 Duff Adam C Man-Portable Incident Command Platform
US20090160255A1 (en) * 2007-12-20 2009-06-25 Grady John K Uninterruptible power supply
US20100060604A1 (en) * 2007-11-01 2010-03-11 Andrew Jan Zwart System for impulse input of commands, control arguments and data

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668318B1 (en) * 2000-05-31 2003-12-23 Xybernaut Corp. System and method for loading one of a plurality of operating systems and adjusting the operating frequency accordingly using transferable core computer that recognizes a system environment
US20080009965A1 (en) * 2006-07-05 2008-01-10 Battelle Energy Alliance, Llc Autonomous Navigation System and Method
US20080009966A1 (en) * 2006-07-05 2008-01-10 Battelle Energy Alliance, Llc Occupancy Change Detection System and Method
US20080028237A1 (en) * 2006-07-26 2008-01-31 Roadnarrows, Llc Power Management Using Integrated Data and Power Interfaces
US20080291879A1 (en) * 2007-05-22 2008-11-27 Duff Adam C Man-Portable Incident Command Platform
US20100060604A1 (en) * 2007-11-01 2010-03-11 Andrew Jan Zwart System for impulse input of commands, control arguments and data
US20090160255A1 (en) * 2007-12-20 2009-06-25 Grady John K Uninterruptible power supply

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Eric Park, Linda Kobayashi and Susan Lee:"Extensible Hardware Architecture for Mobile Robots" Intelligent Robotics Group NASA Ames Research Center *
Eric Park, Linda Kobayashi and Susan Lee:"Extensible Hardware Architecture for Mobile Robots" Intelligent Robotics Group, 04/18/2005 *

Cited By (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150134199A1 (en) * 2013-11-08 2015-05-14 The U.S.A. As Represented By The Administrator Of The National Aeronautics And Space Administration Component control system for a vehicle
US9266518B2 (en) * 2013-11-08 2016-02-23 GM Global Technology Operations LLC Component control system for a vehicle
WO2015076736A1 (en) 2013-11-21 2015-05-28 Scania Cv Ab System configuration and method to make possible the autonomous operation of a vehicle
US11386501B1 (en) 2014-05-20 2022-07-12 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
US11238538B1 (en) 2014-05-20 2022-02-01 State Farm Mutual Automobile Insurance Company Accident risk model determination using autonomous vehicle operating data
US11127083B1 (en) 2014-05-20 2021-09-21 State Farm Mutual Automobile Insurance Company Driver feedback alerts based upon monitoring use of autonomous vehicle operation features
US11080794B2 (en) 2014-05-20 2021-08-03 State Farm Mutual Automobile Insurance Company Autonomous vehicle technology effectiveness determination for insurance pricing
US11062396B1 (en) 2014-05-20 2021-07-13 State Farm Mutual Automobile Insurance Company Determining autonomous vehicle technology performance for insurance pricing and offering
US11282143B1 (en) 2014-05-20 2022-03-22 State Farm Mutual Automobile Insurance Company Fully autonomous vehicle insurance pricing
US10504306B1 (en) 2014-05-20 2019-12-10 State Farm Mutual Automobile Insurance Company Accident response using autonomous vehicle monitoring
US11023629B1 (en) 2014-05-20 2021-06-01 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature evaluation
US11869092B2 (en) 2014-05-20 2024-01-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11288751B1 (en) 2014-05-20 2022-03-29 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11348182B1 (en) 2014-05-20 2022-05-31 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US10685403B1 (en) 2014-05-20 2020-06-16 State Farm Mutual Automobile Insurance Company Fault determination with autonomous feature use monitoring
US11010840B1 (en) 2014-05-20 2021-05-18 State Farm Mutual Automobile Insurance Company Fault determination with autonomous feature use monitoring
US10719886B1 (en) 2014-05-20 2020-07-21 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
US10719885B1 (en) 2014-05-20 2020-07-21 State Farm Mutual Automobile Insurance Company Autonomous feature use monitoring and insurance pricing
US10726499B1 (en) 2014-05-20 2020-07-28 State Farm Mutual Automoible Insurance Company Accident fault determination for autonomous vehicles
US11436685B1 (en) 2014-05-20 2022-09-06 State Farm Mutual Automobile Insurance Company Fault determination with autonomous feature use monitoring
US10726498B1 (en) 2014-05-20 2020-07-28 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
US10963969B1 (en) 2014-05-20 2021-03-30 State Farm Mutual Automobile Insurance Company Autonomous communication feature use and insurance pricing
US10748218B2 (en) 2014-05-20 2020-08-18 State Farm Mutual Automobile Insurance Company Autonomous vehicle technology effectiveness determination for insurance pricing
US11710188B2 (en) 2014-05-20 2023-07-25 State Farm Mutual Automobile Insurance Company Autonomous communication feature use and insurance pricing
US11669090B2 (en) 2014-05-20 2023-06-06 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11127086B2 (en) 2014-05-20 2021-09-21 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
US11580604B1 (en) 2014-05-20 2023-02-14 State Farm Mutual Automobile Insurance Company Autonomous vehicle operation feature monitoring and evaluation of effectiveness
US11069221B1 (en) 2014-07-21 2021-07-20 State Farm Mutual Automobile Insurance Company Methods of facilitating emergency assistance
US10997849B1 (en) 2014-07-21 2021-05-04 State Farm Mutual Automobile Insurance Company Methods of facilitating emergency assistance
US10974693B1 (en) 2014-07-21 2021-04-13 State Farm Mutual Automobile Insurance Company Methods of theft prevention or mitigation
US10825326B1 (en) 2014-07-21 2020-11-03 State Farm Mutual Automobile Insurance Company Methods of facilitating emergency assistance
US11257163B1 (en) 2014-07-21 2022-02-22 State Farm Mutual Automobile Insurance Company Methods of pre-generating insurance claims
US11068995B1 (en) 2014-07-21 2021-07-20 State Farm Mutual Automobile Insurance Company Methods of reconstructing an accident scene using telematics data
US10723312B1 (en) 2014-07-21 2020-07-28 State Farm Mutual Automobile Insurance Company Methods of theft prevention or mitigation
US11634102B2 (en) 2014-07-21 2023-04-25 State Farm Mutual Automobile Insurance Company Methods of facilitating emergency assistance
US11634103B2 (en) 2014-07-21 2023-04-25 State Farm Mutual Automobile Insurance Company Methods of facilitating emergency assistance
US11030696B1 (en) 2014-07-21 2021-06-08 State Farm Mutual Automobile Insurance Company Methods of providing insurance savings based upon telematics and anonymous driver data
US10832327B1 (en) 2014-07-21 2020-11-10 State Farm Mutual Automobile Insurance Company Methods of providing insurance savings based upon telematics and driving behavior identification
US11565654B2 (en) 2014-07-21 2023-01-31 State Farm Mutual Automobile Insurance Company Methods of providing insurance savings based upon telematics and driving behavior identification
US10378878B2 (en) 2014-10-08 2019-08-13 Faro Technologies, Inc. Coordinate measurement machine with redundant energy sources
GB2545146B (en) * 2014-10-08 2018-10-31 Faro Tech Inc Coordinate measurement machine with redundant energy sources
GB2545146A (en) * 2014-10-08 2017-06-07 Faro Tech Inc Coordinate measurement machine with redundant energy sources
US9909857B2 (en) 2014-10-08 2018-03-06 Faro Technologies, Inc. Coordinate measurement machine with redundant energy sources
WO2016057277A1 (en) * 2014-10-08 2016-04-14 Faro Technologies, Inc. Coordinate measurement machine with redundant energy sources
US9651361B2 (en) 2014-10-08 2017-05-16 Faro Technologies, Inc. Coordinate measurement machine with redundant energy sources
US11748085B2 (en) 2014-11-13 2023-09-05 State Farm Mutual Automobile Insurance Company Autonomous vehicle operator identification
US11494175B2 (en) 2014-11-13 2022-11-08 State Farm Mutual Automobile Insurance Company Autonomous vehicle operating status assessment
US11720968B1 (en) 2014-11-13 2023-08-08 State Farm Mutual Automobile Insurance Company Autonomous vehicle insurance based upon usage
US11500377B1 (en) 2014-11-13 2022-11-15 State Farm Mutual Automobile Insurance Company Autonomous vehicle control assessment and selection
US11173918B1 (en) 2014-11-13 2021-11-16 State Farm Mutual Automobile Insurance Company Autonomous vehicle control assessment and selection
US10831204B1 (en) 2014-11-13 2020-11-10 State Farm Mutual Automobile Insurance Company Autonomous vehicle automatic parking
US11014567B1 (en) 2014-11-13 2021-05-25 State Farm Mutual Automobile Insurance Company Autonomous vehicle operator identification
US10915965B1 (en) 2014-11-13 2021-02-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle insurance based upon usage
US11175660B1 (en) 2014-11-13 2021-11-16 State Farm Mutual Automobile Insurance Company Autonomous vehicle control assessment and selection
US11532187B1 (en) 2014-11-13 2022-12-20 State Farm Mutual Automobile Insurance Company Autonomous vehicle operating status assessment
US11740885B1 (en) 2014-11-13 2023-08-29 State Farm Mutual Automobile Insurance Company Autonomous vehicle software version assessment
US11247670B1 (en) 2014-11-13 2022-02-15 State Farm Mutual Automobile Insurance Company Autonomous vehicle control assessment and selection
US11645064B2 (en) 2014-11-13 2023-05-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle accident and emergency response
US10824144B1 (en) 2014-11-13 2020-11-03 State Farm Mutual Automobile Insurance Company Autonomous vehicle control assessment and selection
US10940866B1 (en) 2014-11-13 2021-03-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle operating status assessment
US11726763B2 (en) 2014-11-13 2023-08-15 State Farm Mutual Automobile Insurance Company Autonomous vehicle automatic parking
US10821971B1 (en) 2014-11-13 2020-11-03 State Farm Mutual Automobile Insurance Company Autonomous vehicle automatic parking
US10831191B1 (en) 2014-11-13 2020-11-10 State Farm Mutual Automobile Insurance Company Autonomous vehicle accident and emergency response
US11127290B1 (en) 2014-11-13 2021-09-21 State Farm Mutual Automobile Insurance Company Autonomous vehicle infrastructure communication device
US10824415B1 (en) 2014-11-13 2020-11-03 State Farm Automobile Insurance Company Autonomous vehicle software version assessment
US10943303B1 (en) 2014-11-13 2021-03-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle operating style and mode monitoring
US10500955B2 (en) * 2014-12-30 2019-12-10 Visteon Global Technologies, Inc. Automatic upgrade of a vehicle-based processor based on a physical component change
US11450206B1 (en) 2015-08-28 2022-09-20 State Farm Mutual Automobile Insurance Company Vehicular traffic alerts for avoidance of abnormal traffic conditions
US10977945B1 (en) 2015-08-28 2021-04-13 State Farm Mutual Automobile Insurance Company Vehicular driver warnings
US10748419B1 (en) 2015-08-28 2020-08-18 State Farm Mutual Automobile Insurance Company Vehicular traffic alerts for avoidance of abnormal traffic conditions
US10769954B1 (en) 2015-08-28 2020-09-08 State Farm Mutual Automobile Insurance Company Vehicular driver warnings
US10950065B1 (en) 2015-08-28 2021-03-16 State Farm Mutual Automobile Insurance Company Shared vehicle usage, monitoring and feedback
US10829063B1 (en) 2016-01-22 2020-11-10 State Farm Mutual Automobile Insurance Company Autonomous vehicle damage and salvage assessment
US10579070B1 (en) 2016-01-22 2020-03-03 State Farm Mutual Automobile Insurance Company Method and system for repairing a malfunctioning autonomous vehicle
US11119477B1 (en) 2016-01-22 2021-09-14 State Farm Mutual Automobile Insurance Company Anomalous condition detection and response for autonomous vehicles
US11920938B2 (en) 2016-01-22 2024-03-05 Hyundai Motor Company Autonomous electric vehicle charging
US11062414B1 (en) 2016-01-22 2021-07-13 State Farm Mutual Automobile Insurance Company System and method for autonomous vehicle ride sharing using facial recognition
US11022978B1 (en) 2016-01-22 2021-06-01 State Farm Mutual Automobile Insurance Company Autonomous vehicle routing during emergencies
US11136024B1 (en) 2016-01-22 2021-10-05 State Farm Mutual Automobile Insurance Company Detecting and responding to autonomous environment incidents
US11348193B1 (en) 2016-01-22 2022-05-31 State Farm Mutual Automobile Insurance Company Component damage and salvage assessment
US11016504B1 (en) 2016-01-22 2021-05-25 State Farm Mutual Automobile Insurance Company Method and system for repairing a malfunctioning autonomous vehicle
US11124186B1 (en) 2016-01-22 2021-09-21 State Farm Mutual Automobile Insurance Company Autonomous vehicle control signal
US11441916B1 (en) 2016-01-22 2022-09-13 State Farm Mutual Automobile Insurance Company Autonomous vehicle trip routing
US11440494B1 (en) 2016-01-22 2022-09-13 State Farm Mutual Automobile Insurance Company Detecting and responding to autonomous vehicle incidents
US11189112B1 (en) 2016-01-22 2021-11-30 State Farm Mutual Automobile Insurance Company Autonomous vehicle sensor malfunction detection
US11879742B2 (en) 2016-01-22 2024-01-23 State Farm Mutual Automobile Insurance Company Autonomous vehicle application
US10828999B1 (en) 2016-01-22 2020-11-10 State Farm Mutual Automobile Insurance Company Autonomous electric vehicle charging
US11513521B1 (en) 2016-01-22 2022-11-29 State Farm Mutual Automobile Insurance Copmany Autonomous vehicle refueling
US11511736B1 (en) 2016-01-22 2022-11-29 State Farm Mutual Automobile Insurance Company Autonomous vehicle retrieval
US10818105B1 (en) 2016-01-22 2020-10-27 State Farm Mutual Automobile Insurance Company Sensor malfunction detection
US11015942B1 (en) 2016-01-22 2021-05-25 State Farm Mutual Automobile Insurance Company Autonomous vehicle routing
US11242051B1 (en) 2016-01-22 2022-02-08 State Farm Mutual Automobile Insurance Company Autonomous vehicle action communications
US11526167B1 (en) 2016-01-22 2022-12-13 State Farm Mutual Automobile Insurance Company Autonomous vehicle component maintenance and repair
US11600177B1 (en) 2016-01-22 2023-03-07 State Farm Mutual Automobile Insurance Company Autonomous vehicle application
US11625802B1 (en) 2016-01-22 2023-04-11 State Farm Mutual Automobile Insurance Company Coordinated autonomous vehicle automatic area scanning
US10802477B1 (en) 2016-01-22 2020-10-13 State Farm Mutual Automobile Insurance Company Virtual testing of autonomous environment control system
US10545024B1 (en) 2016-01-22 2020-01-28 State Farm Mutual Automobile Insurance Company Autonomous vehicle trip routing
US10824145B1 (en) 2016-01-22 2020-11-03 State Farm Mutual Automobile Insurance Company Autonomous vehicle component maintenance and repair
US11656978B1 (en) 2016-01-22 2023-05-23 State Farm Mutual Automobile Insurance Company Virtual testing of autonomous environment control system
US11181930B1 (en) 2016-01-22 2021-11-23 State Farm Mutual Automobile Insurance Company Method and system for enhancing the functionality of a vehicle
US11682244B1 (en) 2016-01-22 2023-06-20 State Farm Mutual Automobile Insurance Company Smart home sensor malfunction detection
US10747234B1 (en) 2016-01-22 2020-08-18 State Farm Mutual Automobile Insurance Company Method and system for enhancing the functionality of a vehicle
US11719545B2 (en) 2016-01-22 2023-08-08 Hyundai Motor Company Autonomous vehicle component damage and salvage assessment
US11126184B1 (en) 2016-01-22 2021-09-21 State Farm Mutual Automobile Insurance Company Autonomous vehicle parking
US10691126B1 (en) 2016-01-22 2020-06-23 State Farm Mutual Automobile Insurance Company Autonomous vehicle refueling
US10679497B1 (en) 2016-01-22 2020-06-09 State Farm Mutual Automobile Insurance Company Autonomous vehicle application
US11086328B2 (en) 2016-08-23 2021-08-10 A9.Com, Inc. Autonomous cart for manufacturing and warehouse applications
US11760221B2 (en) 2017-06-27 2023-09-19 A9.Com, Inc. Charging systems and methods for autonomous carts
US10793369B2 (en) 2017-07-12 2020-10-06 A9.Com, Inc. Conveyor system for autonomous robot
GB2564473B (en) * 2017-07-13 2020-09-16 Blue Bear Systems Res Ltd Unmanned air vehicles
US11767109B2 (en) 2017-07-13 2023-09-26 Blue Bear Systems Research Limited Modular unmanned air vehicles
US10880412B1 (en) * 2017-08-21 2020-12-29 Clearpath Robotics Inc. Systems and methods for communicating between a fleet of robots and a fleet manager

Also Published As

Publication number Publication date
US8548646B1 (en) 2013-10-01

Similar Documents

Publication Publication Date Title
US8548646B1 (en) Distributed hardware architecture for unmanned vehicles
US11472299B2 (en) Small unmanned ground vehicle
KR102622032B1 (en) Unmanned flying vehicle and flying control method thereof
US7778744B2 (en) Avionics framework
US10571931B2 (en) Vehicle control system
US9969285B2 (en) Methods and apparatus for reconfigurable power exchange for multiple UAV types
US9616998B2 (en) Unmanned aerial vehicle/unmanned aircraft system
US9456185B2 (en) Helicopter
EP2482024B1 (en) Small unmanned ground vehicle
CN104812671A (en) Takeoff assistance
WO2015094695A1 (en) Self-propelled device with center of mass drive system
WO2012170081A9 (en) Small unmanned ground vehicle
TW200835540A (en) Central control system of wireless remote-control model
CN103235599A (en) Smart phone based flight control system
KR102037359B1 (en) AHRS flight control device based on mobile platform
US20190260605A1 (en) Dual-mode controller
US20230023246A1 (en) Integration between unmanned aerial system and unmanned ground robotic vehicle
Zolich et al. Unmanned aerial system architecture for maritime missions. design & hardware description
WO2017207874A1 (en) Interface for connecting functional modules and aerial vehicles, related module and aerial vehicle
US20170160738A1 (en) Vehicle controllable by a remote computer
CN112533827A (en) Device for storing and remotely launching unmanned aerial vehicles
CN116234751A (en) System and structure of unmanned aerial vehicle
JP5921864B2 (en) Steering communication system
US20190217953A1 (en) Control systems for unmanned aerial vehicles
WO2009147420A1 (en) Vehicle system

Legal Events

Date Code Title Description
AS Assignment

Owner name: CLEAERPATH ROBOTICS, INC., CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GARIEPY, RYAN;GILL, RAJAN JOSHUA;MARTINSON, PATRICK WILLIAM;AND OTHERS;SIGNING DATES FROM 20110602 TO 20110621;REEL/FRAME:026560/0982

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Year of fee payment: 8

AS Assignment

Owner name: CLEARPATH ROBOTICS INC., CANADA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE RECEIVING PARTY'S NAME FROM "CLEARPATH ROBOTICS, INC." TO CLEARPATH ROBOTICS INC" PREVIOUSLY RECORDED AT REEL: FRAME: . ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:GARIEPY, RYAN;GILL, RAJAN JOSHUA;MARTINSON, PATRICK WILLIAM;AND OTHERS;SIGNING DATES FROM 20110602 TO 20110621;REEL/FRAME:065221/0320

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY