"I guess it’s cold enough up thar in Norway that even UAVs need their own little comfy modernist Scandinavian drone huts that look rather a lot like mailboxes. They’re part of Scandicraft’s ScanCam perimeter security system, and the idea is that the huts act as base stations for roving semi-autonomous quadrotors that are controlled remotely. The quadrotors can launch, recover, and recharge themselves at their huts (or “hangars” I guess), and when it snows (which I hear it doesn’t do once or twice a year), the bots can stay snug at home, enjoying their stylish furnishings which you can find at your friendly neighborhood IKEA as part of the new Röböüüüt collection.
Good news: you can now use the standard ArduPilot GCS with ArduPilot Mega!
Just select option 2 ("ArduPilot Legacy") in your GCS protocol in the config file of the latest code, and APM will drive the GCS just like ArduPilot. Try tilting the APM board and watch the artificial horizon move along. Very cool
//0-4 Ground Control Station: #define GCS_PROTOCOL 2
// 0 = Ardupilot Mega Standard Binary // 1 = special test, // 2 = Ardupilot Legacy // 3 = Xplane // 4 = Ardupilot IMU out // 5 = Jason's GCS, // -1 = no GCS (no telemetry output)
Automatik is hard at work updating the GCS to support APM natively, with all the additional functionality it brings, but for now you've got a great GCS with all the cool stuff like moving maps and voice synthesis, all ready to go.
Posted by Tim Trueman on August 11, 2010 at 1:30pm
This week we were joined by Doug Weibel and Jason Short, the team leaders of the ArduPilot and ArduPilot Mega code project. They're the ones working hard on getting the APM Beta ready for release at the end of the month (alpha is already out, of course), and talked about the design and feature decisions they made with APM, as well as the roadmap for 1.0 (in September) and beyond.
Posted by Gary Mortimer on August 10, 2010 at 11:30pm
Have been flight testing this back to basics wing, very pleased with it so far.
If you want one ask Rob @ Flying Wings http://www.flyingwings.co.uk Very simple task, Canon IXUS 100IS for 15 minutes in the air.
Thats the IXUS at the front, this is only the second one we have built so its not covered and a little raw!!! But it flies very well. I'm out of the door to fly it again.
It will be part of the YellowPlane stable and I guess we originally thought of calling it Manta 4 as its the forth version of a flying wing UAV that we have made. During design it acquired the nickname prawn cracker (don't ask) and the original task request made a natural name change. No prizes for guessing the agency that wants one.
Good data from Doug Weibel today, who was testing the uBlox GPS vs the onboard absolute pressure sensor on ArduPilot Mega with his NexStar Mini EP. In general the uBlox is performing great. And we love the onboard datalogging on APM!
Doug explains the modest data diversion between the two sensors:
"You can see that in the area from roughly 1600 to 2500, there is greater difference between the two altitude measurements. This coincides with when I let my son fly the plane and took it out of fly by wire mode and put it in manual. He was busy trying to get the little NexStar Mini EP to do some aerobatics. Since he was spending a lot of time in very high bank and pitch angles I would guess that the uBlox performance was suffering and the baro altitude was more correct."
The first Open Hardware Summit will be held September 23rd in New York City, DIY Drones will be there, along with most of the other leaders in the emerging open source hardware movement. The group organizing this needs donations to cover costs, so please consider donating any amount--$20, $50, even $100--and help sponsor the conference. Sponsors get call-out love!
Posted by Mark Griffin on August 10, 2010 at 7:30am
Here is my successful entry to the competition.
The aircraft I used was an Multiplex Funjet with the Paparazzi autopilot guiding the aircraft autonomously and calculating the drop location. The algorithm took into account egg weight, windspeed, wind direction, groundspeed, height from ground, and drag. I constructed a servo-actuated release mechanism inside the Funjet for the egg drop.
The field location was near Givrins, Switzerland. The weather was hot and sunny with some wind.
I acheieved a good result; The unprotected egg landed approx 1 metre from the Home position and smashed spectacularly. The video gives the best idea of what exactly happened. http://vimeo.com/14030111
At release, the airspeed was 20 m/s (72 km/h) and the height above ground was 54 metres.
The kmz file showing the Home, release and egg land positions is here: Griffin_T3R82.kmz. Here is the kml in case you can't see the track in the kmz: Griffin_T3R82.kml
This exercise was a whole lot of fun!!!!!
Here are some photos of the egg release mechanism:
Posted by Graham Dyer on August 9, 2010 at 11:30pm
While not autonomous, the amazing stability in the video's belie the relatively simple (& cheap) build. Strangely some of the components required are out of stock at HobbyKing.com... :)
I designed this protocol since few months ago but it lost in hole of internet.
I hope it helps someone.
Everyone using video transmitters on UAV/FPV planes and audio channels empty or only transmitting propeller sound, this is why i designed this telemetry protocol on audio ;)
Advantages of Audio Telemetry Protocol (ATP)
You don't need any extra hardware except your Autopilot/OSD's processor for transmitting datas
You can receive all data without any hardware with your PC/laptop
Audio channel less noisy than video
%90 of video Tx/RX modules supports ATP's 2000-1300hz audible waves without any problem
How ATP Works?
ATP uses AFSK method to sending telemetry data over VideoTX’s audio
channel. The carrier is 2100Hz and a byte starts with one 1300hz wave(start bit), ATP sends
data bits after the start bit. and it sends minimum 10 carrier wave(zero) before a new start bit.
This code generates static 2100hz square waves, put a 100nf capacitor on outside of processor and connect it on Audio in of TX, now you have a sinus on RX side ;)
You can send the bytes any time in your main code flow because AFSK protocol following waves not time sensitive protocol. modem[] is an byte array that filled with data to send. modem_byte is an integer for selecting byte of modem[] array modem_bit is an char for counting sinus waves of AFSK
This code sends start bit at start and 8 bit of byte, you should wait for 5ms for next byte for balancing sinus waves on audio stream, then you can send another byte also.
modem_bit = 0;while (modem_bit<18) //wait for all bit waves {
if ((modem_bit%2==0) && ((PINB & (1 << 2))) ) // wait for 1 on PWM output. { if (modem_bit==0) // start bit { TCNT1H = 1; // this values creates small delay for increasing the wave width TCNT1L = 180; // and AFSK decoder can detect this big waves to 1, other small(2100hz) waves 0 }
if (modem_bit>1) { if (modem[modem_byte] & (1<<((modem_bit-2)/2))) // if bit of bte is 1, change the wave width for 1 on AFSK { TCNT1H = 1; // this values creates small delay for increasing the wave width TCNT1L = 180; // and AFSK decoder can detect this big waves to 1, other small(2100hz) waves 0 } }
modem_bit++; }
if ((modem_bit%2==1) && (!(PINB & (1 << 2)))) // wait for 0 on PWM output { modem_bit++; } }
ATP Modem Software
I wrote a modem software for reading AFSK waves without any hardware (maybe a serial 100k resistor on microphone in)
This is only software modem on the planet (or i didn't see another) :)
It is decoding AFSK codes from microphone input like an oscilloscope and giving output values from TCP for 3th party softwares. You can design your loggers, goggle earth interfaces or more with this plug.
It is using 20byte data pack for transmitting and software can separate them
First 16 byte is data bytes last 3 byte is line end and CRC
Pack of Bytes
[0-3] Latitude (4 byte = 32 bit long integer of coordinates)
[4-7] Longitude (4 byte = 32 bit long integer of coordinates)
[8-9] Altitude (2 byte = 16 bit long integer of altitude)
[10] Heading Angle (multiply it with 1.4 for finding angle value)
[11] Battery 1 voltage (divide 10 for value, 111 mean 11.1Volt)
[12] Battery 1 voltage (divide 10 for value, 74 mean 7.4Volt)
[13] Current Sensor 1 (multiply with 0.4 for value, 101 mean 40.4Ah
[14] Current Sensor 2 (multiply with 0.4 for value, 101 mean 40.4Ah
[15] RSSI (It is percentage of maximum value, 35 mean %35)
[16] Speed (km/h)
[17] Line End 1 (value 10)
[18] Line End 2 (value 13)
[19] CRC ( 8 bit totals of first 19 btye)
If you uses my original data pack Software Modem giving this type output from port 1976 (my birth year)
then you can decode your data bytes(first 16 byte)
This software only part of ATP i didn't share the codes because i want to share the protocol with all autopilot/OSD producers and i want to use their 3th party tools too.If I share the code, they can change only AFSK frequency and visuals for non compatible products.
New Features
I added direct KML file based live view for Google Earth on the new version of modem software.
You can click on plane_tracker.kml file and Google Earth connects your Modem Software to tracking the plane :)
It is already primitive because we have some connection problem on Google Earth since few months :(
Tonight we'll do podcast #28, 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 10:30 PM PST and will probably go about 40 minutes.
This week we'll by joined by Doug Weibel and Jason Short, the team leaders of the ArduPilot and ArduPilot Mega code project. They're the ones working hard on getting the APM Beta ready for release at the end of the month (alpha is already out, of course), and will talk about the design and feature decisions they made with APM, as well as the roadmap for 1.0 (in September) and beyond.
This is a great one for questions from the community, so please take advantage of the chat function. We'll keep our eye on that window and ask the team questions as they come in. Apologies for the later hour than usual, which I know is hard for people on the East Coast. The later time is due to a DevTeam meeting that comes before it; it will be a long night of Skypeing for the team!
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. Read more…
So after first connecting the engine the other way around, rain , and more rain, I finally managed to make my first flight in Stabilize mode. With just P-control on a Wingo clone, both at 0.06, it manages to maintain it's height perfectly, but it rolls around a bit.
Guess upping the P was a bit enthusiastic! I'm not posting anything revolutionary, but I'm very happy it flies :)
Picture of the APM mounted inside the plane, no video, sorry.
Posted by Dave Buckley on August 8, 2010 at 6:00am
An open question to the collective:
I am about to start developing a switching system using two spare Tx channels on my radio gear, using the Arduino Nano.
The proposed system will use the first channel as a clock, with the second channel being used as a data channel. The two channels therefore combine to become a synchronous data stream.
THE THEORY
In a 6 channel Radio control system, channels 5 & 6 are binary (not proportional) and provide either a long or short pulse for two position servo control.
AT THE TX
The output cycle of one channel will be measured at the receiver. I expect the length of a channel pulse cycle to be in the vicinity of 120 micro seconds.
Cycling through 6 channels, then, takes roughly 120 micro seconds.
I will be using the Arduino Nano to monitor the position of a number of switches (N) attached to its inputs. The status of these switches (high or low) will be sent sequentially through channel (2) after the synch. pulse (high) of channel (1).
AT THE RX
On receiving the synch. pulse from binary channel (1), the next (N) pulses (long or short) from binary channel (2) will be used to form a word that is demuxed to control the on/off status of (N) number of relays/digital switches on board the UAV.
This output is refreshed every N*120us.
In the case of 6 external switches, I'm looking at up to 240us before the change in status of any given switch, which is fine for non critical switching like lights, flaps or other equipment where immediate response is not needed.
I suppose the big question is:
"Is there a more elegant way to achieve multi switch control to your UAV", or is this proposal in itself an elegant system?
Modified ArduPilot2.6 and ArduIMU to do interprocessor communications via TWI to free up USART for full-duplex serial comm's between ArduPilot and GCS; can upload PID coefficients in flight. IPC code example: twi_stuff.zip
Test flown in manual and stabilize modes, IMU appears to be consistently and accurately reporting attitude.
Stabilize mode is solid with no oscillations using default PID coeff's, but need a way to trim pitch; taildragger isn't at cruise pitch attitude when IMU is initialized.
Using SUP500 GPS module from SparkFun; altitude values off by up to 100 meters (field elevation 1800m). GPS frequently reports altitude of 1700m at pattern height (0-20m AGL). Also seeing huge intermittent (1 second duration) errors in lat,lon on the order of +/- 2 degrees. I don't think I screwed up the NMEA parser...
Also switched to a Serial library which performs buffered transmits. This seemed to solve some problems caused by the standard library's blocking writes. HardwareSerial.zip
As we discussed a few months ago, the 2.4Ghz clone receivers have arrived. Above is the new Futaba FASST clone from OrangeRX that HobbyKing will be selling for $29.99 in September (you can pre-order now). The Spektrum clones (shown below) are already available for $14.95.
