LabView图形化编程语言之机器人控制.zip

# RoboDolf Software (RDS)  The RoboDolf is an electric robot boat designed to conduct acoustic dolphin research in Belize. Acoustic and visual recording of dolphins is conducted to study dolphin vocalization gain insights into complex dolphin socialization. A robotic boat platform that was silent and had minimal visual impact on natural dolphin behavior was required, and drove the specifications for the RoboDolf. The RoboDolf is an unmanned surface vessel (USV) that was built on a 16' long SeaCycle catamaran platform. It has a LiFePo4 battery bank powering two modified electric thrusters in a differential thrust configuration. It has two communication radio systems, a long range 900 MHz radio for basic telemetry and a 2.4GHz 802.11 link for a full data/video link. The vehicle can operate under 3 different modes. A manned mode with an operator on-board controlling the vehicle with an xbox controller; under shore remote mode; and under autonomous mode. The vehicle has a host of instruments and sensors along with 4 actuated instrument pods that can be automatically raised and lowered into the water. The vehicle and field OPS systems where shipped to a remote atoll off the coast of Belize and where it successfully operated. For a video of its construction and operation [click here](https://youtu.be/pHH6SKcS8ms). In this repo, the software system powering the RoboDolf is supplied. The system was written by Paul Sammut in LabVIEW using the Actor Framework and LV-OOP. A custom message routing and subscription layer was written on top of the Actor Framework that facilitated a one-to-many node communication system. A class structure was created to facilitate the writing of common nodes, such as controllers and serial instruments. This system is called the RDS Framework. This project was made possible by the sponsor Dr. Marcelo Magnasco at the Rockefeller University and Eric Angel Ramos who runs the dolphin research programs in Belize. ***Quick Note: If coding anything like this, do it in ROS :)*** ## RDS Framework Architecture The RDS Framework makes heavy use of LV-OOP and the Actor Framework. Each major function of the RoboDolf is written as a nested child actor object that inherits from a special RDS Parent Actor class. This allowed for the creation of node-like processes that run independently of each other, but can easily share data between each other in a structured way. The system works on a one to many publisher/subscribers principle. Each actor subscribes to a list of message types on launch. During run-time the actor can send whatever messages it likes. Logic code can be written on receipt of the messages, on an internal actor loop or by some other means such as on receipt of hardware events.  This framework was written because the LabVIEW Actor Framework does not have native functionality for one to many message broadcasting. Each actor must have access to a queue handle for any actor it wants to send messages to. This was overcome by creating an actor called the RDS Router, and by creating an RDS Parent class that has functionality to subscribe to a list of messages; send messages to the router; and receive messages from the router. In this way, each actor only needs to have the queue handle of the RDS Router Actor, sending it messages and not worrying about who needs to see them. All messages are wrapped in an RDS Message class which allows the RDS Router to handle them regardless of their specific type implementation. This framework allows for all common functionality to be shared across actors and allowed one developer to be able to quickly code the robotic sub-systems. Operational overhead was minimal and all inter-actor communications was handled by performant LabVIEW queues, and implemented in the battle-tested LabVIEW Actor Framework. ## RDS Actors RDS comprises the following actors: - [RDS Router Actor](#rds-router-actor) - [AIP Actor](#aip-actor) - [Port Motor Actor](#mcb-motor-actor-port-and-stbd) - [STBD Motor Actor](#mcb-motor-actor-port-and-stbd) - [Battery Manager Actor](#battery-manager-actor) - [Depth Sensor Actor](#depth-sensor-actor) - [LSR Actor](#lsr-actor) - [Logger Actor](#logger-actor) - [Local Remote Actor](#local-remote-actor) - [GPS Actor](#gps-actor) - [Compass Actor](#compass-actor) - [State Tracker Actor](#state-tracker-actor) - [Helm Actor](#helm-actor) - [Controller Actor](#controller-actor) - [Mission Control Actor](#mission-control-actor) ### RDS Router Actor The RDS Router handles all inter-actor communications. It operates on a principle of subscriptions. Each actor sends the RDS Router an array of messages it is subscribed to. This subscription is implemented as a boolean array, with the index corresponding to a unique id that addresses each message. This list of unique message ID's is implemented as a typedef. This boolean array, along with the actor's message queue is packed into an RDS Subscription object and sent to the RDS Router. This functionality, which is common to all RDS actor's is implemented in the RDS Parent Actor class which all RDS Actors inherit from. The following image shows a specific RDS Actor, in this case the Mission Control Actor, being configured with mission control settings and message subscriptions and being "launched and subscribed". In the launch and subscribe phase the RDS Actor is launched, given the handle of the RDS Router queue (so it can send it RDS messages) and having its subscription list sent to the RDS router, so then RDS Router knows what messages it wants to receive.  During run time, RDS Actors send messages to the RDS Router. The router receives the messages, and through each subscription it has (one for every RDS Actor) and checks to see if that actor is subscribed to that message ID. It does this by simply indexing a boolean array, which takes O(1) time for each actor subscription. If that boolean is true, it sends the message to the associated message queue. Easy peasy! ### AIP Actor The Actuated Instrument Pod (AIP) system is a set of 4 poles that can be deployed into the water automatically by a linear actuator. It can monitor deployed, deploying, stowed, and stowing states of each pod independently and can also actuate each pod independently. The AIP actor is responsible for the following: - create and maintains a serial connection to the AIP system - subscribe and monitor to AIP-command messages - subscribe and monitor water-depth messages and automatically raise the AIP if water-depth is below a minimum #### Subscriptions and Publications The AIP Actor subscribes to: * AIP Command Message * AIP Set Min Depth Message * Depth Data Message The AIP Actor publishes these RDS Messages: * AIP Status Message ### MCB Motor Actor (Port and STBD) The Port Motor Actor is an instance of an MCB Instrument Class which inherits from an RDS Instrument class. The RDS Instrument class is a descendant of the RDS Parent Actor class, and adds serial communications functionality. This actor can be set up to be a Port or STBD motor controller, which follows the DRY principle for identical motor controller code. The motor controller is an MDC1230 RoboteQ single channel 80A brushed motor controller.  This actor is responsible for the following: - create and maintain a serial connection to the specified motor controller (port/STBD) - subscribe to motor messages and enact motor commands to appropriate serial commands - read back state information about thruster, pack a motor state message and send it out #### Subscriptions and Publications The MCB Motor Actor subscribes to: * MCB Command Message The MCB Motor Actor publishes these RDS Messages: * Motor Data Message ### Battery Manager Actor ![Battery pack](images/BTB_pac