Pretty cool outfit with an out there idea
All Posts (11086)
Sort by
Please note that NMEA GPS modules are now supported (thanks HappyKillmore!) and the Xbee test now works.
We need more people flying this code and filing bug reports so we can release a non-beta 1.0 and move on to more feature enhancements. So please try this code out, put it in the air, and file an issue report for any problems you find here.
Some video of FoxTeam member with their QuadFox ..
We're flying and testing stable mode using Arducopter MP ( MultiPilot revision) .. the result is fantastic ;)
Then next step will be GPS hold and return to home ... ;)
Put GoProHD on QuadFox and fly only using throttle and yaw i don't touch roll ..
for more info see my blog : http://www.virtualrobotix.com/profiles/blogs/quadfox-stable-mode-test-work
Or slightly rephrased: The IMAV 2011 summer edition rules are out (original post). IMAV2011 is actually a perfect showcase why IMU-based autopilots plus onboard computer vision are a good choice for MAV competitions. And it is also a good occasion to mention the currently running pxIMU batch order, limited to October 20! You can get your own competition-proven , computer-vision ready research autopilot. For the time after the batch order: We provide all participants of the batch order the hardware design on request, so that they can build more hardware if needed later (and we'll offer future batch orders if feasible). The design files will also be made available GPL-ish licensed at some point early 2011.
Now back to IMAV 2011 itself: Why all-weather and swarms? The competition location in The Netherlands can be quite cloudy and windy in September, like in the last Delft-competition, the EMAV 2009. Although there was no rain, virtually no fixed-wing team was able to fly autonomously, as all relied on thermopiles. This time RC-based flight is banned, so any team sticking to thermopiles is taking chances! By now there are some hackable IMU-based fixed wing autopilots around (ArduPilot, UAVDevBoard v3 and soon pxIMU). We actually hope for similar weather conditions in 2011: An overcast sky provides computer-vision-optimal diffuse lighting (perfect to e.g. locate pylons using pxOvero) and by using pxIMU or any other IMU-based autopilot, the attitude estimation does not depend any more on a more or less clear sky.
And why swarms? Because the IMAV 2011 rules actually encourage teams to run multiple vehicles. We're really happy about this development, because the complete PIXHAWK framework is optimized towards swarm-use. Ongoing research in the team involves mesh-based image transmission (which would allow to transmit images over multiple hops (a chain of MAVs) to a base station). QGroundControl has also been optimized to scale to multiple vehicles from early on. For details on the rules, please refer to the preliminiary rules PDF.
The credits of this video is from Jose Antonio Vela
More info at the spanish forum: http://www.aeromodelismovirtual.com/showthread.php?p=117681#post117681
or
http://www.rcgroups.com/forums/showthread.php?t=1322368
cheers
http://projects.electrictoast.net
So far, I've gotten the HIL simulation working with X-Plane. Instead of the provided pearl script, I'm using my own Processing application to translate between the APM and X-Plane. It runs on a seperate laptop, and also can display other useful information (control deflection, accelerations, attitude, etc) that help with debugging. I will probably be testing the plane on its own in normal RC configuration fairly soon.
I've also been trying to include a little bit of more basic stuff, like care of LiPo batteries, and how voltage dividers work, but I would be glad to answer questions of how things work, or why I'm doing something in some way if I haven't explained it clearly.
This is a little proof of concept video I just put together. The goal is to always keep my aircraft's shadow in the field of view.
Equipment: Senior Telemaster. Fly-Cam-One-3 with built in pan/tilt. Sparkfun 6DOFv4 IMU (it was laying around so I used it.) Gumstix flight computer. Ardupilot used for controlling pan/tilt servos on the camera.
The flight is 100% manually piloted. Camera is 100% automatically pointed.
On board I am running a 15-state kalman filter for attitude estimation. The filter converges to "true" yaw angle independent of ground track, wind, and magnetometer. This is actually critical for camera pointing.
On the ground I have small app I whipped together Thursday evening that computes the sun location for the current time in ECEF coordinates. Then converts the sun "vector" to NED coordinates based on a GPS connected to the ground station (assuming I'm not ranging very far from my start point.) The code computes a new sun angle every minute. Finally, the sun vector is inverted to get a shadow vector and that is sent up to the aircraft as it's target point vector (once a minute.)
Notice: sun vector * [ -1 -1 -1 ] = shadow vector.
Also: sun vector * [ 1 1 -1 ] = reflection vector (where we would be looking at the suns reflection off surface water.)
Also: sun vector * [ 1 1 1 ] = rainbow vector if we would happen to fly above the clouds (this would keep us looking at the center of a rainbow circle/arc.) :-)
In order to run myself over with the shadow from the aircraft's perspective I need to fly the airplane through the sun from the ground pilot's perspective.
Disclaimers: this was my first time out trying something like this so the video is rough. The pan/tilt on the flycam is very low grade, but works well enough for a demo. I'm also flying with an IMU that is about 2 orders of magnitude coarser than I'm used to flying with, so that degrades my attitude estimation more than I would have liked (but the filter still converges.) I put very little effort into aligning the IMU mount with the camera mount, so there are certainly a few degrees of bias just from mounting issues. Finally, I only eyeballed the mapping between servo commands and pan/tilt angles so I'm in the ball park, but there are certainly errors there too. It's a hack, but made for a fun afternoon. :-)
Good news: ArduIMU 1.8 has now been released, which is now built on the same libraries as ArduPilotMega and ArduCopter. [Update: this has now been revised with bug fixes as 1.8.1. See this post for more.] That means that it's got all the latest Ardu* enhancements, including support for the most recent GPS modules (including latest MediaTek firmware), our custom FastSerial communications and magnetometer support. If you've been having trouble with GPS modules not getting lock, please upgrade to this latest version.
You can get the new code here. Note that since it now uses libraries, the installation process is different. Please follow the instructions here. Arduino 0019 or higher required.
If you encounter a bug or other problem, please file an issue here. The developers aren't regularily following comments on blog posts, so the past way to get bugs fixed quickly is through the issue tracker.
Special thanks to Doug Weibel for the port and to the whole APM team for the libraries, which are really paying off now that we're extending them to all the Ardu* projects.
I'm working at the new DIY Drones factory in San Diego today, and I thought I'd share some pictures so you can see where the magic happens! Jordi is the guy standing on the right above. Most conversations are in Spanish, but everyone speaks excellent English, too.
There are currently 8 full-time employees, including Jordi (I'm not an employee, just a co-founder). Here's what some of them do:
Loading ArduIMU firmware and testing the boards with a custom jig.
Here's that jig
The pick-and-place machine
The shipping station
Applying solder paste with a stencil and hand-placing some super-delicate components
Hand-finishing boards and GPS modules that have parts that the pick-and-place machine can't handle.
The original toaster oven we used for reflow! Now still used sometimes (it's outside, so we don't have to vent it). The new automated reflow oven, with a proper conveyor belt, is just waiting to be vented inside.
Lots of room for flying at the baseball field out back!
Android Phone Center of Gravity Calculator.
Here is a free Android Phone CGC (Center of Gravity Calculator) for planes.
It will calculate the position of the center of gravity of an airplane
using the tip chord, root chord, sweep and required CG in percent,
measured back from the leading edge at wing root.
It's free, released as donationware, just download the .apk file below
and use Astro File Explorer or Estrongs File Explorer (or equiv.) to
install it. (I'm busy working on getting it onto the Android Market.)
It's pretty intuitive but instructions are behind the 'Instructions' button
Comments and suggestions welcome!
Please try it out and send it to anyone who might be able to use it! (or point them to this post)
CGcalc.apk (Right Click > Save Link As: )
Thanks
Graham Dyer
(RCGroups: http://www.rcgroups.com/forums/showthread.php?t=1322984&pp=100#post16295945)
Super early demo of my video overlay code. This is a post process that occurs after the mission to overlay the data on top of the video from my cheap Chinese camera. Note that the video is not in sync with the data, and is off by approx 250 ms. This is due to a reboot that occurred during the flight (cause unknown).
The code that draws the instruments is the same code that runs on my ground station. That happens to be displaying on a 256x128x1 vacuum flourescent display, hence the rather low resolution instruments.
This is the same flight I posted earlier, but with the video overlay.
KDA 20-20L ($12.88) x 4: $51.52
HK SuperSimple 18-20 ESC: x 4: $31.20
Zippy 4000 mah 40C battery: $24.74
Zippy 500mah 20C battery: $6.43
Optional, but I like having a separate flight pack as opposed to powering via an ESC. It may be superstitious, but I'd really hate to have a brownout mess with my APM in flight.
HK-T500 Landing Gear: $3.78
Mikrokopter 500mm frame: $72.95
The MK frame is pretty pricey, and replacement aluminum riggers are pretty spendy. This will definitely be a step up with the Arducopter frame, when released.
Oilpan: $159.95
Ardupilot Mega: $59.95
Break away headers: $4.95
APC 10x4.7 Slow Flier x 2: $5.86
APC 10x4.7 Slow Flier Pusher x 2: $8.78
Spektrum AR6110E: $49.99
Radio Shack Project Enclosure: $3.99
JST Male connectors x 10: $1.99
JST Female connectors x 10: $1.55
F/F Servo Wires x 8: $12.00
I made these myself with some bare-end female servo cables from Hobbyking. But these are better :).
Optional Xbee
Adafruit Xbee adaper: $10.00
Xbee Explorer USB: $24.95
Xbee Pro RSPMA 900mhz: $44.95
Xbee Pro 900mhz Wire Antenna: $42.95
F/F Jumper Wires: $4.50
For connecting the Xbee to the Oilpan...
Total of the above: $614.98
I'd highly recommend getting an Xbee setup, since there are issues with blowing outputs on the APM when connecting speed controls and USB at the same time. That means that tuning PID values and testing is a MAJOR pain, since it requires unplugging your ESCs every time you want to plug in the USB. With Xbee you don't even have to open the electronics housing to make changes. Plus you get to look cool because you bring your laptop when you fly :P.
I also made some super-short servo extensions for my ESCs that have the voltage line cut (the red one). This prevents the ESCs from providing power to the board, since I wanted to use a separate flight battery. I found out afterwards that this may be also done by removing a solder jumper on the APM? If so, oh well... I already made the extensions.
There's a few other miscellaneous bits and pieces, such as Deans connectors for the main battery, and rubber grommets and nylon bolts that I bought for vibration isolation for the electronics platform. You can see those between the box and the platform in the pictures below. It's tough to say if they are effective or not yet, because I was having major vibration problems on my aeroquad setup (same frame, just a different box), and I haven't re-tested the aeroquad stuff after getting arducopter finished. It may just be that the Arducopter gyros and accels are less vibration sensitive. It can't hurt, though, and the Mikrokopter frame itself doesn't do much for vibration if you directly attach the electronics to it with the nylon standoffs.
This is pretty much the exact set of gear that is on my quad... Probably way more than anyone here wanted to know :).
Photos
I got my quad off the ground this morning and it worked perfectly with NO tuning needed! NONE! And I'm not using a stock frame either, I'm using a Mikrokopter 50cm frame with some modifications for vibration isolation (just an extra platform with some rubber grommets + nylon bolts)...
Setup:
APM/Oilpan
KDA motors from Hobbyking
HK SuperSimple ESCs with high-rate Quax PPM firmware
Turnigy 5000 3cell
Turnigy 1000 2cell battery for electronics
Spektrum DX7 + AR6100
Mikrokopter 50cm frame
APC 10x4.7 props
Electronics are housed in a Radio Shack project box... I've landed upside down before and really don't want to break anything :)
The system was very easy to get up and running (especially when compared to AeroQuad, which requires a lot more assembly work with the shield, etc). Wireless telemetry via XBee was a snap, and the configurator worked awesome as always (well done, Mikro!).
Stable mode was absolutely amazingly stable... It's less "noticeable" than other stable modes I've dealt with, too. It just seems to do what it should, without any fuss... Acro flew well too, very predictable without any obvious jitter or wobbliness.
Overall, I'm totally stoked, and super excited to get a chance to try all of the position holding stuff once it's released! Again, thanks, well done, and keep up the good work!
Setup:
APM/Oilpan
KDA motors from Hobbyking
HK SuperSimple ESCs with high-rate Quax PPM firmware
Turnigy 5000 3cell
Turnigy 1000 2cell battery for electronics
Spektrum DX7 + AR6100
Mikrokopter 50cm frame
APC 10x4.7 props
Electronics are housed in a Radio Shack project box... I've landed upside down before and really don't want to break anything :)
The system was very easy to get up and running (especially when compared to AeroQuad, which requires a lot more assembly work with the shield, etc). Wireless telemetry via XBee was a snap, and the configurator worked awesome as always (well done, Mikro!).
Stable mode was absolutely amazingly stable... It's less "noticeable" than other stable modes I've dealt with, too. It just seems to do what it should, without any fuss... Acro flew well too, very predictable without any obvious jitter or wobbliness.
Overall, I'm totally stoked, and super excited to get a chance to try all of the position holding stuff once it's released! Again, thanks, well done, and keep up the good work!
Hello ArduPilots,
Here you will find my latest updated version of the ArduPilot (v2.7.4a JLN) successfully tested in autonomous flights with a Multiplex Cularis (GPS Ublox and ArduIMU v1.6). This version runs very well with the GPS Emulator v1.1.45 and you may test it yourself at home.
More photos at : http://diydrones.com/photo/albums/ardupilot-and-arduimu-on-a
The full software can be downloaded at: http://code.google.com/p/ardupilotdev/downloads/list
Here the test procedure with the GPS Emulator:Required material: Ardupilot with or without shield, it works also with Arduino board "Duemilanove"
1) Compile and upload the ArduPilot_2_7_4_JLN software to your ardupilot board
2) Download a flight plan with PlanifMission.exe (v 1.4.14), i.e. upload the flight plan "fieldtest4"
3) Run the GPSEmulator.exe (v 1.1.45):
a) choose the ardupilot comm port: i.e. COM10 then click 'Connect'
b) Select File/Run ArduPilot Mission
c) Selected Mission 'fieldtest4'
d) GPS Data Source 'GPS Emulator w/ArduPilot'
e) check 'Listen to Throttle'
f) Click on the 'Start' button on the main window
Enjoy,
Jean-Louis Naudin
Main JLN DIY Drones page: http://diydrones.com/profile/JeanLouisNaudin
Google code: http://code.google.com/p/ardupilotdev/
Glenn Rizzi is the Deputy Director of the US Army UAS Center of Excellence. In this video, he discusses the Army's deployment of unmanned technology at the tactical echelon level. Listen to him describe the US Army's Roadmap development programme with short term, medium term, and long term project goals. Swarming technologies, improved commonality and autonomy are all topics broached here, as well as the US Army's vision of what capacity the 'human element' should fulfill within the role of UAVs in a combat environment.
Hello... I have small problem with autopilot.I try to make simulation on xplane9.Before I activate autopilot everything is good.But when autopilot is on ,plane flies strait forward and climbing slowly,instead of
flying to waypoints.Ardusimulator working properly.GPS and plane IMU datas
updating well.I couldn’t figured out what is the problem.Could you help me
plese???
As you can see from image.When I activate ardupilot , it adjust plane IMU roll=0 and Pitch=between
1.5 to 4.İt doesnt control heading.it gets fix when autopilot on condition.
The X37 B very secretive air force drone appears to have just changed orbit or landed.
A team of researchers from the Massachusetts Institute of Technology (MIT) has recently demonstrated an innovative landing control system that allows planes to land similarly to birds. Since this method allows quick changes of speed and fast landings, it might improve future aircraft...
From The Future of Things: "Airplanes’ landing procedure is common knowledge. First, the plane maneuvers slowly into an approach pattern; then, there is the long descent, and finally, the wheels touch the ground and the pilot applies the brakes until the plane comes to a full stop. In comparison, birds switch from barreling forward at full speed to lightly touching down on a target as narrow as a telephone wire. Now, a team of scientists tried to understand this difference in order to improve landing technique for airplanes.
According to this recent study, birds’ ability to land precisely depends on a complicated physical phenomenon called "stall." In fluid dynamics, a stall is a reduction in the lift coefficient generated by an airfoil as angle of attack increases. This occurs when the critical angle of attack of the airfoil is exceeded; typically, about 15 degrees, but it may vary.
When a commercial airplane is changing altitude or banking, its wings are never more than a few degrees away from level. Within that narrow range of angles, the airflow over the plane's wings is smooth and regular, like the flow of water around a small, smooth stone in a creek bed. However, when a bird approaches its perch it will tilt its wings back at a much sharper angle; it makes the airflow over the wings turbulent, and it creates large vortices — whirlwinds — from behind the wings. The effects of the vortices are hard to predict; for instance, if a plane tilts its wings back too far, it can stall and fall out of the sky (hence its name).
The newly designed control system is based on mathematics, and developed by MIT associate professor Russ Tedrake, a member of the Computer Science and Artificial Intelligence Laboratory, and Rick Cory, a PhD student in Tedrake's. Their challenge was to describe the stall phenomenon mathematically; although most engineers understand it, modeling it is time-consuming, in terms of computation.
The developed model enabled Professor Tedrake and Cory to guide a foam glider to its perch, but executing a fluid landing was not that simple "It gets this nominal trajectory," Cory explains. "It says, 'If this is a perfect model, this is how it should fly.' But, because the model is not perfect, if you play out that same solution, it completely misses."
The imperfections of the initial model drove Cory and Tedrake to develop a set of error-correction controls that could nudge the glider back onto its trajectory when location sensors determined that it had deviated from it. By using innovative techniques developed at MIT's Laboratory for Information and Decision Systems, they were able to calculate precisely the degree of deviation that the controls could compensate for.
The control system ends up being a bunch of tubes pressed together like a fistful of straws. The addition of the error-correction controls make the trajectory look like a tube snaking through space; the center of the tube is the trajectory calculated using Cory and Tedrake's model, and the radius of the tube describes the tolerance of the error-correction controls. Once the glider launches, it just keeps checking its position and executing the command that corresponds to the tube in which it finds itself. The ultimate solution found allows the glider to constantly be in one of the possible courses; if it goes so far off course that it leaves one tube, it will still find itself in another.
A cruising plane tries to minimize its drag coefficient—the measure of air resistance against a body in flight. Usually, when an aircraft is trying to slow down, it tilts its wings back in order to increase drag. Ordinarily, they cannot tilt back too far, for fear of stall. However, because Cory and Tedrake's control system takes advantage of stall, the glider has a drag coefficient that is four to five times that of other aerial vehicles
There are several potential applications for the new system. For one, the U.S. Air Force has been interested in the possibility of unmanned aerial vehicles (UAVs) that could land in confined spaces; therefore, it has been funding and monitoring Tedrake and Cory’s research. "What Russ and Rick and their team is doing is unique; I don't think anyone else is addressing the flight control problem in nearly as much detail," says Gregory Reich of the Air Force Research Laboratory. More accolades come from Boeing, who gave Cory the 2010 Engineering Student of the Year Award for the system’s development.
Still, current design interferes with the military’s plans: In the conducted experiments Cory and Tedrake used data from wall-mounted cameras to gauge the glider's position, and the control algorithms ran on a computer on the ground that transmitted instructions to the glider. "The computational power that you may have on board a vehicle of this size is really, really limited," Reich says.
Despite the drawbacks mentioned Tedrake is optimistic, saying that in a few years’ time computer processors will be powerful enough to handle the control algorithms. In the meantime, his lab has already begun to address the problem of moving the glider's location sensors onboard. On a humorous note, Cory concludes: "I visited the Air Force, and I visited Disney, and they actually have a lot in common: the Air Force wants an airplane that can land on a power line, and Disney wants a flying Tinker Bell that can land on a lantern."
TFOT has also covered CyberQuad, a UAV capable of vertical take-off and landing, and Deep Throttling, a technology developed by NASA to make smoother landings.
For more information about the technology that allows planes to land like birds, see MIT’s press release."
According to this recent study, birds’ ability to land precisely depends on a complicated physical phenomenon called "stall." In fluid dynamics, a stall is a reduction in the lift coefficient generated by an airfoil as angle of attack increases. This occurs when the critical angle of attack of the airfoil is exceeded; typically, about 15 degrees, but it may vary.
When a commercial airplane is changing altitude or banking, its wings are never more than a few degrees away from level. Within that narrow range of angles, the airflow over the plane's wings is smooth and regular, like the flow of water around a small, smooth stone in a creek bed. However, when a bird approaches its perch it will tilt its wings back at a much sharper angle; it makes the airflow over the wings turbulent, and it creates large vortices — whirlwinds — from behind the wings. The effects of the vortices are hard to predict; for instance, if a plane tilts its wings back too far, it can stall and fall out of the sky (hence its name).
The newly designed control system is based on mathematics, and developed by MIT associate professor Russ Tedrake, a member of the Computer Science and Artificial Intelligence Laboratory, and Rick Cory, a PhD student in Tedrake's. Their challenge was to describe the stall phenomenon mathematically; although most engineers understand it, modeling it is time-consuming, in terms of computation.
The developed model enabled Professor Tedrake and Cory to guide a foam glider to its perch, but executing a fluid landing was not that simple "It gets this nominal trajectory," Cory explains. "It says, 'If this is a perfect model, this is how it should fly.' But, because the model is not perfect, if you play out that same solution, it completely misses."
The imperfections of the initial model drove Cory and Tedrake to develop a set of error-correction controls that could nudge the glider back onto its trajectory when location sensors determined that it had deviated from it. By using innovative techniques developed at MIT's Laboratory for Information and Decision Systems, they were able to calculate precisely the degree of deviation that the controls could compensate for.
The control system ends up being a bunch of tubes pressed together like a fistful of straws. The addition of the error-correction controls make the trajectory look like a tube snaking through space; the center of the tube is the trajectory calculated using Cory and Tedrake's model, and the radius of the tube describes the tolerance of the error-correction controls. Once the glider launches, it just keeps checking its position and executing the command that corresponds to the tube in which it finds itself. The ultimate solution found allows the glider to constantly be in one of the possible courses; if it goes so far off course that it leaves one tube, it will still find itself in another.
A cruising plane tries to minimize its drag coefficient—the measure of air resistance against a body in flight. Usually, when an aircraft is trying to slow down, it tilts its wings back in order to increase drag. Ordinarily, they cannot tilt back too far, for fear of stall. However, because Cory and Tedrake's control system takes advantage of stall, the glider has a drag coefficient that is four to five times that of other aerial vehicles
There are several potential applications for the new system. For one, the U.S. Air Force has been interested in the possibility of unmanned aerial vehicles (UAVs) that could land in confined spaces; therefore, it has been funding and monitoring Tedrake and Cory’s research. "What Russ and Rick and their team is doing is unique; I don't think anyone else is addressing the flight control problem in nearly as much detail," says Gregory Reich of the Air Force Research Laboratory. More accolades come from Boeing, who gave Cory the 2010 Engineering Student of the Year Award for the system’s development.
Still, current design interferes with the military’s plans: In the conducted experiments Cory and Tedrake used data from wall-mounted cameras to gauge the glider's position, and the control algorithms ran on a computer on the ground that transmitted instructions to the glider. "The computational power that you may have on board a vehicle of this size is really, really limited," Reich says.
Despite the drawbacks mentioned Tedrake is optimistic, saying that in a few years’ time computer processors will be powerful enough to handle the control algorithms. In the meantime, his lab has already begun to address the problem of moving the glider's location sensors onboard. On a humorous note, Cory concludes: "I visited the Air Force, and I visited Disney, and they actually have a lot in common: the Air Force wants an airplane that can land on a power line, and Disney wants a flying Tinker Bell that can land on a lantern."
TFOT has also covered CyberQuad, a UAV capable of vertical take-off and landing, and Deep Throttling, a technology developed by NASA to make smoother landings.
For more information about the technology that allows planes to land like birds, see MIT’s press release."
