All Posts (14056)
The Balancing Cube is a lovely exercise in balance, dynamic control and tight gearing.
[via AdaFruit]
The thread can be found here: http://www.rcgroups.com/forums/showthread.php?t=1234310
Step 5 includes information on using the output from ArduPilot to supply GPS, pitch and roll data to the OSD. Below are a few screenshots of an EasyCAP screen and the modifications to the config tool to indicate where the moving dashes are on the OSD.
Config Tool
EasyCAP
Not to be outdone by Navy Aviator Heroine, Vika 1 made a UAV sky writing
video. The last video of skywriting was in 2008, using 1Hz GPS, no
barometer, & the T-Rex. It's the most technology ever thrown at a
single word. To this day, no-one else in the world has done it, believe
it or not.
Note ground station in bottom center.
SHORT WAVE IR
Also of interest are some short wave IR cameras if you're having trouble
seeing through haze. They look small enough to put on a model. If you need to know the price, you can't afford it.
http://www.sensorsinc.com/index.html
GROUND VS. EMBEDDED
Well, we've been using ground based autopilots since Fall 2008. It's
been much cheaper than embedded autopilot. Crashes don't destroy
anything expensive. Every vehicle shares the same ground based computer
& uses a real simple board. Regarding convenience, would say it's
equivalent to embedded autopilots.
You've got easy configuration, a full development environment,
potentially more neural network capability, but have an autopilot in 2
halves. Sensor acquisition & rate damping can only be done on the
airframe. Getting high bandwidth, reliable, realtime communication is
still complicated. Radios haven't evolved.
2 different runtime environments are required to do the job of 1.
Communication isn't perfect. Some data is lost & flight is not as
stable as it could be if all the data was getting through, especially
with GPS where 1 lost packet is .25 sec of data.
Now that ArduMU or ArduShield or whatever is flying quad rotors, it's
tempting to switch to that. If we were just starting now, we would have
just bought Ardu parts. The main problem is the extra stuff for
commercial RC transmitters & fixed wings we'd never use. The cost is
also still much higher & it still doesn't have C language flight paths.
Then there's the lure of 32 bit ARM. Reverting the ground based
autopilot to embedded is a lot easier with 32 bits.
MARCY 2 NOTES
Rebuilt the 900Mhz ground station radio with a single sided board after
it started getting flaky & Marcy 2's double sided board failed completely. It's still flaky.
The 900Mhz FSK chips have become too flaky to fly recently. An unknown
state change is happening on the PIC which can only be fixed by
resetting it, not the FSK chip. Other problems seem due to the
inaccuracy of home made boards. Marcy 1's flight board has been
perfect, ironically.
With all the problems with 900Mhz FSK chips, we're leaning towards
abandonning indoor projects, especially Marcy 2, & just focusing on a
large outdoor monocopter with the complete XBees, GPS, & SCP1000. Want
to fix the problems with Marcy 1 as an indoor, manually controlled
monocopter 1st.
She's leaning towards reverting to a bicopter to fit indoors, but the
advantage with monocopters is having the most airfoil in the highest
speed air for the least weight. That leads to longer wings.
Chord length & balance beam size are related. Wider chord length
requires longer balance beams. That leads to long, skinny designs.
We had the opportunity last week to view Snowflake field tests at CIRPAS McMillan Airfield. The Arcturus launched a pair of Snowflake parafoils from 3500-ft, and upon touchdown, the Snowflake controller transmitted GPS coordinates that were relayed to the robot. The robot then autonomously moved to the transmitted coordinates using a script written in picoC. We witnessed 3 successful UAV launch and robot retrieval cycles. Future tests will include drop of a smaller version of the Surveyor robot by parafoil.
Arcturus ready to launch. Note underwing pod carrying the parafoil.
Parafoil approaching the ground
Robot receives parafoil GPS coordinates
Robot driving through the grass to reach parafoil
Arcturus approaching touchdown
Very interesting seeing this go forward.
Should be in the shop soon.
Jose Julios quad will take some beating though, quite the thing.
Keep an eye on the store for the release.
Click Here!
Features:
-Basedon MediaTek Single Chip Architecture.
-Supply from 3.3V to 5V!
-Dimension:16mm x 16mm x 6mm
-L1Frequency, C/A code, 66 channels
-High Sensitivity:Up to -165dBmtracking, superior urban performances
-Position Accuracy:< 3m CEP(50%) without SA (horizontal)
-Cold Start is under 35 seconds(Typical)
-Warm Start is under 34 seconds (Typical)
-Hot Start isunder 1 second (Typical)
-Low Power Consumption:48mA @ acquisition,37mA @ tracking
-Low shut-down current consumption:15uA, typical
-DGPS(WAAS, EGNOS, MSAS) support (optional by firmware)
-USB/UART Interface
-SupportAGPS function
You can watch it in action here, i got 9 satellites during fly, taking in consideration a 1.3Ghz@1Watt video transmitter very near to it:
The heading and the altitude is not that bad! Soon i will release an easy to solder interface board with EM-406 "like" port.
I'm still a little fuzzy on the advantage of the "maple-seed" style monocopters, but BotJunkie has an update on Lockheed Martin's Samurai UAV:
"We heard some rumors back in 2009 that Lockheed Martin’s SAMARAI UAV project had been killed off. In fact, Lockheed Martin themselves apparently confirmed that they had stopped developing the UAV since AeroVironment won DARPA’s nano air vehicle development contract to put some polish on their robot hummingbird. So, I’m not entirely sure what the background to this video is, but it shows a much more recent (and smaller, with a wingspan of only 12 inches) version of the SAMARAI.
The SAMARAI is certainly simple (at least, compared to AeroVironment’s UAV), and as the video shows, you can just chuck it into the air, and it can land on the ground and then take off again without needing much in the way of space or infrastructure. On the other hand, I’m not sure exactly how you’d go about mounting something like a camera on a spinning airframe (maybe sync the shutter speed with the rotation speed?), and in order to operate effectively indoors, the SAMARAI would benefit from some level of resilience to impacts. At this point, it seems as though a collision with a wall or doorframe would probably knock the SAMARAI a tad askew, causing it to spin out of control and decapitate everyone in the room.
Or maybe that’s a feature."
[Paper on the project]
LabVIEW based ArduPilot Ground Control Station ( GCS) is ready for public beta test.
GCS wiki: See wiki for installation and configuration instructions (read through it, or at least watch video )
Requirements:
- Windows OS
- LabVIEW run time engine 9.0
- Google Earth ( if you already have it you don't have to re-install it. Google Earth version prior to 5.1 ( newest) should be fine)
- Ground Control Station application (zip file) - Updated May 16, 2010 !
- Data logging
- kml logging
- voice synthesis
- (UI has been redesigned, code architecture has been changed, etc.)
http://vimeo.com/11772440
more comprehensive GCS video ( worth watching ! ) is here:
http://vimeo.com/11608873
Hi all, I have a new drone in the family...
This tiny drone is able to do completely automatic flights, it can perform altitude hold (based on sonar sensor) and obstacle avoiding based on IR distance sensors (you could see the "black stange eyes" on the photo). It´s your personal droid...
Look at the video (the "tennis game" part it´s funny. Thanks to Ramon for the idea!!)
There are some new features in this thrid part... This is the list:
For outdoor configuration:
- GPS library support (actually UBLOX or NMEA)
- Position hold based on GPS
For indoor configuration:
- 4x IR distance sensors to detect obstacles (1.5m range)
- Obstacle avoiding (using distance sensors)
Common:
- Altitude hold based on Sonar (LV-EZ0)
- Automatic flight pattern (experimental).
--- Automatic takeoff
--- Position hold [outdoor] or obstacle avoiding [indoor] during a predefined time
--- Automatic descend
--- Automatic landing
- Added XBee for telemetry (and debug)
And some improvements in the code:
- New "radio test mode" to test radio equipment
- Revised control routines
Development
For the GPS position hold I had to implement the navigation algorithms for the quadcopter because it´s really different that the one used for planes...For this navigation it´s necesary to have the magnetometer to cancel the yaw drift in hover conditions. One thing I have observed is that you can only fly this tiny drone on very calm days because it´s too light for the wind... so it´s better suitted as an indoor drone. Then I started to think how to make a cheap way to navigate on indoor enviroments... I have one sharp IR disntace sensor so I start making some tests mounting the sensor in a servo to make a 180º scan. The idea was to mount 2 (or 4) of this sensors in the moving head.
On the tests I found that in this little machine the moving head caused some inestability, so I decided to mount 4 sensors in a fixed way. OK, this the cheap DIY version of an EXPENSIVE laser range finder, but it works...
there are many thing to improve and test, but it´s a promising start...
Details
Sonar module is an LV-EZ0. Because we don´t have any analog input available I use the PWM interface in a Port Change pin (PCINT20) to use an interrupt to read the sensor. (It´s recommended some solder skills to make this modification).
For the IR range finder (Sharp GP2Y0A02) I needed to use a separate Arduino Pro mini (again we don´t have any analog input free). This module connects to the ArduIMU via Serial port so we need to choose between GPS of range finder (outdoor-indoor decision).
On this III part, the hardware (ArduIMU) really show it´s limits... it´s not a problem of CPU power, it´s a problem of the limited I/O as I said before, so it´s time to move to the big brother, the new ArduPilot Mega Hardware... this new platform will be fantastic for this projects...
Behind the scenes
During the test of position hold I have some crashes (nothing important, only some broken propellers...) and there was a moment in that the quad performs not so good, so I start searching the reason. Again I suspect that it could be a vibrations problem so I decided to make a modified code to test the vibration on each motor.
As you can see I have problems on left motor, so I change this prop, also add a new layer of doubled sided foam tape to the ArduIMU and problem gone.
The code is here: Quad1_mini_test_motor_vibrations.zip (If you want to use it read the instrucctions)
Respect to the IR distance sensor, the first version was a moving head with a servo but this had some problems with vibrations that affect stability and also has a poor scanning rate, here is a photo of this prototype. Finally I decided to use 4 fixed sensors.
Codes
Some parts of this codes are still experimental but you can get it here:
Outdoor code (GPS): Quad_mini_1_27.zip . GPS libraries : GPS_libraries.zip
Indoor code (IR sensors): Quad_mini_1_29_rangefinder.zip External Arduino pro mini code: IR_distance1.zip
Old posts of this project: http://www.diydrones.com/profiles/blogs/arduimu-quadcopter-part-ii
Jose.
In case anyone's wondering, the material we use is twinwall, kind of like the plastic version of cardboard (two plastic sheets connected by flutes running between them). The thing is, I know they're used alot for SPADs but not so much for slightly more complex things - is there anything about twinwall we've massively overlooked?
I know this has taken ages (we only get an hour a week to work on this :( ) but we've nearly finished the wing and the fuselage, but there's still so much to do - at least it'll keep me occupied for the next few months at least.
If you want to see more pics or whatever, visit our blog: http://uavkes.blogspot.com
A company that won a NASA prize for beaming power to a climber in a space-elevator competition is targeting unmanned aircraft as an initial application for its laser-based technology.
LaserMotive says power beaming could extend the endurance of electrically powered UAVs. The company plans to fly a small internally funded demonstrator by year’s end.
I changed the motor driver to a l298 to provide more amps to my motors than the l293d did. (l298 picture below)
An example of automated photomapping:
typical GPS precision plus turbulence gives around 10-15m precision.
After spending one minute on manual adjustments:
This is what you have after importing automatically, without any manual adjustments, IMU corrections included but the major factor is that the camera is already almost vertical and the platform is stable:
Since the protos are taken with roll-stabilised head using Pteryx UAV,
they are ortorectilinear as the shooting angle was at worst a few deg relative to vertical.
FLEXIPILOT log decoder now take camera lens angle and mounting offset angles as a parameters, generating Google Earth file with matching photos within seconds! This is particularly useful
for isolated shots, since overlapping images when mapped in quantity give an impression of 'randomized crowd'.
Another approach: Microsoft ICE and 10min processing after drag & drop:
Unfortunately the image is a little skewed.
The major benefit of stabilised head is that all photos are of acceptable geometry and useful for stitching. However, because the precise moment of taking the photo cannot be known, an important angle and positional error will always be present in the logs. Another factor to include is changing lighting and altitude, inevitable in real-life operation and during turbulent weather (this time 42km/h flight speed and 20km/h wind speed plus strong thermals affecting pitch).
Automated mapping (AerialRobotics LogDecode) applied to a linear map:
If your UAV has wheels and you're landing on tarmac, how to stop at exactly the right spot to win the T3-6 competition? Powerslide!
From BotJunkie:
Now, part of the reason that Volkswagen/Audi are helping to fund all of this stuff is that eventually, they hope to use the technology in production automobiles to help keep us all safe. And, if you think about it, there are those occasional times where you see a parking spot open up behind you on the opposite side of the street with someone else about to snag it. By implementing this parking technology in consumer cars, you’ll be able to park that much faster, thus decreasing the amount of time that you’re on the road and therefore lowering your accident risk. Autonomous powerslide parking: it keeps you safe!"
It is a great fact that UAVs tend to miniaturization. Despite the high technology advances on microprocessors and embedded systems it is clear that only simple control laws can be implemented into Miniature Autonomous Vehicles. Note that i am not talking for rf manned control but for fully autonomous solutions. So what about Wireless Sensor Network control for Drones? It is an idea implemented widely in ground robots. The main approach is to implement on-board only the main control functions (for example stabilization with simple PID loops for safety mainly when the wirelless network is not availible for some reasons) and let advanced control laws send commands from the ground station. Obvioysly the drone will also send its state vector through the network. What's your opinion?
|------------------------|........................|-------------|
| Ground Station | <---- WSN ----> | DRONE |
|------------------------|........................|-------------|
AAC: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=330632997
MP3: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=330633212
RSS feed
AAC: http://feeds.feedburner.com/diydrones
MP3: http://feeds.feedburner.com/diydronesmp3
The folks over at Grass Roots Mapping are looking for people with low altitude aerial photography skills to help map the BP oil spill in the Gulf of Mexico.
Volunteer at their website http://grassrootsmapping.org/volunteer/
This may be a good opportunity to show the benefits of UAVs to the community at large.
-Mark W.
p.s. I'm not involved with Grass Roots Mapping. Just passing along the info.