ourdev_298114

所属分类:单片机开发
开发工具:C/C++
文件大小:10552KB
下载次数:452
上传日期:2009-07-23 16:25:46
上 传 者yuchao86
说明:  开源无人驾驶飞行器UAV 这是一位大名鼎鼎的网友开发的无人驾驶飞行器项目,他就是搞无人驾驶飞行器的朋友都应该知道的Jack Crossfire,该飞行器以直升机为原型,公开了全部源代码。 该无人驾驶飞行器可不是一个玩具!你可以去作者针对该项目的主页,阅读作者公开的完整源代码。
(UAV unmanned aerial vehicles that open source is a well-known users of unmanned aircraft development projects, he is engaged in unmanned aerial vehicles should be aware of the friends of Jack Crossfire, the prototype aircraft to helicopters, open all the source code . The unmanned aircraft is not a toy! You can go to the author' s home page for the project, read the author' s complete source code public.)

文件列表:
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_2way.c (19280, 2008-03-11)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_2way.c.acks (5386, 2007-12-10)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_2way.c.bak (6322, 2007-12-12)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_2way.h (1686, 2007-12-20)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ahrs.c (7677, 2008-01-05)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ahrs.h (181, 2007-10-02)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_autopilot.c (21622, 2008-04-14)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_autopilot.h (3283, 2008-03-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_config.h (5072, 2008-04-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_config.h.kalman (5587, 2007-10-16)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_config.h.nokalman (5072, 2008-04-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_copter.c (10031, 2008-04-14)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_copter.c.2way (8804, 2007-12-10)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_copter.h (8238, 2008-04-14)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_copter.h.2way (6030, 2007-07-28)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_gps.c (26043, 2008-04-17)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_gps.c.2 (17860, 2007-12-28)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_gps.h (176, 2007-12-28)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_gyro.c (2358, 2007-09-19)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_gyro.h (472, 2007-06-10)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_i2c.c (15194, 2007-05-06)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_i2c.h (158, 2007-05-06)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_i2capi.c (12621, 2007-05-06)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_i2capi.h (3836, 2007-05-06)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_i2cdev.h (13545, 2007-05-06)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.c (30494, 2008-04-28)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.c.102node (28614, 2007-09-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.c.5node (26222, 2007-09-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.h (6752, 2008-04-19)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.h.102node (5305, 2007-09-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_ins.h.5node (5165, 2007-09-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_kalman.c (15853, 2008-03-04)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_kalman.h (271, 2007-09-12)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_kml.c (1037, 2008-03-24)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_math.c (33654, 2008-04-07)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_math.h (7138, 2008-04-04)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_menu.c (9690, 2007-07-26)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_menu.h (162, 2007-07-09)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_menu.txt (1499, 2007-07-23)
开源无人驾驶飞行器UAV\vicacopter-1.0\arm_neural.c (22624, 2008-04-25)
... ...

VICACOPTER Copyright (C) 2007 Adam Williams This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Portions of the software came from autopilot.sourceforge.net. Currently the only section of theirs still in use is the direction cosine matrix calculation. ***** INSTALLATION For the PIC sections, install gputils. For the ARM sections, build the gumstix SDK in a separate directory next to the VicaCopter directory. Edit TOOLCHAIN in the VicaCopter Makefile to point to the Gumstix toolchain. Run make. You must reflash the Gumstix with the freshy built SDK image to get floating point to work. Next, copy the following to your /root directory on the Gumstix, using rz. cyclic.conf settings.conf arm_copter Make sure arm_copter has executable permission. The reprogramming sequence: Plug the PIC into the programmer with the power off, then plug it in. Program the PIC bootloader with pic_programmer pic_bootloader.hex. Program the PIC firmware next, with pic_programmer -b pic_copter.hex. Connect the Gumstix to a serial console. Remove arm_copter from the Gumstix. Run rz and download a new arm_copter to the /root directory. ***** CALIBRATION **** Throttle calibration Set FIXED_PITCH to 1 to program the ESC. This causes the left stick to control throttle. Set FIXED_PITCH to 0 to use THROTTLE_VALUE as the throttle when the engine switch is on. **** IMU calibration Stable voltage is required. The LM317 gives good results. The LM7805 doesn't work. Good IMU vibration isolation is required. Gyro calibration needs to be spot on. Deviation between gyro integration and accelerometer tilt causes more drift. The center gyro voltages need to be close to 2.5. Since the A/D converter isn't linear, offset center voltages won't give symmetric values for rotation rates. The sensors must be calibrated. The calibration factors are in settings.conf. Set DUMP_ANALOG to 1 in settings.conf. Set ATTITUDE_BLEND1 to 0.002. Set X_ACCEL, Y_ACCEL, and Z_ACCEL to 0, 1, 2. In pic_config.h, set ROLL_GYRO, PITCH_GYRO, and YAW_GYRO to 0, 1, 2. These must be in pic_config.h to control the software flybar. Reflash & run it on the flight computer with a serial console. Determine which of the accelometer & gyro columns are roll, pitch, & yaw. Edit the subscripts in the configuration files to match the true data columns. Reprogram again with the new subscripts. Set the _ACCEL_SIGN values so accelerations have the right signs. Use gravity to simulate the acceleration away from the surface of the Earth. Gravity pulling on the nose, the starboard side, & the rotor head should be -1 on the sensor readouts. Gravity pulling on the tail, port side, & the skids is 1. Set the _GYRO_SIGN values for the gyros. Rotation clockwise is 1. Use doc/cheatsheet.png to see the rotation signs. The ACCEL_MIN and ACCEL_MAX values must now be calibrated by orienting the sensor in all 6 directions and copying the analog values. Finally DUMP_THETA must be set to 1 and the RAD_TO_GYRO value must be calibrated so the orientation from gyro steps is as close as possible to the orientation from accelerometers. Test flights with attitude hold only are required to find the ATTITUDE_BLEND values. Set CYCLIC_TILT to 1. This causes cyclic to command attitude. Set all DUMP_ values to 0 before flight. ATTITUDE_BLEND should be high for manual flying. For autopilot, it should be as low as possible without experiencing drift in a hover. The trick here is there are 2 types of drift. Drift from translation motion occurs if ATTITUDE_BLEND is too high. This is observed by a failure to return to the starting attitude after yanking & holding the cyclic in attitude hold. Drift from gyro integration is a slowly increasing tilt that occurs if the cyclic is left centered. All this depends on the PID constants being previously calibrated for attitude hold. And all that depends on the swashplate mixing being calibrated. **** Magnetometer calibration The IMU must be calibrated and giving the proper roll & pitch before the magnetometer is calibrated. In settings.conf, set X_MAG, Y_MAG, Z_MAG to 0, 1, 2. Set DUMP_MAG to 1. Set DECLINATION to 0. Run the autopilot on the airframe with the magnetometer & everything mounted in its final position. Rotate the airframe on the X, Y, & Z axes and note which axis corresponds to which column of mag output. Change the X_MAG, Y_MAG, & Z_MAG indices to match the dumped columns. Now the X, Y, & Z axes will be dumped in order & it's time to calibrate the ranges. Rotate on the X, Y, & Z axes and note which direction North is from the printout. Unless you're on the equator, north points into the ground or into the sky. Point each axis of the magnetometer towards & away from North and copy the max & min values from each column to the MAG_MIN and MAG_MAX values in settings.conf. When the nose points toward north, Y mag is positive. When starboard points toward north, X mag is positive. When the rotor head points toward north, Z mag is positive. Next, set DUMP_MAG to 0 and DUMP_THETA to 1. With the autopilot running, rotate the airframe on the yaw axis. The printed heading should be North: 0, East: 90, South -179/179, West: -90. If the heading increases when it should decrease, reverse COMPASS_SIGN in settings.conf. If the heading is always offset by a certain amount, change COMPASS_OFFSET in settings.conf to correct the offset. Finally, you need to set DECLINATION to the magnetic declination for your area. If magnetic north is 14' East of true north, set DECLINATION to 14. With the autopilot running, rotate on the yaw & pitch axes to verify the compass reading is mostly independant of the attitude. **** Swashplate calibration The swashplate can be controlled with algebraic mixing or a neural network. Algebraic mixing is no longer tested or used because it is nonlinear & less predictable. The neural network correlates an exact blade pitch to the servo PWM. Enable USE_NEURAL_CYCLIC in arm_config.h to use the neural network. Comment it out to use algebra. In settings.conf, the section entitled SWASHPLATE MIXING FOR ALGEBRAIC METHOD is the PWM gains for this method. There is a bit of magic to get these to work. The section entitled SWASHPLATE MIXING FOR NEURAL NETWORK METHOD is for the neural network. These also take a bit of magic. The swashplate neural network must be trained with video. Set SWASH_TEST to 1 in settings.conf. The swashplate test now runs every time power is connected and then the flight program quits. Swashplate test parameters are in arm_config.h under SWASHPLATE TESTING PARAMETERS. 1) Mount the LED jig to a blade grip without the blade. - Straighten the other blade. 2) Jam the main shaft to keep it from turning during the tests. 3) Take sharp, long focal length, closeup video from each of the 3 camera positions in doc/neural_swash.xcf.bz2. - rotate the grip with the LED jig to point towards the camera. - Keep main shaft as vertical as possible. - Do video in a dark area so nothing is close to the LED brightness. - Make sure a visual cue is visible for angle 2 because nothing moves in the first servo position. 4) Clean the video & export 1 high quality quicktime movie for each camera position. - The cyclic test's starting angle should begin on frame 0. - The first servo movement should be half of SWASH_PERIOD into the video. 5) Tweek macros in swash.c to set the video search ranges, LED threshold, & filenames for the 3 camera positions. 6) Run 'make swash' & 'swash' 7) View the console output on a text editor to make sure the timing was right. - if timing for angles 0 & 1 is right, the pitch reverses direction after servo 0 is held constant for 2 SWASH_PERIODs. - if the timing for angle 2 is right, the blade pitch should only change when servo 0 is held constant for 2 SWASH_PERIODs. - the output is always noisy but this test should be done in the software. 8) cyclic.conf pops out containing the swashplate neural network weights. - Copy this to /root on the Gumstix. This utility requires Quicktime 4 Linux & Libmpeg3 to be built in a directory next to VicaCopter. USER GUIDE The transmitter has 4 switches: Autopilot enable -> switches on the autopilot program Engine mode -> When on, the motor spins up to fixed RPM and the left stick controls collective. When off, the left stick controls throttle and the collective is fixed to the last value. Operator mode -> Determines if the right stick controls horizontal movement or vertical + heading in autopilot mode. Camera -> Enables the camera shutter program Format of path.conf LATITUDE LONGITUDE ALTITUDE HEADING SONAR_LIMIT MAJOR FLIGHT COMPUTER PARTS 200Mhz computer (Gumstix Basix + Thumbstix) - Recommend 600Mhz compter (Gumstix Verdex XL6P + Thumbstix) Microcontroller with 8 analog inputs (PIC 18F4580) 3 x analog gyros 75-90deg/sec (ADXRS401) 3 axis analog accelerometer 2-3g (ADXL330) - Recommend digital equivalents 3 axis magnetometer (Micromag3) GPS module (EM406) - Recommend Hemisphere 20Hz carrier phase board 72Mhz receiver Analog inertial components probably have faster data rates, key to rate damping. All the parts are required. She won't fly if any part isn't working. Prices rise very fast in the short term so it pays to order all at once instead of piecing it together. MAJOR GROUND STATION PARTS 72Mhz transmitter 4 3 pin switches The switches must have 3 pins. Microcontroller with 8 analog inputs (PIC 18F458) There are better radio sets which don't need any hacking to do what we need. The transmitter needs to send the following bits in addition to standard flight controls: autopilot enable - sends Vicacopter into autopilot mode idle up - flight head speed or cutoff camera enable - enables camera shutter guidance mode - whether cyclic determines horizontal or vertical speed in autopilot mode GROUND STATION GUI The ground station GUI runs in Java. To run it, you need to download and install Java OpenGL from https://jogl.dev.java.net/. Uncompress the jogl archive. For Linux, copy the .so and .jar files to the jre/lib/ directory inside your jdk directory. You also need the Java Communications API from http://www.sun.com. For Linux, copy the lib/.so files to the jre/lib/i386 directory inside your jdk directory. Copy the jar/.jar files to the jre/lib/ directory inside your jdk directory. Finally, copy the docs/javax.comm.properties file to the jre/lib/ directory inside your jdk directory. Next, you have to configure the Communications API for your serial ports. The javax.comm.properties file needs new lines for each serial device not already listed. Edit the ground.sh file in Vicacopter to point JAVA_HOME to your jdk directory. Run ground.sh to bring up the ground station. ground.sh -h shows command line options The ground station can play back recorded flights or show realtime telemetry. Currently, it only takes keyboard input. i - speed up playback of flight recording u - slow down playback of flight recording shift U - upload file on wireless link m - toggle map q - quit < - zoom out map > - zoom in map The ground station has more options in ~/.vicarc TRANSMITTER USAGE When autopilot is off, the transmitter works normally. When autopilot is on, Vicacopter tries to hover in the current position. The left stick does nothing. The right stick controls climb rate/heading or forward/sideways speed depending on the guidance mode switch. 1 waypoint is stored in the flight computer flash. If waypoint mode is store, guidance commands write the new positions to the waypoint flash. If waypoint mode is recall, she flies to the stored waypoint and guidance commands do not write to the flash. Camera enable causes a shutter pin to be raised every certain number of seconds to trigger a camera. TRANSMITTER OPERATION A single trace in most 72Mhz transmitters carries all the flight control data to the transmitter block. The manufacturer's data trace is ground away and both ends are soldered to PIC terminals. The user may revert to the manufacturer's data by removing a jumper on the PIC circuit or use Vicacopter's data by inserting the jumper. Vicacopter data is a modulated binary signal from the PIC. The binary signal is phase shift keyed. 4 bits are encoded in each inversion of the data line. The inversions have 16 possible delays. The delays are based on the fastest data rate the Hitec transmitter and GWS receiever can handle. The transmitter repeats a fixed length packet over and over. The packet contains a checksum, status, and digitized stick positions. The checksum removes most errors from the data path. Further checking ensures the motor can't turn on if the transmitter is off. The status of the switches is stored in the status bits. Another status bit tells if the packet contains stick positions or user data. A method exists for uploading user data to the flight computer but it was never used. The compromise with digital control is the stick positions are updated more slowly than analog control. FLIGHT COMPUTER OPERATION The flight computer uses a PIC and a much faster ARM processor. The PIC digitizes the following analog signals: 3 gyros 3 accelerometers reference voltage battery level The PIC also provides rate damping, decodes the radio packets, reads the magnetometer, and drives the servos. There is no flybar or heading gyro on Vicacopter. Rate damping was only possible on the PIC, not a serial loop. The PIC sends data in fixed length packets on a serial port to the ARM. These packets are checksum protected. The ARM reads the GPS module and the PIC data from 2 serial ports. The ARM sends servo positions, camera shutter, and status LED commands to the PIC in its own fixed length packets. To digitize the gyros & accelerometers, the PIC requires a fixed reference voltage on one A/D input. The gyros provide this reference voltage. Without it, the house voltage drifts too much to get useful gyro results. The reference voltage is subtracted from the other digitized voltages to get stable measurements. Another problem is that the A/D converter is not linear. The neutral gyro voltage must be as close to halfway on the A/D range as possible or they'll over emphasize one turn direction over another. This doesn't matter as much for the accelerometers. The PIC lowpasses the analog measurements, computes PWM feedback for rate damping, then sends the measurements on to the ARM. The rate damping multiplies lowpassed analog readings by a straight proportional constant to get offsets for the PWM. The ARM converts the PIC navigation data to an orientation and position. It does not use a Kalman filter, but rotates a quaternion by the gyro steps to get orientation. The gyro steps are applied to the quaternion of the world frame, not the aircraft frame. Then the world quaternion is inverted to get the aircraft quaternion. A second orientation is computed from the accelerometers and the magnetometer. Because North is not horizontal but points down, the magnetometer reading is rotated by the current roll & pitch to get the horizontal heading. The heading + the roll & pitch from the accelerometer comprise the absolute orientation in Euler format. GPS is not used in centering the orientation. It's not accurate enough. The aircraft quaternion from the gyros is converted to Euler angles and then blended with the Eulers of the absolute orientation to eliminate drift. Only blending the Eulers works. Blending the quaternions using a SLERP operation doesn't work. The final orientation estimate is sent to the rest of the loop at 25Hz. Position, velocity, and acceleration is determined purely by GPS. GPS is faster than any inertial methods. The horizontal GPS position is converted to meters by simple scale factors. Naturally the scale factors must change if she changes latitude by a significant amount. Velocity prediction is also required for autonomous flight. That is determined by combining GPS acceleration & commanded orientation in a neural network. The neural network takes the most recent GPS acceleration in one axis, commanded orientation in 1 axis, and outputs the predicted acceleration in 1 axis. There are 3 neural networks: X, Y, Z. The X network takes previous sideways acceleration & commanded roll. The Y network takes previous forward acceleration & commanded pitch. The Z network takes previous climb acceleration & throttle. Neural networks which did all 3 axes simultaneously required too much computing power for little improvement. The neural networks are trained in flight from a table of most recently recorded data. GPS acceleration is determined by subtracting GPS velocity readings. This measurement is delayed significantly, so when tabulated for the neural network, the most recent GPS reading is matched to orientation readings which have also been delayed. For each GPS reading, the neural network iterates 2250 times over a static table of acceleration vs orientation. Because the ARM has very slow context switching, the neural network is trained 90 steps at a time during each update of the orientation estimate. Until it hits 2250 iterations, the neural network can't be used for prediction. A second network from the last training table is used for prediction. The latest orientation estimate and GPS acceleration is fed to the prediction neural network. The predicted acceleration result is then added to the latest GPS velocity to get a predicted velocity. For autonomous feedback, the latest position error and predicted velocity error are fed to PID equations to get the desired orientation. The desired orientation is relative to a hard coded "neutral" orientation. The neutral orientation is the orientation that gives 0 acceleration and for now is the last orientation detected before autopilot was enabled. Another stage of PID equations convert the orientation error to servo offsets. FAILURE MODE The failure mechanism is based on cascading failures. If Vicacopter's PIC doesn't receive data from the ARM in a certain time, it switches to failure mode. If it receives data but the radio valid bit is 0 for a certain time, it switches to failure mode. The ARM always sends data when it is running because the radio isn't reliable enough to give the servos the necessary, constant inputs. In failure mode, autopilot is immediately disabled. The servo pulses are held constant. The throttle is slowly reduced to 0. NOTE: the 0 PWM for throttle is hard coded in pic_config.h It changes depending on the ESC. Some of them don't cut off if throttle PWM is too low. FLIGHT RECORDING If we record flight data on th ... ...

近期下载者

相关文件


收藏者