See the July report for the previous update.
Computational grids are currently being developed for three-dimensional Navier-Stokes analyses of candidate rotor designs. Technical assistance and computational resources for these calculations are being provided by Dr. Roger Strawn and the Rotorcraft Computational Fluid Dynamics Group at the Army AFDD-ATCOM, NASA Ames Research Center. The first rotor being considered is a 4-blade 2.5 cm diameter rotor for the 15g vehicle. This particular rotor design is being closely examined to determine the source of the discrepancies between the predicted performance from the current design tools and the experimental results. As described previously, the current design tools predict rotor thrust versus RPM well, but significantly underpredict the power required. The differences may be due to inaccuracies in the design method, geometry variations incurred in manufacturing, structural dynamics, or any combination of these factors.
The 3-D viscous CFD analyses, coupled with experimental test data and the use of laser surface scanning for determination of the as-built geometry, will provide a much clearer picture of where the problem lies. The results of the computational analyses will provide both quantitative data for direct comparison to experiment, and qualitative flow visualization. The qualitative data will be very helpful in improving the lower-order modeling implemented in the design tools.
A variant of the NASA OVERFLOW-D code will be used for all 3-D analysis. This is an overset grid method, which greatly facilitates grid generation of complex geometries. The OVERGRID grid tools package, also developed at NASA, is being used for all volume grid generation. Steady-state analysis permits the use of periodic boundary conditions on the vertical inflow and outflow planes. Gridding only one sector of the rotor allows a much higher grid density for a given problem size, but places restrictions on the maximum rotor solidity near the hub. High inboard solidity causes the overset grid on a blade to exceed the periodic boundaries of a single blade sector. This restriction practically limits the analysis to rotors with four or less blades. Initial computations on the 4-blade geometry should be completed by the end of October.
The blade is twisted with respect to the shear center when the torque is applied. In the previous calculations, we assumed the shear center and centroid are close enough that twist angles with respect to centroids will be almost the same as those with respect to shear centers. To verify this assumption, a program was written to calculate shear center for the cambered plate cross-sections. Once the shear centers are found, we could calculate torques at the shear centers and further calculate the twist angles at different cross-sections. The comparison of the twist angles with respect to centroids and shear centers supported our earlier assumption.
More structural analyses were done for also 5-blade rotor, and Mars rotor. The results of 5-blade rotor are shown in the following figures. Since the Mars rotor is made of composite material other than epoxy, material properties became more complicated and were not verified experimentally. Therefore, we could not simply use Young?s Modulus (E) and shear modulus (G) for calculating deflections and twists. A comparison of torques from aerodynamics forces and centrifugal forces is shown below.
Efforts were made to verify the material properties of epoxy at small scales. Small cantilever beams (1mm x 2mm x 10mm) were built for bending test. Material testing machines available on campus do not have suitable load cells in our required range, thus we had to seek other possible solutions to implement this test. The setup shown in the following figure seems feasible.
The force was applied at the tip of the beam by the height gauge, so that we can control the deflection at the tip and read the force through the scale. However, in the actual experiments, the reading of the scale decreased with time and no stable number or range could be read. This may be due to deformation of the rubber pads on the bottom of scale. Outsourcing the testing is currently pursued. The best resolution provided by Testing Engineers, Inc is 0.1 g.
In continuation of the analysis of the dynamic behavior of the mesicopter, a 3D simulation of the vehicle kinematics has been created in Matlab. The simulation includes all the 3D rigid body motions of the mesicopter. Simplified models of the inflow aerodynamics are also being incorporated.
The following assumptions were made for the simulator. The earth was assumed to be an inertial reference frame. The gyroscopic moments due to the spinning blades have been ignored now, but will be implemented shortly. Finally, uniform inflow and linear twist are assumed for determining the rotor forces. Currently only axial rotor forces have been implemented. The dynamics are decoupled into translational and rotational components. The forces are expressed in the inertial frame, then integrating Newton's law provides a time history of the position and velocity of the center of mass in the inertial frame. The angular velocity of the vehicle is calculated from the forces and moments acting on the vehicle to provide Eulerian angular rates. These rates can also be integrated to procuce a time history of the Euler angles which define the orientation of the vehicle through time. The integrations described above are all carried out using a 4th order Runge Kutta scheme.
The forces and torques themselves are calculated from momentum theory combined with simple blade element theory. Currently hover conditions are assumed so that the inflow ratio and advance ratio can be assumed constant. Only perturbations in the inflow due to axial motion of the rotor itself are accounted for. The torque due to spinning the blade is calculated from simple relationships which relate RPM, torque and power for the motor.
In order to completely define the state of the mesicopter at each point in time now requires 12 state variables. These variables record the position, velocity, orientation, and angular velocity of the vehicle in three dimensions. Analyzing the stability of this 3D system is more complicated than the previous 2D analysis. Complete linearization of the functions is tedious and may neglect important dynamics. I am currently studying the use of Lyapunov theory to determine if the nonlinear dynamics are stable.
Preliminary time history plots of the 3D dynamics are not yet available, but will be posted to this site as soon as they are available.
A software simulator written in Java and Java3D has been developed for the PCB flyer. It consists of a physical model of the dynamics, a texture mapped environment, and a vision stabilizer. The dynamics are modeled as a single rigid body with an accurate inertia matrix representing the mass distribution of motors and battery acted upon by the force of gravity, propellor lift forces and drag torques. Noise forces are also included. The user may fly the vehicle using arrow keys and may choose a ground view of the flyer, a chase plane view, or the view as seen from an onboard camera.
Vision stabilization is simulated by a camera fixed to the flyer frame. Ray tracing is used to sample pixels of this camera by intersecting rays cast through the pixels with the texture mapped environment. The environment in this case is an "airfield" modeled as a cylinder with sky texture mapped on the top, grass texture mapped on the bottom, and garden border texture mapped on the cylinder walls. The sampled pixels are used to compute optical flow vectors at four regions of the simulated camera's image.
The above algorithm has been written, debugged, and tested. It runs at 100 steps per second. It has a realistic feel despite the simplified aerodynamic model and is very difficult to control. The code is correctly computing the optical flow vectors. The next step is to use the optical flow vectors to estimate the body motion, especially angular, and to generate stabilizing input to be combined with user input. The texture mapping is performed in real time using a GeForce 2 GTS accelerator card.
We are actively researching methods to enable 3D formation flight. Using new distributed control techniques, we hope to synchronize multi-mesicopter flight. Currently we are compiling a bibliography of topics related to distributed contol. Areas of interest include synchronization of distributed agents, minimization of communication/information for group control, dynamic modeling of distributed formations, and group stabilization.
In parallel we are designing an external vision sensor to track mesicopter state. Distributed controllers will use state estimates and additional information to automate group flight.
We've setup a Linux-based PC with PCI framegrabbers to design/run our software. Framegrabbers acquire video from offboard cameras. Software is being designed to format/process data from these frames. The sensor's software infrastructure is made up of reusable, modular components. Real Time Innovation's ControlShell software provides the infrastructure. We have created a vision repository which will hold components created within the mesicopter group and within other groups at Stanford. All vision applications, like the sensor, will be based on 5 basic, inheritable components.
Acquisition components will be OS/device specific (the only architecture specifc component) and are wrappers for specific framegrabber device drivers. Acquisition components provide a memory reference to the current image and the sampling rate (based on the frame rate).
Processing components manipulate an image and output a modified image. For example, we would provide a compenent to implement a common thresholding technique. The output image of a thresholding component would consist of binary pixels. If an individual pixel value of the entering image was above a certain threshold, the output pixel of the corresponding image would be 1. For pixel below the threshold, the output pixel would be 0.
State components provide information specific to an input image. For the mesicopter project, state components calculate specific data about position, orientation, etc. of the vehicle from an image. State components are often application specific. Networking components transfer an image from one machine to the next transparently. In most applications this component is not useful because of the expense. The functionality is still provided. Display components display images actively on a monitor. These components are often used for verification. All components pass information via a common image interface.
Powerful applications, like our sensor, can be constructed using available components. Our vision repository will enable many new vision applications and simplify development work (especially for the sensor design). In providing this repository we hope to promote open source programming.