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 ... ...
近期下载者:
相关文件:
收藏者: