Free video streaming by Ustream
Tonight (Sunday) we'll do our fifth podcast, 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 Ryan Beall, talking about his homebrew IMU autopilot Asteryx. Other themes will include
--Launch of the DIY Drones Workspace and the teams that are underway
--The conclusion of the Outback Challenge contest
--The flat-gyro era arrives
--Favorite blogs posts of the week
--And whatever other cool stuff comes up!
Read more…
Posted by Pete Burnight on October 4, 2009 at 12:30pm
While flight testing my Magpie and ArduPilot, I was having a problem with over-shoot during Way Point Navigation. After hitting the way point, the aircraft would start turning towards the next way point, and then continue turning until way past the bearing to the next way point, requiring the aircraft to make a sweeping s-turn to get back on track towards the next way point.
I suspected a number of things... the directional bearing data the aircraft uses comes from the GPS "Ground Course" data. It has no idea which direction you're actually pointing, it can only tell you the bearing between where you are now, and where you were a little while ago. I'm using the EM406 GPS, and there's a little lag in what it tells you your course is, as it tries to integrate, and smooth the data it's receiving. In addition, while my aircraft is in a high banking turn, it's actually pointing "ahead" of where the direction vector says it is, and, my GPS only puts out new data once per second, so the current course data available to the Nav functions is old, and the aircraft easily gets pointed way ahead of where I want it to.So... I did a couple things. I added code to calculate my own CMG (course made good) that didn't filter or smooth the data so I'd have better data quicker, I added a Gyro to update my current bearing based on rate of rotation during a turn, and I added some code to compensate for high bank turns, that essentially add some offset to the current heading based on how much the aircraft is banking.Works Great. The Gyro is sampled every 20 ms, and updates the variable gyroHeading based on rate of rotation. Every 200 ms I set the update flag so the nav routines think there's new data, and re-evaluate the roll set point based on the updated heading provided by gyroHeading. Every time I get new GPS data (once per second) I re-calc my own version of CMG by calc'ing the bearing BACK to where we were 1 second ago, and setting gyroHeading to this new course. That way, gyro drift is minimized (it only has 1 second to get in trouble) and I really only need the gyro during high bank turns, where the aircraft's course is changing quickly, and I'm only getting GPS data once per second. This gives the nav function 5 updates per second on the "true" nature of the quickly changing course of the aircraft, and the PID functions then do a much better job of calculating the roll set point needed to "round the mark" smoothly.
// --------------------------------------------------------------------------------------------------// adjust the heading if we're banking hardint heading_roll_compensation(){int rollAmt = get_roll();if (abs(rollAmt) < 16) return 0; // don't adjust unless banking hardreturn (rollAmt/2);}// --------------------------------------------------------------------------------------------------// Calc our own Course Made Good - use as Gyro Referencevoid calc_our_CMG(){static float prevLat=0;static float prevLon=0;if (calc_dist(prevLat, prevLon, lat, lon) > 1){ourCMG = calc_bearing(prevLat, prevLon, lat, lon) + heading_roll_compensation();if (ourCMG > 360.0) ourCMG -= 360.0;if (ourCMG < 0) ourCMG += 360.0;prevLat = lat;prevLon = lon;gyroHeading = ourCMG;}}// --------------------------------------------------------------------------------------------------The code is then used within the function navigation():wp_bearing = calc_bearing(lat, lon, wp_current_lat, wp_current_lon);calc_our_CMG();roll_set_point = calc_roll(heading_error(wp_bearing, gyroHeading), dt_t);Note that calc_our_CMG() will NOT update gyroHeading every time thru, only when it gets new GPS data that puts us at least 1 meter away from our previous position (usually every second) In between, the gyro will have been updating gyroHeading 5 times per second so the nav routines can respond quick during the turn.The code below supports the Gyro. Init_Gyro_Bias() is called during init - NO MOTION.The main routine sample_gyro_data() is called each time thru the main loop.// ---------------------------------------------------------------------------------------------------------------------------// Called from Main Loop to sample gyro data & update gyroHeading.// Sample the analog data from the Gyro about 2,000 times per second.// call the Update Heading routine only every 20ms// smooth the over-sampled analog lines.void sample_gyro_data(){static unsigned long gyroTimer=0;static unsigned int gyroCounter = 0;unsigned long dt;analog4 = (analog4 + analogRead(4)) >> 1; // sample Analog inputs every time thruanalog5 = (analog5 + analogRead(5)) >> 1; // analog 4 & 5 are for the Gyrodt = millis() - gyroTimer;if (dt > 50) dt = 50;if (dt > 20) {update_gyro_heading(dt);gyroTimer = millis();gyroCounter++;if (gyroCounter > 10) {data_update_event |= 1; // update rudder info 5 times a secondgyroCounter = 0;}}}// -----------------------------------------------------------------------------------------------------------------------------// rate of gyro at full swing = 150 degrees per second// this should be called every 20ms -> 50 times per second// dt is in milli-secondsvoid update_gyro_heading(int dt){int gData;float gyroDelta;gData = (analog4 - analog5) - gyroBias; // range is now -512 ... 0 ... 512gyroDelta = (float)(gData) / 512.0; // range is now -1.0 ... 0 ... 1.0gyroDelta = gyroDelta * 150.0 * (float)(dt / 1000.0);gyroHeading += gyroDelta;if (gyroHeading > 360.0) gyroHeading -= 360.0;if (gyroHeading < 0.0) gyroHeading += 360.0;}// ---------------------------------------------------------------------------------------------------------------------------// gyroBias = reading of gyro at rest. So we know the zero point.// called at Init time gyroBias = init_gyro_bias();int init_gyro_bias(){int n;int theBias;analog4 = analogRead(4); // sample Analog input for gyro rateanalog5 = analogRead(5); // 2.5v voltage reference = 512theBias = analog4 - analog5;for (n=0; n<50; n++){analog4 = (analog4 + analogRead(4)) >> 1; // range 0..1023analog5 = (analog5 + analogRead(5)) >> 1;theBias = (theBias + (analog4-analog5)) / 2; // signed value -512..0..511}return theBias;}// ---------------------------------------------------------------------------------------------------------------------------
Read more…Developer
Posted by Jason Short on October 3, 2009 at 11:30pm
I've been working on this the last two weeks and I finally today did a successful walking navigation using the software. It's an extension of the last version I posted which now includes navigation (EM406 only). It's still a work in progress and I'll have it in the air soon, but until then I thought I'd share.The whole reason behind making this was to create something custom fit for my FPV setup. I'm also interested in trying alternate styles of navigation algorithms which I can now do, and test them with my ground station. All the code is custom written except for the GPS parsing algorithm which was only changed slightly to use Longs instead of Floats. (I'm doing a lot more calculations per second than the current Ardupilot, so I wanted to stay away from Floats.)I'm also reading the throttle input instead of using a 'remove before fly' jumper which frees an Arduino pin for other uses such as Lights or my audio based telemetry.The nav algorithm is pretty simple but it will keep the plane on track during high winds and I use simulation to predict when I'll reach a waypoint and how much I'm turning based on the IR readings. I'll be adding an airspeed sensor soon which will greatly add to the accuracy of the sim and give it throttle control.Here is a copy of the progress and a Flash base station. There are a bunch more features and details in the code and more coming soon. Feedback is welcome, and a special thanks to everyone who wrote the Ardupilot code. I've learned an enormous amount from it.JasonSource Files
Hi all,I'm just wondering how can we perform a position hold (within 10-20 cm, just like microdrone MD4-200 did ) with a GPS and IMU because I know that the accuracy of normal GPS is aroung 2m and can not achieve up to few cm level if we dont have DGPS. So I'm thinking of a Kalman fusion between GPS and IMU to give a more accuracy in position ? I'm not so clear about that, it has made me confused for a long timeThat's why I post this entry to get your inputAny idea are appriciated and welcome.I forget to post a link to you guy for easy imagination of GPS position hold.http://microdrones.com/en_mc_videos.phpthen looking for a video name "flight-performance md4-200, part 3", this is what it called "GPS positon hold"
Read more…
Now onto trying to get the differential pressure sensor to do... something. I have the Ardupilot Shield alone with both 3.3v and 5v attached. Analog 3 on the Shield is connected to analog 0 on an Atmega328. Took some trial and error to get the code to read something meaningful (I'm new to this, obviously), and after that was on to road testing. I got the pitot tube from an R/C website, but don't remember which. Here's some redneck engineering at its finest:
/yes, that's masking tape (duct leaves residue) and a stickLiving in the desert, it was windy today. About 25mph with 33mph gusts. Fortunately it was traveling due east, and all the roads are N-S-E-W. So I did a few trials east and west (head and downwind) at the same velocity, then the same thing for north and south (crosswind). I played around with the data for a little bit, and found that the best results came from averaging each run, and then splitting the difference with its opposite. Came up with this graph of results:
Since there was a significant beta with respect to the airflow on the north/south runs, you can see that the pressure difference is less. Makes sense to me at least. So for the fit, I chose the headwind/downwind curve. Something I've noticed about real aircraft (analog and digital birds), you need about 40kts to get a decent airspeed. Same applies to this model. Here's my code:int analogPin = 0;int pressure;float velocity;void setup(){Serial.begin(9600);}void loop(){pressure = analogRead(analogPin);velocity = 2.15314 * (float)pressure - 509.48572;if (velocity < 40){velocity = 0;}Serial.print("Counts: ");Serial.print(pressure);Serial.print(", velocity est: ");Serial.print(velocity);Serial.println("mph");delay (1000);}Now the only thing remaining is to be able to read the GPS data, put it into an algorithm and then I'll be able to calculate the wind speed and direction while the aircraft is flying (one of my primary goals for this system). But considering what I've learned today, higher velocity will equate to more accurate wind speed measurements, so I'll have to account for this when building the airframe. Also, probably going to go out and repeat this test when there's no wind out.
Read more…
Posted by Pete Burnight on October 3, 2009 at 2:04pm
I've been tuning the GPS portion of my ArduPilot / Magpie airframe combination, and put together this flight data recorder to save the results of the flights without having to take a laptop out to the field.The data recorder consists of a Spark Fun Data Recorder, an XBee radio modem, and a battery. The Data Recorder takes a serial stream at 9600 baud, and records it to a SD data card as a text file.The Spark Fun card takes un-regulated power in (my 6v battery), regulates it, an provides the regulated 3.2v power required for the XBee. (very simple) Just 3 wires between the XBee and the Data Recorder, V+, Gnd, and DataOut (XBee->Recorder)
I used a 4 cell battery case from Radio Shack for power - it sits on the back of a bread board used to hold everything together. Very easy. Thanks Spark Fun for making such amazing little products.The aircraft has a XBee Pro 900 modem sending out 1 line of flight data every 300 ms. I capture it with my portable download link to an SD data card that I copy to my computer at home after the flight. The Spark Fun Data Recorder saves the data as a simple text file, that I post-process into a KML file for Google Earth.|-- AP Mode:1,GPS:0,Mir:189,CH1:-2,CH2:-1,IMU:321.74,CMG:306,GHD:301.77,CRS:319.61,***|-1 LAT:36956188,LON:-122063904,ASL:34.76,ALT:34,ALH:29,***|-2 WPN:2,BER:257,DST:54,CRS:317.06,SPD:23.57,CRT:0.30,WPa:125,***|-3 ASP:0,RLL:-20,PCH:-5,THH:30,rSv:7,pSv:10,rSp:-31,pSp:5,tSp:85,***|-4 GYRO:4,Rate:428,vRef:513,Bias:-89,***|-- AP Mode:1,GPS:0,Mir:189,CH1:1,CH2:0,IMU:318.86,CMG:305,GHD:300.63,CRS:310.88,***|-1 LAT:36956340,LON:-122064112,ASL:35.76,ALT:35,ALH:29,***|-2 WPN:2,BER:230,DST:45,CRS:305.32,SPD:24.04,CRT:0.00,WPa:125,***|-3 ASP:0,RLL:-44,PCH:-7,THH:30,rSv:10,pSv:11,rSp:-40,pSp:5,tSp:85,***|-4 GYRO:54,Rate:478,vRef:513,Bias:-89,***|-- AP Mode:1,GPS:0,Mir:192,CH1:0,CH2:-1,IMU:310.09,CMG:279,GHD:278.19,CRS:297.76,***|-1 LAT:36956444,LON:-122064368,ASL:36.46,ALT:36,ALH:29,***|-2 WPN:2,BER:196,DST:42,CRS:291.87,SPD:26.01,CRT:0.40,WPa:125,***|-3 ASP:0,RLL:-44,PCH:0,THH:30,rSv:11,pSv:2,rSp:-36,pSp:5,tSp:85,***|-4 GYRO:82,Rate:507,vRef:514,Bias:-89,***|-- AP Mode:1,GPS:0,Mir:192,CH1:0,CH2:0,IMU:297.90,CMG:257,GHD:259.03,CRS:284.54,***|-1 LAT:36956468,LON:-122064512,ASL:36.96,ALT:36,ALH:29,***|-2 WPN:2,BER:164,DST:45,CRS:280.27,SPD:24.76,CRT:0.20,WPa:125,***|-3 ASP:0,RLL:-45,PCH:-10,THH:30,rSv:8,pSv:13,rSp:-45,pSp:5,tSp:85,***|-4 GYRO:9,Rate:433,vRef:513,Bias:-89,***|-- AP Mode:1,GPS:0,Mir:192,CH1:0,CH2:0,IMU:285.74,CMG:239,GHD:238.06,CRS:275.35,***|-1 LAT:36956460,LON:-122064768,ASL:37.16,ALT:37,ALH:29,***|-2 WPN:2,BER:137,DST:46,CRS:264.31,SPD:18.75,CRT:0.70,WPa:125,***|-3 ASP:0,RLL:-37,PCH:-8,THH:30,rSv:10,pSv:12,rSp:-34,pSp:5,tSp:85,***|-4 GYRO:46,Rate:471,vRef:514,Bias:-89,***// ---------------I put what-ever I want in the print_data() function of ArduPilot, and it gets copied to the output stream.After the flight, I post-process the data file into a KML for Google Earth, so I can evaluate the results of the latest code changes.
If anyone's interested, here's the code I used, slightly modified and spliced from the internet. This is for the SCP1000-D01, with my temperature running about 35 degrees F hot which for now I'm attributing to the heating from the amperage:// define spi bus pins#define SLAVESELECT 10 //CSB#define SPICLOCK 13 //SCK#define DATAOUT 11 //MOSI#define DATAIN 12 //MISO#define UBLB(a,b) ( ( (a) << 8) | (b) )#define UBLB19(a,b) ( ( (a) << 16 ) | (b) )//Addresses#define REVID 0x00 //ASIC Revision Number#define OPSTATUS 0x04 //Operation Status#define STATUS 0x07 //ASIC Status#define START 0x0A //Constant Readings#define PRESSURE 0x1F //Pressure 3 MSB#define PRESSURE_LSB 0x20 //Pressure 16 LSB#define TEMP 0x21 //16 bit tempchar rev_in_byte;int temp_in;unsigned long pressure_lsb;unsigned long pressure_msb;unsigned long temp_pressure;unsigned long pressure;float altitude;void setup(){byte clr;pinMode(DATAOUT, OUTPUT);pinMode(DATAIN, INPUT);pinMode(SPICLOCK,OUTPUT);pinMode(SLAVESELECT,OUTPUT);digitalWrite(SLAVESELECT,HIGH); //disable deviceSPCR = B01010011; //MPIE=0, SPE=1 (on), DORD=0 (MSB first), MSTR=1 (master), CPOL=0 (clock idle when low), CPHA=0 (samples MOSI on rising edge), SPR1=0 & SPR0=0 (500kHz)clr=SPSR;clr=SPDR;delay(10);Serial.begin(9600);delay(500);Serial.println("Initialize High Speed Constant Reading Mode");write_register(0x03,0x09);}void loop(){rev_in_byte = read_register(REVID);pressure_msb = read_register(PRESSURE);pressure_msb &= B00000111;pressure_lsb = read_register16(PRESSURE_LSB);pressure_lsb &= 0x0000FFFF;pressure = UBLB19(pressure_msb, pressure_lsb);pressure /= 4;altitude = (1 - pow((float)pressure/101325,0.19025515825))*(288.15/0.00199074074);Serial.print("Altitude ft [");Serial.print(altitude);Serial.println("]");temp_in = read_register16(TEMP);temp_in = temp_in / 20;temp_in = 1.8 * temp_in - 3;Serial.print("TEMP F [");Serial.print(temp_in , DEC);Serial.println("]");delay(1500);}char spi_transfer(volatile char data){SPDR = data; // Start the transmissionwhile (!(SPSR & (1<<SPIF))) // Wait for the end of the transmission{};return SPDR; // return the received byte}char read_register(char register_name){char in_byte;register_name <<= 2;register_name &= B11111100; //Read commanddigitalWrite(SLAVESELECT,LOW); //Select SPI Devicespi_transfer(register_name); //Write byte to devicein_byte = spi_transfer(0x00); //Send nothing, but we should get back the register valuedigitalWrite(SLAVESELECT,HIGH);delay(10);return(in_byte);}float read_register16(char register_name){byte in_byte1;byte in_byte2;float in_word;register_name <<= 2;register_name &= B11111100; //Read commanddigitalWrite(SLAVESELECT,LOW); //Select SPI Devicespi_transfer(register_name); //Write byte to devicein_byte1 = spi_transfer(0x00);in_byte2 = spi_transfer(0x00);digitalWrite(SLAVESELECT,HIGH);in_word = UBLB(in_byte1,in_byte2);return(in_word);}void write_register(char register_name, char register_value){register_name <<= 2;register_name |= B00000010; //Write commanddigitalWrite(SLAVESELECT,LOW); //Select SPI devicespi_transfer(register_name); //Send register locationspi_transfer(register_value); //Send value to record into registerdigitalWrite(SLAVESELECT,HIGH);}/-------------------------------------------------------------------------------------------------------------------------------This is the code I used to get a decent compass heading. There's a lot of extra fluff in this code, and its not modified at all:#include#includeint magReading = 0;int XmagValue = 0;int YmagValue = 0;int Azimuth = 0;void setup(){Serial.begin(9600);Wire.begin();}void magRead(int outputMode){// int HMC6352Address = 0x42;// Shift the device's documented slave address (0x42) 1 bit right// This compensates for how the TWI library only wants the// 7 most significant bits (with the high bit padded with 0)// slaveAddress = HMC6352Address >> 1; // This results in 0x21 as the address to pass to TWIint slaveAddress = 0x21; // This is calculated from HMC6352's address, see comments aboveint ramDelay = 100; // us, delay between a RAM write command and its effect, at least 70usint getDelay = 10; // ms, delay between a get data command and its effect, at least 6msbyte magData[2];int i;switch (outputMode){case 0:Wire.beginTransmission(slaveAddress);Wire.send(0x47); // Write to RAM commandWire.send(0x4E); // Output Mode control byte addressWire.send(0x00); // 0x00 for Heading modeWire.endTransmission();break;case 1:Wire.beginTransmission(slaveAddress);Wire.send(0x47); // Write to RAM commandWire.send(0x4E); // Output Mode control byte addressWire.send(0x03); // 0x03 for Magnetometer X modeWire.endTransmission();break;case 2:Wire.beginTransmission(slaveAddress);Wire.send(0x47); // Write to RAM commandWire.send(0x4E); // Output Mode control byte addressWire.send(0x04); // 0x04 for Magnetometer Y modeWire.endTransmission();break;default:Wire.beginTransmission(slaveAddress);Wire.send(0x47); // Write to RAM commandWire.send(0x4E); // Output Mode control byte addressWire.send(0x00); // default to Heading modeWire.endTransmission();}delayMicroseconds(ramDelay); // RAM write needs 70 microseconds to respondWire.beginTransmission(slaveAddress);Wire.send("A"); // The "Get Data" commandWire.endTransmission();delay(getDelay); // Get Data needs 6 milliseconds to respondWire.requestFrom(slaveAddress, 2); // Request the 2 byte data (MSB comes first)i = 0;while(Wire.available() && i < 2){magData[i] = Wire.receive();i++;}magReading = magData[0]*256 + magData[1];}void loop(){magRead(0);Azimuth = magReading;magRead(1);XmagValue = magReading;magRead(2);YmagValue = magReading;Serial.print("Mag X: ");Serial.print(XmagValue);Serial.print(" Mag Y: ");Serial.print(YmagValue);Serial.print(" Azimuth: ");Serial.print(-int(atan2(YmagValue,XmagValue)*57));Serial.print(" degrees ");Serial.print(int(Azimuth/10));Serial.println(" degrees ");delay(500);}
Read more…3D Robotics
About half the ArduPilot development teams are now up and running (the rest of you team leaders--send out those invites!), and we've got a little more experience in using Huddle. Some tips:
--Formatting in discussions right now is hosed. Paragraph returns don't work and only plain text is supported and they're not threaded. So until they enhance the fucntionality of discussion, keep your posts short for readability. Or move some discussion out to the main DIY Drones discussion boards if you need richer tools.
--If you're going to collaborate on files, try to keep them to Word or Excel formats. Powerpoint is not supported with an online editor, and not everyone has Powerpoint running on their machine. Obviously this does not apply to code or Eagle files, which can remain in their native format for downloading.
--At the moment (noon PST on 10/2) Zoho currently isn't saving changes to files edited online. It worked earlier today and presumably will come back soon. But in the meantime, work with those files offline. [Saving documents you've edited online is not working reliably for me. I recommend you edit all documents offline and upload them. The process is to "lock and download" then "upload a new version" when you're finished.]
--Try to start a new discussion thread for each new topic, so they're easier to follow. Without threading or quoted replies, it's hard to follow discussions that are long and evolving.
--To download or edit files, look for the little dropdown menu next to the file name.
Read more…Moderator
Posted by Gary Mortimer on October 2, 2009 at 9:13am
Still a couple of weeks to run on this round which other than for a few brave souls seems to have proved impossible!Next time lets try and break that Stanford record in 300' steps. If you don't have a clue what I'm on about, watch the video above and listen to the guys from Stanford on the Podcast for some advice.G
Read more…Moderator
Posted by Gary Mortimer on October 1, 2009 at 12:30pm
From my fav tech website (and lots of other places, but you should know about The Register ;-) )Manned 'Surrogate Predators' fill in for robot assassinsTrack this topic Print story Post commentHumans go into simulations, but not into real worldBy Lewis Page • Get more from this authorPosted in Science, 1st October 2009 16:12 GMTMaking IT work In the real world. Is Open Source alone the answer?Robot aircraft are in such demand for combat in Iraq and Afghanistan that the US military - in mildly disorienting move - is using manned aeroplanes to stand in for them during military training exercises.It seems that high demand for the services of Predator and Reaper surveillance/assassination droids overseas has meant that none can be found to take part in the US Air Force's annual "Green Flag" air bombing exercises.Read more....http://www.theregister.co.uk/2009/10/01/surrogate_predators/Read more…Developer
Posted by Jordi Muñoz on October 1, 2009 at 11:00am
I just want to tell anybody whats going on:1.-Sales grew exponentially this month. The old store with a few sales a day and commodity to produce just a few units a week to keep it running NO longer exist. That means good changes here, more people over there and maybe extra external help.2.- I'm introducing the new ArduPilot Shield, has the labels corrected and a real mux to support all the GPS on the market, letting you upload code without disconnect it. I will offer four versions:-The economic version (Without 3.3V power regulator): Available with and without pressure sensor. This is the best option for uBlox + Adapters and EM406 owners that already have the old shield. The pressure sensor is expensive so you can rip it off from the old one to save some rupees.-Standard version (with 3.3V power regulator): Will be available with and without pressure sensor.-All available as a Kit.3.-The new ArduPilot Shields, uBloxs and uBlox adapters are stuck in China! Some kind of Dragon Christmas (National Day) will delay one week everything at least for the PCB's. Great! Sorry for the inconveniences!4.-For those who bought the Remzibi OSD, please patient, 30 units are on its way to the US and i will relay them to everybody after they have arrived, the USPS tracking is CP 11 628 509 5 PL. ;-)5-Today i will ship all the backordered ArduIMU's. Sorry for the delay!6-Please welcome 23 years old JB Aletky, he is part of DIYdrones store crew now, helping us packing, assembling and testing ArduPilots, he has a few R/C flight skills (LOL):
Read more…3D Robotics
Posted by Chris Anderson on September 30, 2009 at 10:00pm
[UPDATE: the team leaders should all now be inviting team members as friends and once the invitations are accepted, they'll be invited to the workspaces. If you're on the team, you'll get an alert telling you that you've been added. It will say nonsense about needing to click on unclickable words, but ignore those bugs. Just go to your workspace by clicking on the Workspaces tab and you should see it.
I'll be swinging by in each Workspace as I'm added to upload necessary files and give further directions over the next day or two.
-chris]
Many thanks to all of you have stepped forward in our call for ArduPilot project help! I'm going to set up the projects in the workspaces and give the initial project definitions in the next day or two, but in the meantime I've made some provisional assigments based on expressed preferences. Names with an asterisk in front would be the provisional project lead/managers.
If you've volunteered, please review the list and see if you're happy with your assignment. If not, please express your preferred change in the comments. If you're shown as lead and don't want to lead, please comment. Or, if you'd like to lead a project and aren't shown as the lead, comment that too.
Finally, if you'd like to add your name to one of these projects, do so in the comments as well.
1) Design a "thermopile replacement" version of ArduIMU: this is a version of the current ArduIMU board with a two-channel DAC and a FMA connector, so it can output voltage to emulate the FMA thermopiles.
*Michael Zaffuto
Mark Colwell
Joe
David S
David Sprague
2) Design the turn-rate limiter shield hardware and software modification to the ArduPilot code: this is shield that has a one-axis gyro, a differential pressure sensor and a connector for the uBlox GPS. It will duplicate the functions of the UNAV PicoPilot but be better and a lot cheaper.
*Jeff Taylor
Curt Filipowski
Michael Zaffuto
Grubi
David Sprague
Dave_fr
3) Create and maintain a library of airframe.h configuration files
*Peter Meister
Octane-link
4) Design the hardware for the ArduPilot Mega ground station (with dynamic PID adjustments).
*Sarel Wagner
Andy Geppert
John C
Peter Koppendorger (enclosure)
Mogly
Kyle Corbitt
5) ArduIMU documentation
*Andy Geppert
John C
Michael
Octane-link
David Sprague
6) Create an autopilot PID tuning guide
*Octane-link
Mogly
7) Create a Lego Mindstorms compatible version of our MUX/Failsafe. This is just our current board with the addition of a Mindstorms connector and any necessary components for an I2C link.
*Christopher Barnes
Michael Zaffuto
8) Create a "Using ArduPilot with the Remzibi OSD" guide
*HappyKillmore
John C
Peter Meister
9) Create a ArduStation assembly and usage manual
*Chris Anderson
John C
Octane-link
James McGlinn
10) Create a system that can inject telemetry data on the invisible closed caption lines of a video stream and be able to decode it in the other side for the OSD system.
*Remzibi
David Sprague
11) Contest management
*Gary Mortimer
Chris Anderson
12) Podcast management
*Tim Trueman
Chris Anderson
13) Create Lego Mindstorms turn-rate limiter autopilot code (similar to #2 and using #7)
*Chris Anderson
Read more…Developer
Posted by Jordi Muñoz on September 30, 2009 at 4:59pm
Hi there, well I'm happy to announce the new ArduPilot 2.4 firmware, i still have many things to add, but i will leave them for 2.5 .What's new:-Improved ADC conversion, now uses interrupts to free some CPU.-uBlox parser bug fix, now i can navigate better.-Added a new header option called "ALT_HOLD_HOME". Let you select what altitude you want to hold for home, 0 will hold the altitude you are when you switch to RTL, 1 = will hold the altitude defined on the confiq. tool.-Altitude hold dramatically improved for my Easystar. (Thanks to Bill!).-Airspeed and throttle control improved.To do:-Add Happy Kill More code for Remzibi Integration.-Change the TX protocol to binary.-Use interrupts for the serial output.-Header typos correction.-Maybe cross-track error or another solution to fly straight lines between waypoints.Source Code: ArduPilot_EasyStar_V24.zipMy header: easystar.hRead more…
A couple of people at the University I attend and I had our first flight the other day, and we wanted to tell all of you about it.I will start with the goals of our "team". Our goal is to create a network of UAVs that allow for mulitple users and/or multiple ground stations attempting to control multiple vehicles. We felt that the ArduPilot platform was perfect because we have access to source code, it is inexpensive and a vibrant community which could, hopefully, provide feedback.We were able to encorporate two way telemetry by simply adding a software serial line to pins 8 and 11. Because it is a software line we are operating at only 38.4k baud rateAs of right now the ground station only supports three aircraft (because of communication restraints) and can successfully upload wps, tune trims and PIDs, command heading angle, switch to reading wps off EEPROM (when uploading new wps we store in RAM) and a few other, not as exciting things. We changed the telemetry system to a request based system rather than always talking, this was done because the XBees on each AC operate on the same channel.Here is an older photo of the groundstation, no major changes have been made since this screen shot was taken
So our first day out was successful, we flew two aircraft with ground station and two way telemetry. We had an issue with the map being slightly skewed, so we are gonna try again soon. Luckily all commands work through Hyper Terminal or the Arduino Serial Comm screen, which is a bonus.In the future we would like to try flying more aircraft and using the dynamic WP changing features to get a crude version of formation flight, as well as some other high level control schemes.Amain.pdeCommunication.pdeControl.pdeForDIY.pdeGPS_EM406.pdeGPS_UBLOX.pdeNavigation.pdeSensors.pdeServos.pdeSystem.pdeWayPoints.pdexDebug.pdeRead more…
Can anybody shed some light on the accuracy of the airflow around the fuselage on the attached image? The wing is based on the GM15 foil. Rest of the details is in the picture. The modeling was done with XFLR5.Does the results of lift, drag etc look credible?
Posted by Chris Anderson on September 29, 2009 at 11:00pm
Please note that I've added Huddle Workspaces to the site, which I hope will prove useful for the volunteer teams working on various ArduPilot projects. I'll be PMing those who responded to our call for volunteers and giving directions and assignments in the next day or two, but in the meantime, what do you think of Huddle? Is it appropriate for our purposes? (It seemed the best of the available Ning apps, but I don't know much about workspace software and haven't used Huddle before). Let me know if it looks good or not, and I can then get us going.
Read more…3D Robotics
Posted by Chris Anderson on September 29, 2009 at 10:36pm
From the good BotJunkie blog: "The operation of the Point and Toss is literally that simple: you point it in the direction you want it to go, click a hand controller to lock the heading and start the engine, and then toss. The UAV automatically stabilizes itself, flies out for about half a mile at 250 feet taking pictures and video to an SD card, and then autonomously turns around and lands at your feet."
It's intended for military use, which means that when the manufacturer, IATech, describes it as "cheap", it probably means thousands of dollars. But I can think of lots of civilian uses, too. All of our UAVs can do this already, and I don't even think a RTL UAV like this would be export controlled, so we could easily produce one--simple, single-purpose and ready to fly out of the box. What say we make an open source one for $250? (And then some toy company can make it for $99!)
Read more…3D Robotics
Posted by Chris Anderson on September 29, 2009 at 2:08pm
[UPDATE: This one proved a bit harder than we thought, so we're going to extend the deadline by two weeks, to 12:00 midnight PST on Sunday, October 18th.
Also, here's a preview of next month's contest: Break the Stanford team's UAV altitude record of 7,142 feet by doing at least 24 circles with a 300ft climb and descent in each! (This won't really beat his official record, because there won't be an official judge there. But you'll get bragging rights, at least). I'll announce full details on Oct 19th]
The first Trust Time Trial (T3) contest was a great success. Lots of entries, nail-biting competition, awesome performances and lots of learning for all.
Now comes round two. The difference this time are as follows:
--Three laps
--3D waypoints. (must hit altitude targets as well as lat/long)
The prize this time is a Global Hawk kit.
Winning entries must be posted in the comments below by midnight PST on Sunday, October 4th 18th.
Rules:
1) Must complete the pattern as shown above, totally autonomously. Go into autonomous mode before waypoint 1 and stay in for three laps. The four points are arranged in a square, with 200m on a side (obviously the two diagonal paths are longer). Any aircraft/autopilot allowed. It doesn't matter how close to the waypoints you get, as long as you pass on the outside of them.
2) Altitude must be within +-10m of given altitude at each waypoint. It doesn't matter what your altitude is in between waypoints. All altitudes are either above launch position or the contestant's specified "safety altitude".
3) Fastest time to complete three laps and hit the 3D waypoints wins. Must provide GPS track with timestamps and on-board video. (If you don't have/can't afford a small onboard videocamera like the FlyCamOne 2, we'll let it go this time. But in the future: video or it didn't happen!)
GPS tracks are best achieved with an onboard GPS datalogger, like the i-Blue 747 or smaller Sanav ML-7. But if you don't have one or don't want to add the weight, you can just capture the GPS track from your telemetry stream, although you'll have to figure out how to convert it to KML format to export to Google Earth (see below). If your Ground Control System has a built-in map+track function, a screen shot of that is fine, but it should be possible for people to check to confirm that your leg lengths are at least 200m.
Evidence data should include these four things:
1) Total time, along with aircraft and autopilot used. A photo of the aircraft would be nice.
2) Screen capture of path exported to Google Earth or an equivalent, annotated with waypoints and where autonomy began and ended. :
3) GPS datalog file, any format
4) Onboard video, embedded from YouTube or Vimeo. [Not absolutely required but requested]
Read more…
Posted by Brian Delaney on September 29, 2009 at 12:41pm
I am currently a Soldier in the U.S. Army at AIT to be an Unmanned Aircraft Systems Operator/Payload Operator. I am National Guard, so once i am done here in JAN i will be able to search for a civilian job. I will be certified to fly and control payload on the Shadow 200/300 systems and 100% capable of emplacing/displacing all required equipment.I am curious if there are opportunities to fly the Shadow with a civilian company overseas. I want to find a job with some sort of DoD contractor company working in Iraq/Afghanistan and go on deployment with them right away. I will be able to go "Inactive Guard" on the military side.But i REALLY want to find a job right away with a civilian contractor working in Iraq/Afghanistan flying the shadow.My qualifications will be-Shadow 200/300 Aircraft Operator/Mission Payload Operator-DoD Security Clearence-Associate Degree in Unmanned Aircraft Operations.Any help is appreciated. my email address is PilotBJD08@Aol.com
Read more…
