Distributed hardware architecture for unmanned vehicles

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.

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.

DETAILED DESCRIPTION

FIG. 1depicts external features of an unmanned vehicle platform101, according to non-limiting implementations. A chassis180and supporting external members190house or otherwise provide stable mounting points for sensors, computing systems, and other devices. Unmanned vehicle platform101is enabled to track trajectories by way of actuating a set of wheels200, which in non-limiting depicted implementations are arranged in a differential-drive configuration. Devices may be mounted within the chassis180or external to it, on removable and modular plates100or affixed to bumpers90.

For ease of access to devices mounted within the chassis, drawers140are securable from opening using, for example, a set of latches130, and may be opened via handles150, springs, or the like. Bumpers90may 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 bays210which may incorporate a battery bay latch230. In some implementations, if users do not wish to remove batteries for charging, they may be charged while still in the platform via charge connectors220.

Unmanned vehicle platform101can comprise a set of controls mounted directly to the chassis. In depicted example implementations, unmanned vehicle platform101is enabled for activation/deactivation via a latching pushbutton240and can be emergency stopped manually via a safety pushbutton170. Any other suitable method of controlling unmanned vehicle platform101is within the scope of present implementations, including but not limited to issuing commands from a computing system mounted within the drawers140and/or by sending commands to a remote control receiver module110. A degree of feedback on the state of the system of the unmanned vehicle platform101can be provided via a status display120.

Internally, unmanned vehicle platform101can comprise a plurality of possible operational modules, each of which may provide unmanned vehicle platform101with a different set of capabilities.FIGS. 2aand2bshows two possible arrangements of internal modules.FIG. 2adepicts a central control module30connected to a motor amplifier module40and a user interface module50by way of a vehicle control network60. Vehicle control network60can 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.

Modules30,40,50can also be enabled to receive commands from other systems not on the vehicle control network60. For example, in non-limiting exemplary implementations, the central control module30can be connected via a control link20to a high-level computing system10, 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 link20and an off-the-shelf laptop computer as the high-level computing system10, but the system is not restricted to these choices. For example, the control link20could be a radio modem and the high-level computing system10could 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. 2bis similar toFIG. 2a, with like elements having like numbers, however the arrangement of modules ofFIG. 2bfurther comprises an RF (radio frequency) module70enabled to receive wireless emergency stop commands and an RC (radio control/radio receiver) module80enabled to transform signals from (for example) off-the-shelf radio control receivers to forms which are compatible with the vehicle control network60. Expanding the platform capabilities in this way does not necessitate any changes to the rest of unmanned vehicle platform101.

Attention is now directed toFIGS. 3a,3band3cdepicts a toolless battery change process/sequence, according to non-limiting implementations;FIG. 3adepicts a battery bin260in a closed position,FIG. 3bdepicts the battery bin260in an open position, andFIG. 3cdepicts the battery bin260in the open position with a battery320external to the battery bin260. With reference toFIG. 3a, the battery bin260is secured to the chassis180via pivots290. The battery bin260incorporates integrated terminals270which elastically deform under the weight of the battery to maintain electrical connectivity. Also mounted to the battery bin260are two mechanical stops250,280which constrain the pivoting of the battery bin260by contacting the chassis180. A battery bay latch230may be used to lock the battery bin260in the closed position by engaging with a latch slot300. Additionally, this battery bay latch230may include a sensor on it to allow the central control module30to determine when the battery bay260is opened or closed. If this is the case, the battery bay latch230is designed such that it cannot be closed when the battery bay260is open. Finally, a spring assembly310may add to the force keeping the battery terminals330mated with the integrated terminals270when the battery bin260is closed.

The battery320is removed by releasing the battery bay latch230and manually pivoting the battery bin260until the opening mechanical stop250makes contact with the chassis180, as inFIG. 3b. When the battery bay latch230includes a sensor capable of monitoring its state, the central control module30can execute appropriate instructions to handle the opening event (for example, as described below with reference toFIG. 7). The battery bin260may also be opened by a spring assembly or by other automated means. The battery320is then removed, as inFIG. 3c. 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 battery320is replaced by reversing the process. The battery320is slid into the battery bin260until the battery terminals330mate with the integrated terminals270. The battery bin260is then pivoted closed until the closing mechanical stop280makes contact with the chassis180. Finally, the battery bin260is secured with the battery bay latch230. If the battery bay latch230includes a sensor capable of monitoring its state, the central control module30can now execute appropriate instructions to handle the closing event.

FIG. 4depicts a system301of electronic modules and device network of unmanned vehicle platform101, according to non-limiting implementations. The central control module30is powered by a power bus460which itself is fed from a plurality of power sources which may include one or more batteries320and/or an AC power supply440or the like. Batteries320used in unmanned vehicle platform101can be recharged without being removed by the battery charging system430. The battery charging system430can indicate to the central control module30when the batteries320are being charged.

The central control module30can be enabled to shut off or turn on any subset of the available power sources, while the platform's power switch470shuts off all available power sources. The central control module30is further enabled to power the fuse panel360, any internal modules50,70,80, low-level sensors390and portions of the motor amplifier module40. Incorporated into the low-level sensors390are 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 sensors400and encoders410, where the encoders410can use any suitable sensing methods (e.g. optical, magnetic, mechanical or the like). In the latter case, the encoders410can be physically connected to the drive train of the chassis180, providing a direct observation of various speeds within the drive train. These feedback sensors400and encoders410may be used to improve the trajectory tracking performance of the unmanned vehicle platform101and/or may be restricted to observing changes in a state of the unmanned vehicle platform101.

The payload bay340is generally comprised of components that a user interacts with during operation of the unmanned vehicle platform101. In depicted implementations, the payload bay340contains the high-level computing system10, the fuse panel360and a plurality of payloads350. Payloads350can 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 system10is connected using appropriate interfaces to the payloads350. The fuse panel360routes power from the central control module30to the high-level computing system10and the payloads350, 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 system10.

The central control module30communicates via the vehicle control network60with secondary modules40,50,70,80as 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 platform101. For example, such an implementation can be useful when receiving commands via the remote receiver module80, monitoring remote switches via the RF module50and/or commanding motor motion via the motor amplifier module40. However, such a requirement on message frequency can be less useful with other modules such as the user interface module70. 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. 5depicts a configuration of a central control module30of the unmanned vehicle platform101, according to non-limiting implementations. The main components of the central control module comprise a power source selection module490, a power regulation module510and an embedded processor530. The power source selection module490is enabled to select which of the available power sources within the power bus460is fed into the power regulation module510. This selection is done based on the information made available by the monitoring module480. The power regulation module510powers the embedded processor530, the fuse panel360(including devices powered by the fuse panel), and any other devices which are connected to the vehicle control network60.

As well, the battery detect switches550enable the power source selection module490to determine if the user is removing a battery320or if they have recently replaced one. With such information, the power source selection module490can minimize system downtime by ensuring that the unmanned vehicle platform101and/or the system301is powered from a reliable power source at all times. Optional display indicators, such as the status panel120and/or the battery-in-use indicators540can indicate which subset of power sources are being used at any given time.

A soft start module520may be used to limit the inrush current into the fuse panel360and other devices powered by the power regulation module510. The status of each power source in the power bus460is monitored using corresponding monitoring modules480. The monitoring modules480may retrieve any subset of temperature, voltage and current draw data or the like. The monitoring module480may also use this data to estimate the health of each power source in the power bus460. This data can also report to the embedded processor530so that it can reduce power draw when necessary. The data may also be forwarded to the high level computing system10or retransmitted along the vehicle control network60.

Each monitoring module480can be enabled to shut off power from its associated power source. There may also be a separate current sense module500that reports current draw data to the embedded processor530. A power switch470is used to shut off all available power sources. The embedded processor530also collects sensor data520from 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. 6depicts a configuration of a motor amplifier module40of the unmanned vehicle platform101, according to non-limiting implementations. The motor amplifier module40comprises an embedded processor590, a motor power source selection module560and any suitable ancillary components, for example any suitable ancillary components that can be determined according to electrical design principles. The embedded processor590can communicate with the central control module30and other modules in the system301using the vehicle control network60. The power regulation module510located in the central control module30provides the power necessary to run the embedded processor590. This power is transmitted along the same path as the vehicle control network60. The embedded processor590can read battery voltages using the power monitoring system570and motor current draw using the current sense modules580.

These measurements can be used for platform health monitoring, or can be incorporated further into the platform control system301to allow for more precise control strategies. The motors380are powered by sources selected by the motor power source selection module560. Power to each motor380is controlled by the embedded processor590. The embedded processor590can use any suitable strategy to regulate the power to each motor380. In exemplary implementations, as depicted, each motor380is driven by an H-bridge circuit600which is controlled by a bridge driver610. Each bridge driver610is in turn controlled by the embedded processor590.

A physical E-stop170can be used to cut off power to parts of the system301, if necessary, providing a robust safety system which is not dependent at all on firmware. For example the physical E-stop170can be monitored by the motor power selection module560. When the physical E-stop170is activated, the motor power selection module560can shut off all power to the H-bridge circuits600and by extension halts the motors380.

FIG. 7depicts a process flow for a managing a power bus460that can be implemented by the unmanned vehicle platform101, according to non-limiting implementations. The unmanned vehicle platform101starts in a power off state620. When the main power switch470is turned on, a power-on transition occurs630and the central control module30, as well as every other device powered by the power regulation module510, is powered on. For a period of time, the electronics are powered by all available power sources640. After a period of time, the embedded processor530instructs the power source selection module490to choose a single power source and a power source selection transition650occurs.

In the single-power state660, the central control module30, and every other device powered by the power regulation module510, is powered by a single power source (e.g. a first battery of batteries320). In some configurations the system301will remain powered by a secondary power source, such as a second battery of batteries320, in addition to a source such as an AC power supply440in case the primary source is suddenly removed. After the power source selection transition650occurs, the motor power source selection module560turns on the power source to power the motors and a motor power transition670occurs. Once the motor power transition670has been completed, the unmanned vehicle platform101has entered its normal operation state680.

A number of situations can cause the unmanned vehicle platform101to leave the normal operation state680. Such situations may include the triggering of the battery detect switch550, the battery state-of-charge dropping below a preset threshold, or the user swapping out a current power source/battery320. If one of these situations occurs, the unmanned vehicle platform101leaves the normal operation state680and a motor power down transition740occurs. During the motor power down transition740, the motor power source selection module560shuts down all power to the motors380and the system301then transitions into the motors powered down state750. If the motor power down transition740occurred due to a low state-of-charge on the batteries320then the vehicle will undergo a state transition730to a low-power state720.

In the low power state, the unmanned vehicle platform101waits until the charge on the battery320reaches a critically low level and another transition710occurs to a shut down state700. The user may add a fresh battery320or an additional power source such as an AC power supply440to prevent the system301from entering the shut down state700. In this case, the system301switches the new power source on, undergoes a recovery transition760, and is powered by both the old and the new power source for a period of time790. From this state, the system301would return to being powered by one source660by shutting the old source off and will eventually return to normal operation680as it did when first starting up.

In the situation where the unmanned vehicle platform101undergoes a motor power down transition740because the battery detect switch550had been triggered or the user is swapping out the current power source, a secondary power source transition770occurs and the unmanned vehicle platform101is powered by two power sources for a period of time790. From this state790, the unmanned vehicle platform101would shut off the old power source and return to being powered by one source660. The unmanned vehicle platform101would then return to the normal operation state680as it did when first starting. If the user removes the only available power source, a shutdown transition690occurs and the unmanned vehicle platform101enters the shut down state700immediately.

FIG. 8depicts detail of a remote receiver module110mounted to the chassis180, according to non-limiting implementations. The remote receiver module110can 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 antennas800or the like.

FIG. 9depicts a configuration of the RF module70of the unmanned vehicle platform101, according to non-limiting implementations, which enables direct wireless control of the central control module30. The RF module70comprises an RF antenna800that provides a modulated signal to the RF demodulator810. The RF demodulator810sends out a string of data, as received by the antenna800, to the decoder820. The decoder820reads a serial bit stream and translates the data to a parallel bus. The parallel bus is read in by the embedded processor830. The embedded processor830then encodes the data and communicates the encoded data over the vehicle control network60. The entirety of this module is powered by the power regulation module510. 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. 10depicts a configuration of the remote receiver module80of the unmanned vehicle platform101, according to non-limiting implementations. Remote receiver module80is 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 platform101without changing the firmware or electrical system of the central control module30. Such data can be transmitted over a 2.4 GHz band, or any other suitable radio band, or the like. The remote receiver module80can comprise (for example) an off-the-shelf remote control receiver840and an embedded processor860. The remote control receiver840and the embedded processor860are powered by the power regulation module510. The remote control receiver840demodulates transmissions sent by the remote control transmitter850. The remote control transmitter850can be handheld, stationary, or in any other physical configuration.

The remote control receiver840forwards the demodulated transmission to the embedded processor860. 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 processor860interprets the demodulated transmission and reformats the received data into a form which can be transmitted on the vehicle control network60. The embedded processor860can also be enabled to conduct some filtering on the demodulated transmission. Such filtering can comprise detecting when the remote control transmitter850is out of range of the remote control receiver840. Similarly, such filtering could also serve to reject invalid transmissions and reduce noise.

FIG. 11depicts a status display120of the unmanned vehicle platform101, according to non-limiting implementations, mounted on an exemplary chassis180by mechanical hardware870. The status display120can be positioned in any suitable manner, for example such that it is visible to users from the exterior of the chassis180. In exemplary depicted non-limiting implementations, indicator lights880-920are mounted to a single printed circuit board. Furthermore, the user interface module50can comprise the status display120. Exemplary functions of the indicator lights880-920include, but are not limited to: indicating the presence of main electronics power900, indication of communications failure910, indication of use of power source selection880, depiction of the state of charge of an onboard power source890, depiction of overall system status920or the like.

The user interface module50can also be enabled receive inputs, and the portion of the chassis180to which the status display120is mounted can be enabled for quick replacement to match different physical layouts of the status display120can optionally incorporate input devices such as mode switches or adjustment knobs or the like.

FIG. 12depicts a program layout of vehicle control firmware of the unmanned vehicle platform101, according to non-limiting implementations. The control link20provides full-duplex serial communication to the system301, including error detection. The system301of unmanned vehicle platform101can receive messages which make up commands930or data requests960. Commands930can affect vehicle settings and setpoints directly or can be pre-processed by additional modules such as built-in vehicle kinematic models950. Vehicle settings and setpoints can be verified by a set of control loops940before being sent to secondary modules via the vehicle control network60. The control loops940may also be capable of providing some degree of autonomy, for example when the sensor data420includes appropriate information. Settings and setpoints can be stored in a central system state1000. System state1000also contains data received from other modules located on the vehicle control network60. Sensor data420may be raw data as received from the hardware, or filtered via analog and/or digital means.

The system301of the unmanned vehicle platform101can be monitored remotely by issuing data requests960. Data requests960can be structured to require immediate responses from the system301, or can be subscriptions for periodic updates of specific data. The management of the varied requests and subscriptions can be handled by a subscription manager970. The subscription manager970is queried by a data scheduler990which uses this subscription information and the system state1000to produce data980for the control link20. In this way, data980can thus be produced for the device on the other end of the control link20without continual requests for such data, thereby lowering the inbound bandwidth requirements.

FIG. 13depicts a control flow within each module attached to the vehicle control network60of the unmanned vehicle platform101, according to non-limiting implementations. Upon module start-up1010, a given module issues requests for information1020from the central control module30via the vehicle control network60. For the user interface module50, this information may be system status, while for the motor amplifier module40, this information may be safety limits. The given module may then wait for this information to be provided in a loop1030or 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 commands1040, performs a variety of tasks1050, and then transmits information over the vehicle control network60. Depending on the specifics of the vehicle control network60, 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 toFIG. 1, it is appreciated that the unmanned vehicle platform101comprises a wheeled land vehicle. However, in other type of vehicles are within the scope of present implementations. For example, while the unmanned vehicle platform101is 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 toFIG. 14which depicts an aquatic unmanned platform1401, according to non-limiting implementations. The aquatic unmanned platform1401comprises a hull120aand attached framework150awhich provides a stable buoyant platform upon which the rest of the aquatic unmanned platform1401is mounted. A primary electrical enclosure10acomprises the primary control board30aand a primary battery20a, while an auxiliary electrical enclosure90aholds the auxiliary control board70aand an auxiliary battery80a. Attached via shafts160ato both enclosures10a,90aare thruster assemblies100awith appropriate propellers110afor propelling the aquatic unmanned platform1401through an aquatic environment. A status display40aand a long-range bidirectional communications system50acan each be attached to the primary electrical enclosure10a. A plurality of additional sensors such as a camera system60aand a GPS system130amay also be emplaced on the hull120a. Sensors60a,130amay be mounted on mounts140aif required. It is otherwise appreciated that aquatic unmanned platform1401comprises a control system similar to the system301, and suitable associated modules.

In particular attention is directed toFIG. 15which depicts an electrical architecture of unmanned aquatic vehicle1401, according to non-limiting implementations and represent an alternative architecture of parts of system301. Separate control modules485a,515aare electrically connected via a suitable vehicle control network500a. In each module485a,515acomprises a motor driver36a0and its associated thruster100a. A primary module485ais powered by a battery2awhich has its power filtered, monitored, and distributed by a power system490a. Control of the system is done by the primary control board30a, which itself receives information from low-level sensors340aand communicates with other control modules via the vehicle control network500a. The primary control board30acan interface with the user and other sensors in any suitable manner. Auxiliary module515acomprises a dedicated battery80and power system510a, and is controlled aria an auxiliary control board70a, which itself responds to commands over the vehicle control network500a. Each power system490a,510ais enabled for self-monitoring and safety limiting, and can provide status updates as required to the relevant control board30a,70aofFIG. 14.

Those skilled in the art will appreciate that in some implementations, the functionality of system301can 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 system301can 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.