Hi. I have made some modifications to the MatrixPilot code to do tests on In flight tunable gain. If this is further refined, it will be possible to do tuning of P/D gains on roll, pitch and yaw axis while in flight. The idea is that the gains can be tuned with a spare button on your RC transmitter one after the other (separately) while you fly the plane in stabilized mode. The gain you want to tune is gradually increased until oscillation is seen at max desired airspeed and then reduced back somewhat to ensure stability on that axis with that gain. My code mods is a hack at the moment, but this is just to illustrate the concept.
All Posts (14056)
Sort by
Hi. I have made some modifications to the MatrixPilot code to do tests on In flight tunable gain. If this is further refined, it will be possible to do tuning of P/D gains on roll, pitch and yaw axis while in flight. The idea is that the gains can be tuned with a spare button on your RC transmitter one after the other (separately) while you fly the plane in stabilized mode. The gain you want to tune is gradually increased until oscillation is seen at max desired airspeed and then reduced back somewhat to ensure stability on that axis with that gain. My code mods is a hack at the moment, but this is just to illustrate the concept.
I wanted to get a hardware in the loop sim running in X plane and I wanted to document my first attempt. I've been able to connect the ardupilot using a binary protocol and a custom Perl socket server based on the work of Jeffery Goff http://www.perl.com/pub/a/2004/07/09/xplane.html
I have everything in place, but a lot of tweaking to do. The really nice part is that there is no extra hardware or soldering to do. The IMU parser will read in the X plane output. The GCS_Xplane.pde when finished will output binary to Xplane. I'll have it working hopefully in the next rev.
If you want to try it and help make it better, I could really use the help. If you've never heard of Perl or Serproxy or Sockets, I don't think I'll be able to help you get it running.
Here is the flow of information
Ardupilot <-> Serial Port <-> Serproxy <-> Perl_AP_glue <-> Xplane
Here are the files to make it run on 2.6.2.
GCS_None.pde - I modded GCS_None.pde to output binary control surface data.
I haven't heard much talk about Jasons sim which is strange because the more I use it the more I realise how good it is.
It is certainly the best tool to use when building your own gcs. Auto mode works brilliantly and "fly by wire" is a bit of fun. The sim automatically returns to base and then loiters once all the way points have been reached. Switching back to "auto" mode starts the sim again.
Below you can see the turns which the sim produced. The telemetry included the correct lat, lng, pitch, roll, climb rate, and speed
Pros: parts are easy available, it's simple to build and repair. The main brain on this copter consist of a Gyro and receiver. That's it nothing else, performance is pretty good as well. There's also talk of a gps on this quad. I was able to fly this quad in my dinning room which is 12'x12' with no problem.
Cons: Cheap esc and brushless motors, horrible landing gear and propeller nuts that may come off even if loctite is used. For example i had a propellor come off while checking my transmitter setting and i used loctite.
I recommend replacing the propeller nuts before any major flight this will save you a lot of money on repairs if one or more propeller come off while in the air. Later down the line change out the landing gear other than that buyers should enjoy this quad.
I have posted photos of the locknuts i used to replace the propeller nuts, my 330x start to finish. If you have any question on building or in general please contact me.
Tomorrow night we'll do podcast #27, which everyone here is welcome to participate in by listening to the chat live above and commenting and asking questions via the DIY Drones chat function. We'll be starting at 9:00 PM PST and will probably go about 40 minutes.
This week we'll by joined by Richard Hanson, who the AMA's Regulatory and Governmental Affairs operations. The regulatory process to introduce UAVs in the National Airspace (NAS) is a long, tortured and potentially disastrous ordeal for us. If it goes well, we'll be given guidelines or laws under which to operate, which create a category for small amateur UAVs that allows us to operate safely and still do interesting work. If it doesn't go well, we could be banned entirely.
Want to see what we're up against? Check out this thread, by another AMA official: Excerpt: "At one time our feelings and direction were to try to leave modeling under AMA as close to status quo as possible....In fact the words that were used were "To regulate model aviation by exempting it from regulation". I am fairly certain that idea is no longer valid!"
Rich's job is to ensure that model aircraft continue to have a place in the NAS, while allowing the hobby to move forward as technology allows. So far the AMA hasn't allowed UAVs on its airfields, but it has allowed FPV under certain conditions. We'll be talking to Rich about how it's going and what we can do to help.
As always you can subscribe to the podcast here. Tonight's livecast will be recorded and available as a podcast by Tues of the next week.
Another great run by Brian Wolfe with his custom PicPilot autopilot, and he wins Round 7 of the T3 competition--the autonomous takeoff and landing round! Second place goes to Mark Griffin (Paparazzi), Third to William Premerlani (UAVDevBoard), followed by Riccardo Kuebler (UAVDevBoard) and Krzysztof Bosak (EasyUAV).
This was a tough round--not all autopilots can do autonomous takeoff and landing--so hats off to the winners. They're all real UAV pros, as shown by their consistent high performance in multiple T3 Rounds.
I'll announce the next round this weekend, and it should be a bit easier (and fun!) to encourage lots of entries. Plus it's summer--what else do you have to do??
Full list of winners and standing after 7 rounds below. Huge thanks to our judge, Gary Mortimer, who has handled the difficult task of reviewing and grading the entries (requiring the smarts of Einstein and wisdom of Solomon) with charm, good humor and constant encouragement. We couldn't do it without you, Gary!
Made a 19 Km 28 minute flight and made a video using 3 onboard cameras.
The mission was 10 Km but de wind and missing waypoints added 5 Km
the other 4 Km was flight time before and after the mission.
Setup was the same as the 7 Km flight;
http://www.diydrones.com/xn/detail/705844:BlogPost:175965?xg_source=activity
It's time to return to where we 1st envisioned having a UAV & enact the vision seen 22 years ago with real hardware.
In 1988, intended to have a manually flown, solar powered quad rotor which flew over the East Bay hills to our 1st love & provided telepresense. Still not possible to this day, but part the vision involving hovering near the school can be realized.
There it is. The vision has finally been made real.
This is where we had the 1st ideas & drew the 1st pictures of what would 1 day be a practical UAV.
But all good things come to an end, with pride.
Forgot to screw in the servo horn.
BotJunkie continues: "It’s not specified in the video what level of autonomy was used on the Delfly II… The competition permitted both full autonomy and remote control based on onboard video. At the very least, the first sequence (the figure eight around the two orange poles) seems to be completely autonomous, albeit (as far as I can tell) using a ground station to interpret the video and send steering commands to the robot.
If you think 16 grams is pretty small for an autonomous robot, don’t forget the DelFly Micro, which weighs just a hair (literally) over 3 (!) grams, and also manages to carry an onboard camera that can transmit streaming video. The DelFly Nano (1.5 grams) still seems to be a work in progress, and as for the DelFly Pico, somebody at TU Delft sneezed nearby and now they can’t find it."
[ TU Delft ]
[ IMAV 2010 ]
SparkFun's high-altitude balloon tutorial continues with several great posts, including this one on hacking regular Canon cameras to run open source firmware called CHDK:
"What is Canon Hack Development Kit? It's this amazing open source effort to create a much more flexible firmware for the Canon digital camera. Where Canon (the parent company) wants to limit the user interface so that you can only change a few controls (thus resulting in usually decent photos), CHDK opens up the camera entirely so that you can do some really crazy stuff - like active motion detection on the camera that is fast enough to photograph lightning! Remember, you don't need the SD400 specifically - many different models of Canon will do. The SD400 is 5 megapixel and decently priced so it worked out well for my first launch.
There are tons of different user submitted scripts, but the most basic (and helpful to ballooning) is the ultra intervalometer. This script allows us to tell the camera to automatically take a picture every X number of seconds. Once CHDK is installed on the camera, and the ultra intervalometer is setup, the camera will start taking pictures as soon as the camera is turned on. In the case of my payload, I setup the SD400 to take a photo every 20 seconds. It's really freaky to have a camera just sitting there snapping away photos. But that's what we want for the balloon!
Anyone remember BASIC? I found a script that is basically an interval timer (set to take a picture) but also turns off the LCD. So simple, but reasonably hard to find. Thanks Vicente Piorno! You can download my entire CHDK zip (it's better to get the right CHDK for your camera from their website), or you can grab just the script."
Reports Wired's DangerRoom blog: "While on-the-fly autonomous navigation is a first for a full-sized helicopter, the technology developed by Sanjiv Singh and his team from Carnegie Mellon is not so different from what they used to outfit a Chevy Tahoe to win Darpa’s 2007 Urban Challenge. “It’s not as if we started from scratch,” says Singh. “A lot of the technology was there already.”
To make the helicopter self-flying, the team installed a scanning LIDAR that uses lasers to collect range information from its surroundings. The laser data is processed by a computer that relays commands to the helicopter controllers.
The data also creates a 3-D map that enables the helicopter to “see” the ground or obstacles in the air — and then adjust its trajectory accordingly. The algorithms helped the helicopter miss a tall tower during one of the tests. In another trial, the team deceptively instructed the helicopter to land on top of a car, but the chopper was not fooled, resolving instead to land on flat ground nearby."
It's based on earlier RMax automomous obstacle avoidance research:
The perils of biomicry: if you're small and flappy, you look good enough to eat.
[via BotJunkie]
Well I'm back in the basement tinkering after a brief hiatus. After a couple in-air resets of the Ardupilot, I decided that I really wanted to do some simulation before commiting anything into the air again. I think the resets (and crashes) were caused by running out of RAM on the Arduino, but at least now I can give code changes a thorough shakedown before flight.
My workplace does avionics integration for real aircraft, and in most of our labs we use X-Plane and Labview to do simulation testing of aircraft avionics systems. We already have a set of VI's developed that handle all of the UDP communication between Labview and X-Plane.
I borrowed these VIs from work and wrote an interface to take the flight variables and pass them to and from the ArduPilot. I finally got everything working and my ArduPilot spent yesterday evening flying the X-Plane Cessna 172 around Ottawa.
One neat feature (I think) is how I'm getting the servo commands back into X-Plane. I built a 2-servo pitch/roll tray. On the tray I mounted my ArduIMU. The Ardupilot drives the two servos which causes the tray to pitch/roll. The ArduIMU senses this motion and sends its Euler angles back to the Labview computer. The labview computer decodes the ArduIMU pitch and Roll and sends these values over to X-Plane as Joystick positions. A couple of advantages of this method over simply outputting servo commands from the Ardupilot Serial port are:
- I'm testing the whole system (including the PWM signal code and the mux chip).
- I can fly the X-Plane aircraft in manual mode using my transmitter (more realistic, and makes a good way of positioning the aircraft for testing.)
- It's cool to see this little robot arm shift around while the aircraft flies along the flight plan.
I'll post a little video clip of the system in action later tonight.
Here are the details of my closed-loop path.
1. The computer running X-plane sends the aircraft position data (lat/long/alt/pitch/roll/heading) over the LAN to the Labview PC.
2. The Labview PC takes the X-Plane data, formats per the ArduIMU binary message protocol and sends it out the Serial port to the ArduPilot.
3. Ardupilot is set to GPS Protocol 3 (IMU) and listens to the serial data from labview thinking it's from an ArduIMU and does it's autopilot work.
4. The Channel 1 and 2 servo output from ArduPilot is connected to the little tilt table I built.
5. On the tilt table, the ArduIMU outputs Euler Angle Data (Pitch/Roll). I'm using a Sparkfun XBee USB explorer (without the XBEE) to translate the serial output from the ArduIMU back into USB format.
6. Labview reads the Pitch/Roll Data in, formats this data as a joystick position, and sends it to X-Plane.
7. Go back to step 1.
As you can see in the pictures, I am also powering the ArduPilot and ArduIMU from the computer's USB ports. This seems to work well, and I don't have to keep an eye on the voltage of a lipo pack during testing.
I can share the labview VI's I personally created for this little project. (Basically they create the simulated ArduIMU output, and read the ArduPilot and ArduIMU telemetry), however, the VIs that do the communication with X-Plane, while not complicated are not something I can give away (I like my job too much ;) )
The picture at the top of this post is the Local Map screenshot from X-Plane after completing a flightplan consisting of 15 waypoints.
Below are a couple pictures of my setup.
The Qinetiq Zephyr has been airborne for 7 days and as I write this.... 2 hours and 23 minutes. Its still flying. I believe they are going for two weeks. It took off last Friday from the Yuma testing grounds in Arizona at 1440 BST (0640 local)
Its Friday night lets all raise a glass to them!!!
XtreamBee board
ArduPilot Mega
IMU shield
MediaTek GPS
Magnetometer
Thanks DIYDrones community! We at the Royal Military College of Canada used the Ardupilot software and ground station as a basis for programming our 2m autonomous wing-sailed trimaran. This made our lives much easier while building and programming the boat during the 3 month time frame before it competed in Sailbot 2010 http://sailbot.ca.
Between Varun's modified Ardupilot code, and my modified LabView Ground Station code, there is now a complete setup available to those that have been looking for in-the-air waypoint updates.
Setup of the hardware from Varun's post: "The XBee's TX pin is hooked up to analog4 (one of the few pins we foundwas not in use) via NewSoftSerial and runs at 57600 baud. If it has a valid packet, it replaces the ArduPilot's next waypoint value with the one from the packet. After it hits this new waypoint, it loads the old next waypoint back in from EEPROM and continues on its original path."
Operation of the GCS is simple. With Google Earth already setup on a good view of the area, click 'Capture Point' on the GCS, then click somewhere on the Google Earth globe. The point's coordinates will be captured in the GCS, add an altitude, and click 'Send Waypoint'.
Since I don't own a Ardupilot (yet) I have not been able to test it. One person has successfully tested the complete setup, but please report any bugs you find.
My plane is stock:Permax 400/6v motor with 12,5 x 11 cm propeller.
The stock version is useless for UAV and FPV.Main reason is the motor, but I also think the plane may be the culprit.Gliders may fly longer, but they go with the wind.
My Multiplex EasyStar with landing gear:
There is a reason for EasyStar lack of landing gear.The reason is its poor controling behaviour(small control surfaces and big wings)
Hi. I have finished the first prototype of the lightweight KFM3 wing for my UDB2 / Matrixpilot UAV. The wing is made entirely out of Polystyrene. The benfits of this wing are: wide AOA range, wider stable CG range since lift is produced farther back on the wing surface, no aileron reflex needed so lower aileron reflex drag. I will add vinglets to reduce wingtip vortexes and drag due to vortex leakage out from the rear KFM surfaces.
This design should also give a low wingloading for autopiloted photo missions in low speed.
I have made a USD 2,- handheld cutter head for the PWM controller desribed in my previous blog post. The handheld cutter is nice for trimming off edges and so on. The spring keeps the wire tensioned. The final version don't need a series dropping resistor as the PWM driver stage uses two FETs.
The controller has also has been tested on a vertical setup for cutting spacers to my KFM3 depron wings (below):
The cutter gives nice clean cuts for vertical cutting operations (below). Please note the fan that sucks gases out from the workpiece. This is very important because blue and red foam gives off fumes that are very toxic when they are melted.
The PWM controller outputs pulses and is configurable both in duty cycle and several other parameters (below).
Based on interest, I may make a kit available.
