Implementaciones abiertas

In order to be able to accurately define the needs in the design of the project deliverable, the team had to consider numerous constraints. These constraints can be grouped into seven distinct categories: financial constraints, time limitations, available workspace, safety concerns, operational environment, wireless communication protocols, and power distribution. Each of these categories had an effect on how every aspect of the project was approached, and overall determined the outcome of the project deliverable. This section will explore each of these categories in depth, and discusses the impact on the design choices made in the development of the collaboratively navigating autonomous system.

4.1.1 Experiment  Specifications  

In order to simplify the requirements of the vehicle for the task of autonomous navigation, the project team had to simplify the environment in which the vehicle would be

the design. The team also made assumptions as to which obstacles would never be encountered and thus would not be considered when making decisions about the vehicle design. One simplification made was the decision to not be concerned with abiding by the rules of the road. Another assumption the team decided to make about the operating environment is that the vehicle will only traverse flat terrain. Additionally, it has been assumed that the vehicle will never be required to make turns sharper than that of its turning radius and will never be required to reverse.

The vision system must be able to operate in an outdoor environment, which means a vision system cannot be used that utilizes infrared sensors, such as the Microsoft Kinect because the sun produces light in the infrared spectrum. The Kinect is a camera that uses an infrared sensor to gather depth data about the surrounding environment. The noise induced by the Sun’s infrared light will cause the depth data from a sensor like the Kinect useless. This was a driving factor to use RGB cameras.The team did not restrict the environment to indoors or outdoors, and thus the sensors used must be able to function properly in both types of lighting and must be somewhat weather resistant. This assumption meant we could not use any sensors that depend on infrared light due to the interference from sunlight.

4.1.2 Information  and  Sensor  Connectivity  

To successfully communicate with the UAVs engaged in the project without hindering their movements or range, they were operated via a wireless connection to the ground vehicle. Ultimately, the project is intended to function independent of the type of connection, and only needs a respectable range and a minimum speed. This is achieved by allowing the drones function as separate, self-contained systems that take positional commands from the ground vehicle and relay back information about the observed environment.

The AR Parrot drones acquired for this project already used Wi-Fi to communicate with a phone or computer, but also contained several other wired hardware interfaces onboard. These were pursued in the hope that they may be used to control the drone (and thus allow the team to attach a controller and use an independent radio), but were dismissed due to the short time and lack of documentation. An alternative proposal was to attach a small Linux-based computer to the drone (ie a Raspberry Pi) and equip it with a Wi-Fi adapter to connect to the drone and a Wi- Fi, Zigbee, Bluetooth, SDR, or other radio to communicate with the ground vehicle.

Table 4.1: Specifications of different wireless standards.

Wireless Standard Data Bandwidth Range (line-of-sight) Transceiver power Price

Wi-Fi (IEEE 802.11g-2003) Up to 54 Mbps About 140 m Up to 125 mW+ $20+ Wi-Fi (IEEE 802.11n-2007) Up to 600 Mbps About 250 m Up to 700 mW+ $30+ Bluetooth Up to 2.1Mbps (2.0+ EDR) Up to 24Mbps (3.0+ EDR) Up to 60 m 100 mW (Class 1) 2.5 mW (Class 2) 1 mW (Class 3) $20+ ZigBee (IEEE 802.15.4) Up to 250 kbps 10-100 m (Up to 1500 m) 1, 2, 30, 50, 60 mW (up to 250 mW) $20+

Due to the team’s concerns over the AR Drone payload capacity, controllability, and reduced flight times of implementing such solutions, the team decided to use the Wi-Fi radios on the drones to communicate with them, and conduct all of the position control and data processing on the ground vehicle. The advantage of the ROS environment is that the AR Drone API and functions could be offloaded to a computer attached to the drone, or replaced with another software stack as needed to accommodate other drones or configurations.

4.1.3 Power  Management  Constraints  

The electronics and electromechanical systems added to the ground vehicle demanded consideration regarding the ability of the vehicle to power itself and the added peripherals for periods of extended testing. An internal combustion engine, powering the vehicle drivetrain or solely generating power, was disallowed due to safety concerns over storing gasoline and hot engines (see Section 4.3.4, Safety). When compared to an internal combustion engine powering a generator, however, the low energy density of the battery system on the ground vehicle leaves a minimal overhead for accessories before the performance of the vehicle is negatively affected. Additionally, the time needed to recharge the batteries would potentially interfere with the team testing the system, and as such required either conservative power use or supplementation.

Supplying power to the computer was the first aspect the team addressed as it had the most potential to discharge the vehicle quickly. The two ways to power the computer from the batteries on the vehicle involved adapting the 48V DC vehicle power to either a 120V, 60Hz AC mains source, allowing the power supply of the computer to be plugged in with no modification, or sourcing or building a 48V-powered, ATX compatible power supply and installing it in the computer. Both such solutions exist, but were ruled out due to their cost. As the constraints for the rest of the project narrowed, the decision was made to provide power to the computer and other mains-powered devices via an extension cord long enough for the vehicle to complete its course.

For the electromechanical systems mounted to the ground vehicle, the least expensive options for actuators and motor drivers consistently required 12V or 24V (or up to 30V) instead of 48V, as most hobbyist-level and light industrial hardware operates at these lower voltages. Additionally, motors and linear actuators capable of manipulating the controls for the ground vehicle were rated at drawing more current than most cheap step-down voltage regulators would

supply. Many of the high-current solutions required the construction of some manner of mounting that would provide sufficient heat dissipation. To keep the system simple, the team chose to purchase 12V batteries, manipulators, and controllers rated for 12V.

By isolating the computer and actuator power systems from that of the vehicle, its failsafe mode could be implemented to cut power only to the drive motor of the vehicle, while the electromechanical system can still steer and actuate the brakes as necessary. The computer can also continue operating without the need to re-initialize the software after every emergency stop, preserving the state of the executing programs to better diagnose the problem and fix it.