While transcribing parts of ArduPilot code in Python for testing and NMEA sentence parsing/emulation, I noticed that the checksum calculations/comparisons are made twice, once for the RMC and later for the GGA sentences.Could it be worth a few bytes or simply better to do it another way to limit the number of checksum to process (for now, all received sentences are cross-checksummed)Could we1) test the sentence header (RMC or GGA)2) if header found, do the checksum calc3) if chksum ok parsing the sentenceThis solution would leave all unnecessary sentences eventually sent by the GPS out of the processing loops a little earlier than now. this would probably save some processing time for those who do not program their GPS to limit the NMEA flow to the minimum sentence needed in ArduPilot.Another question concerning the code:is there an explanation as to why the latitude/longitude conversions to decimal degrees need temp variables. In Python, I do each conversion in one line:lat = float(`latIn`[:2]) + float(`latIn`[2:])/60lon = float(`lonIn`[:`lonIn`.index('.')-1]) + float(`lonIn`[`lonIn`.index('.')-1:])/60Would such single line be doable in Arduino?Finally, I would like know if there is any way to read a full line out of the GPS instead of parsing through each character. In Python, I use a serial.readline() and then read complete blocks between the comma delimiters:datablock = buffer.split(',')latIn = string.atof(datablock[3])lonIn = string.atof(datablock[5])course = string.atof(datablock[8])Is there aFinally, I wish to say I am not a programmer, but only an archaeologist, so I could be wrong ! Thanks for any inputs on this, I'll probably add more questions about the code in the coming days, I am a newbie.
Read more…
Posted by Kyle Sanders on February 3, 2009 at 6:30am
My girl always said that "good things come in small, teal boxes", and now I think I understand... I am all about small, red boxes!
Kudos to Sparkfun and the DIYDrones developers who got the hardware / software / simulators figured out - this really opens the door for the rest of us to tinker away!
Read more…Developer
Posted by Jordi Muñoz on February 1, 2009 at 9:30pm
For months i have been slowly investigating and "developing" an accurate, efficient nav code (for slow power 8-bit uControllers), finally i just finish my new navigation algorithm, is super faster and smaller.... =).Before the functions were like this:int get_gps_course(float flat1, float flon1, float flat2, float flon2){float calc;float calc2;float bear_calc;float diflon;//I've to spplit all the calculation in several steps. If i try it to do it in a single line the arduino will explode.flat1=radians(flat1);flat2=radians(flat2);diflon=radians((flon2)-(flon1));calc=sin(diflon)*cos(flat2);calc2=cos(flat1)*sin(flat2)-sin(flat1)*cos(flat2)*cos(diflon);calc=atan2(calc,calc2);bear_calc= degrees(calc);if(bear_calc<=1){bear_calc=360+bear_calc;}return bear_calc;/********************************************************************************/}unsigned int get_gps_dist(float flat1, float flon1, float flat2, float flon2){float dist_calc=0;float dist_calc2=0;float diflat=0;float diflon=0;//I've to spplit all the calculation in several steps. If i try to do it in a single line the arduino will explode.diflat=radians(flat2-flat1);flat1=radians(flat1);flat2=radians(flat2);diflon=radians((flon2)-(flon1));dist_calc = (sin(diflat/2.0)*sin(diflat/2.0));dist_calc2= cos(flat1);dist_calc2*=cos(flat2);dist_calc2*=sin(diflon/2.0);dist_calc2*=sin(diflon/2.0);dist_calc +=dist_calc2;dist_calc=(2*atan2(sqrt(dist_calc),sqrt(1.0-dist_calc)));dist_calc*=6371000.0; //Converting to meters, i love the metric system.. =)return dist_calc;}Now are like this:int get_gps_course(float flat1, float flon1, float flat2, float flon2){float calc;float bear_calc;float x = 69.1 * (flat2 - flat1);float y = 69.1 * (flon2 - flon1) * cos(flat1/57.3);calc=atan2(y,x);bear_calc= degrees(calc);if(bear_calc<=1){bear_calc=360+bear_calc; }return bear_calc;}/********************************************************************************/unsigned int get_gps_dist(float flat1, float flon1, float flat2, float flon2){float x = 69.1 * (flat2 - flat1);float y = 69.1 * (flon2 - flon1) * cos(flat1/57.3);return (float)sqrt((float)(x*x) + (float)(y*y))*1609.344;}And if you wonder the difference i have compared them side by side and recorded it.The results are here:The precision is exactly the same, only if you go more than 8 km away, the distance starts to get dirty... But good enough for our purposes... =)
Read more…
A photo of successful flight as seen in Google Earth and X-plane:
Here is another ArduPilot simulation inspired by Jordi's simulation.My simulation requires minimum additional hardware, all you need is ArduPilot connected by FTDI cable to PC.Actual simulation runs in X-plane simulator. ArduPilot get simulated GPS data over serial, and it returns back proposed servo positions back over serial as part of telemetry info (servos can also move physically). ArduPilot also reports bunch of variables - lat/lot/alt, next waypoint, distance to it, etc.What you need to repeat the simulation:- Modified ArduPilot code from this blog post- X-plane 9 demo (buy full version if you wish, but demo works just perfect, it only ignores joystick input after 10 minutes, but we control it other way so it really doesn't limit us)- Google Earth- ArduSimulator ArduSim_20090211.zip (developed by me), which is simple application that does following:1) Connects to ArduPilot over serial for sending/receiving data2) Connects to X-plane on localhost (same PC)3) Reads data from X-plane (lat/lon/alt/course), sending these to ArduPilot as GPS sentences4) Simulating FMA copilot stabilization on ailerons/elevator5) Reads and displays telemetry and servo positions from ArduPilot6) Sends servo positions to X-plane to control throttle and rudder7) Records fly path and sends it to Google Earth to displayHere's how to repeat the simulation:- Start X-plane, go to Menu->Settings->Net Connections, select tab Inet 3 and enable "IP of data receiver", change IP address to 127.0.0.1 and port to 49001. It looks like this:
- Select Aircraft from folder Aircraft\Radio Control\GP_PT_60 (yes, we want to fly RC plane which has ail/elv/rud/thr controll)- Select airport Innsbruck- You can open this KML path: Innsbruck.kmz in Google Earth, which was my testing fly plan configured in ArduPilot; this will show you the waypoints- upload compiled ArduPilot code to the board and leave it running; LOCK LED should keep flashing- start ArduSim.exe (simulator tool); it will connect to serial port and X-plane; if it can't connect to serial, specify correct port and baudrate and press Start button- click [Google Earth] button in ArduSim to make connection with GE- hit B in X-plane to release brakes, and try keys A/W/C to choose various viewsNow simulation should be running if everything is connected successfully, and you should see plane in X-plane to fly and visualization path & icon in Google Earth to move. Don't control plane in X-plane! ArduPilot will take-off and fly on its own.Here's video how it all looks in action:And complete flight path visualization for Google Earth: Flight.kmzYou can see original waypoints in white, and real fly path in yellow. And also final circulation over start point when all waypoints were visited...Now about problems and future tasks:- I have strong impression that controlling altitude by throttle with use of copilot stabilization doesn't work properly, this simulation showed me that plane didn't want to drop altitude from high point to lower one... see results in above flight path in GE. I'm not sure how real plane behaves (didn't went out to real world with this yet), we'll see.- For this reason I plan to start playing with complete stabilization in ArduPilot, and controlling both elevator+throttle to get desired altitude.- You can play with dozen of various parameters to control behavior, most obvious are PID settings for throttle/rudder in ArduPilot, but also PID values in stabilization (which is here provided by simulator tool, in real world it is FMA Copilot which you can control by its sensitivity setting). Then you can change maximal servo rotation for ArduPilot to work with. All these values make the plane fly smoother, make more precise turns, etc etc. And the settings seem to depend on actual aircraft and its physical behavior. So there won't be single settings working for everyone.- It's somehow cumbersome to specify different altitude for various waypoints; while I converted waypoints from KML file out of Google Earth, I had to specify individual altitudes manually in waypoints.h file in ArduPilot code.After all, I'm pretty happy to see the plane flying in simulator and doing the task! Note that it's ArduPilot doing the navigation work. And in a real airplane, this simulation allows to reuse the ArduSim application as a base station, getting telemetry from plane over Xbee modem and displaying what it does as well as showing path in Google Earth.
Read more…Moderator
Hi all,I was wandering around and guess what I found, an M.Sc. Thesis by Philip S. Anderson about the development of a UAV ground control station.I haven't read it yet but it seens to be a really nice reference. He uses LabVIEW which by what I have seen is a very popular software among us(uhhh but I still a newbie).What I think is a nice point of his project is that he actually built the system and put it on a van, so we can have a taste of what the military guys have :DJust for the sake of knowledge, I'm attachig his work(am I infringing any law, copyright or anything like this?).Ground Control Station.pdfRead more…3D Robotics
We've been describing ArduPilot as a navigation-only autopilot and saying that it needs the FMA Co-Pilot to provide stabilization. But that's actually not true--we just hadn't written the stabilization code yet. ArduPilot is powerful enough to handle both functions, something that Jordi proved this week with his ArduPilot-powered FunJet.
The above picture shows all the elements (click for a larger version): A FMA X-Y sensor is connected to two of ArduPilot's analog inputs. The four wires in the FMA sensor cable are, in order, roll, pitch, 5v, gnd. Connect roll to ArduPilot's analog 0 port and pitch to analog 1.
This is an example of how flexible the basic ArduPilot hardware is. It's the exact same board, but with different code and sensors added on the analog ports. We're going to add an airspeed sensor, too, and other goodies over time. You can do a lot with this little board!
Here is the alpha code, which is just so you can see the basics of how he did it. It's got the GPS stuff stripped out, but Jordi also has a working version with a 5Hz UBlox GPS.
For the public beta, we'll use a 3-channel EasyStar, rather than the FunJet, and the standard 1Hz EM406 GPS. The FunJet is, well, fun, but hard to fly (Jordi crashed it three times this week alone!) and not for everyone, and we want to stick with the simplest, easiest to use equipment for our main releases. Stay tuned.
Read more…3D Robotics
Big win for Dean! Purdue has been getting great press for its AttoPilot-powered UAV. Excerpt from Network World: (Slashdot coverage here:
"Researchers at Purdue will soon experiment with an unmanned aircraft that pretty much flies itself with little human intervention.
The aircraft will use a combination of global-positioning system technology and a guidance system called AttoPilot that uses GPS signals and an on-board flight-stabilization system to guide the aerial vehicle to predetermined points. Researchers can be stationed off-site to monitor the aircraft and control its movements remotely. AttoPilot was installed in the aircraft early this year, and testing will begin in the spring, researchers said.
According to Purdue, researchers have been using a small, lightweight unmanned aircraft - essentially a model airplane equipped with electronics - to collect agricultural data for Calmar Labs in Remington, Ind. The vehicle is equipped with infrared and digital cameras to take photos to assess the effects of shadowing on corn growth or to monitor the effects of drought or floods on crops. Until now, the aircraft has been controlled by a conventional radio receiver, which required human intervention to begin and end the missions, Purdue stated."
Read more…
Default baudrate of EM406a GPS device is 4800 baud. Then this baud rate dictates entire communication of serial port on ArduPilot - also those for Serial OUT (telemetry).Here's simple way how to permanently increase baud rate of EM 406. Once done, the device will remember the baudrate, and you can increase serial speed in ArduPilot code.1) Temporarily connect your GPS directly to FTDI cable:
Pin connection:FDTI GPSblack <-> 5 (from right)red <-> 1orange <-> 3yellow <-> 4Note: I used original half-cut cable + connector left by this cable modification. No soldering, just careful wire plugging into FTDI connector.2) Connect FTDI cable, and check if GPS works in RealTerm using default baudrate 4800:
3) Switch to Send tab in RealTerm:
and1) type command $PSRF100,1,19200,8,1,0*38 in marked field2) check +CR +LF line-ending3) click "Send ASCIIThis will configure your GPS device for 19200 baud rate.I didn't test with higher baud rates, but if you change it, you'll need to recalculate command checksum (*38 at end), otherwise GPS won't accept the command.4) Now GPS start to send at 19200 baud, so you'll see some garbage in RealTerm. Go to Port tab, close link (untick Open button), change baudrate to 19200, and Open link again. If you see valid GPS data, then all is OK:
5) In ArduPilot code, search for line Serial.begin(4800);and change it to Serial.begin(19200);Done! You have now faster serial communication in your ArduPilot code. GPS device will remember the baud speed as it has internal battery and memory and keeps the setting.You're now prepared for more data to be sent by telemetry link.
Read more…3D Robotics
Posted by Ross Mansell on January 28, 2009 at 1:13am
Posts are much easier to read if the poster uses capital letters where required AND correct punctuation!! Text type posts are not much use either, as a number of people do not bother to use a telephone for texts
Read more…T3
The UAV development board is back in stock at SparkFun.SparkFun also plans to eventually carry 12" cables for the GPS connection, which could be used for the UAV development board, as well as for Chris Anderson's ArduPilot. Sparkfun also plans to eventually carry 12" servo cables for connecting from the board to the RC receiver.Presently, there is C code available for getting you started with the UAV development board. There are two separate programs. One is for simply making sure that the board is working, used at SparkFun to test the boards before they ship. This one is available both at SparkFun and on this website, and is the program that is in the board when it is shipped. There is also a program that I call "GentleNav", available on this website only. It is a port of the program that I have been using for a couple of years on my previous hardware platform. It performs pitch stabilization and/or RTL for an electric sailplane.By the way, there is a "feature" of most GPS radios that you should be aware of if you plan to use both programs. If you command GPS radios to switch baud rate or between NMEA and binary formats, they only listen at the new baud rate and in the new format. If you run the "GentleNAV" program, it will switch to binary format with an NMEA command. If you then run the self test program, which trys to communicate in NMEA format, the GPS radio will ignore all commands, and the self test will indicate a failed GPS. If you plan to switch back and forth, you should revise the self test program to have it send the GPS command in binary format to switch to NMEA. With older GPS radios that I have used, they eventually default back to NMEA. The EM-406 somehow seems to forever remember the commands to switch, it will never switch back. I eventually plan to revise the self test program. In the meanwhile, it might be a good starting point for you to revise the self test program to send a binary command to the GPS to switch to NMEA format, its not hard to do.You should also be aware that the status light on the EM-406 only works when the radio is in NMEA mode. At least I haven't figured out how to make it light in the binary mode, it just goes out. It resumes operation when you switch back to NMEA.Presently, I am working on two projects related to the UAV development board. First, I am finishing up the documentation for the "GentleNav" firmware. Its taking longer than I thought. I will post a blog when it is done.Second, I am working with Paul Bizard to develop theory and implementation for "artificial horizon" firmware for the UAV development board. It will combine gyro, accelerometer, and GPS information into a stable, responsive, accurate representation in matrix format of the orientation of the plane that it is mounted in. We believe we have a method that will work, but we have a few more details to work out. We will publish the theory when we have something we are satisfied with, and tested code some time later. What we have in mind is an algorithm that will maintain the 3X3 direction cosine matrix that describes the relative orientation of the plane and ground. Each entry in the matrix is the cosine of the angle between an axis on the plane and an axis on the ground.Best regards to everyone, and acknowledgements to Chris Anderson, Paul Bizard, and all the staff at SparkFun for their help.Bill Premerlani
Read more…3D Robotics
Posted by Jordi Muñoz on January 27, 2009 at 1:00pm
This is a quick video tutorial to explain how to re-flash the attiny45 in ardupilot boards. You can also tweak the attiny code if you wish...But first you need to fallow this steps:1.-Buy an AVRISP MKII programmer, you can buy one in DIGIKEY, MOUSER and FARNELL (for Europeans)2.-Download and install AVR Studio from here, if the link don't work try this one (you must register). When your are installing it, when it ask about "Jungo Drivers", say always "Yes, yes and yes!" (are AVRISP drivers).3.-Now AVR studio will only let you program ATMEGAS in assembler (yeah, sure). For C/C++ you must install the WINAVR (AVR GCC). It will automatically fuse with AVR Studio, so don't worry about anything else... The main page is here, and the direct download here. After download, install it please.4.-Now plug you AVRISP programmer and make sure the drivers are well installed, if you want to know more about AVR studio and AVRISP please read here (very suggested).5.-Download the Fail Safe firmware (or code), to download the one i'm using in the video click here. Lasted updates will be published here. You can also download the HEX directly here, if you want... ;-)6.-Watch my quick-made video:
Read more…
nothing new since last post, but here's a video:it might look stressful but keeping it this way was really easy, easier than my rc helicopter.
Read more…
The Sparkfun guys and we diagnosed the issue today. It was our fault--we had a version control problem with the Attiny code we sent them, and the bad news is that appears to have affected a total of 60-80 boards. For those of you affected, our apologies--we'll make this right. Here are your options:
1) The fastest way, if you have an AVR programmer, is just to reflash the chip with the updated code (hex file is here; full source code is here). Instructions are here. If you don't have an AVR programmer, but have always wanted one, this is your chance! The AVRISP2 is excellent, comes with the terrific AVR Studio software, and is cheap ($34)
2) If you don't have an AVR programmer, the solution is to return the boards to Sparkfun and they will reflash or replace them at no charge, testing to ensure that you have a working board. Just send an email to techsupport@sparkfun.com, who have been alerted and will help you with the process.
All board shipped from today on will have the correct firmware, so this should be the end of the problem. Again, our apologies for the inconvenience and confusion. Our aim is to ensure that everyone has a working board as soon as possible, and Sparkfun has been great about responding quickly and making sure this doesn't happen again. Thanks for your support and understanding.
[Update. If you have this problem and live in the LA area, Jordi has volunteered to come to your house and reflash the board himself, no charge. Just PM him. For those in the Bay Area, I'll do the same, although depending on where you live, we might have to meet at some mutually convenient location. For those in Europe, we might be able to match you with someone who lives near you and has an AVR programmer. Please post in the comments if you need that.]
Read more…
a little info i couldnt find anywhere else. while programming my quadrocopter, i somehow messed up the throttle start and end-points of one of the esc's. the motor started only when the throttle was already in the middle. after some googling and experimenting, i found out how to reprogramm the endpoints. this will probably work with other esc's too.here's the exact procedure:- connect esc to receiver and motor, do NOT connect battery- on the (turned on) remote move to full throttle- now connect the battery- the esc will beep twice (two short beeps)- right after that, move the throttle back to idle/off/stop- the esc will now do the normal beeps (in my case 3 beeps for 3s lipo)- it can probably be used now, but i would "reboot" (disconnect battery and connect again) just to make sure it worked.this procedure fixed it. i then did this to all 4 esc's, and for the first time, all the props started moving and stopped at the same time. also got the best and most stable hover up until now.im surprisingly quickly getting to very stable results. all the axes are stabilised now. i removed the accelerator mixing for the moment (vibrations are problably making it useless right now) until i connect a display and see what's going on exactly. for short flights this isnt a problem. the quadro lifts off and stays very calm, no wobbling, no heavy vibrations (except motors of course), it's just slighty moving around, but i can control it with the remote. this probably can be stabilised with the accelerometer to.also did some hacking to the board, and connected another 4017 (to the unused output compare unit of timer 1) so i could drive the esc at 200hz, works perfectly!! love those esc's!here's the code of the PI-controller:int sens_nick = (gyro_y>>1)+(y_angle2>>10); //the current gyro data + integrated gyro data (shifting is precise enough at the moment :)int sens_roll = (gyro_x>>1)+(x_angle2>>10);int sens_yaw = (gyro_z>>1)+(z_angle2>>10);int inp_nick = -50+((serinp[1]-3750)>>3); //a little trim, plus the input from the ppm-decoder/remote-controlint inp_roll = -50+((serinp[0]-3750)>>3);int inp_yaw = -30+((serinp[3]-3750)>>3);//seradj is added to the throttle-input and passed to each esc.seradj[2] = (sens_nick-inp_nick) -inp_yaw-sens_yaw; //backseradj[3] = -(sens_nick-inp_nick) -inp_yaw-sens_yaw; //frontseradj[0] = (sens_roll-inp_roll) + inp_yaw+sens_yaw; //rightseradj[1] = -(sens_roll-inp_roll) + inp_yaw+sens_yaw; //left
Read more…3D Robotics
This is the first post in what I hope will be a mini-series on doing hardware-in-the-loop simulations with ArduPilot. A simulation is something you do to test your autopilot on the ground, where you won't get in trouble. It's an absolutely necessary thing when you're writing your own code or fiddling with ours and constructing a simulator is part of basic autopilot development.
It's called "hardware-in-the-loop" because you're using your real autopilot hardware, but feeding it simulated sensor or GPS data to make it think that it's in the air and moving around. Then you watch its reactions and see if it's doing what it's supposed to.
Eventually this series will take you to a full closed-loop simulation, where the simulator talks to the autopilot and the autopilot talks back to the simulator, totally replicating the interaction between plane and space. But for now, we'll start with the basics: simulated GPS in and telemetry out.
To do this, you'll need a computer with two USB ports (or two computers, as I've shown above) and two FTDI cables (or other USB-to-serial converters). Although it's not totally necessary, you'll also probably want a breadboard to do all the wiring on.
[UPDATE: See the comments below. You can download a utility that will turn one physical port into multiple virtual ports. That way you can use a single FTDI cable, and plug it straight into ArduPilot as usual. If you're using this method, ignore all the stuff below about the breadboard and wiring.]
You'll be running two programs on the computer(s): a GPS simulator and a terminal to see incoming serial data. I like the FlyWithCE GPS simulator and for a terminal, I use Realterm.
Plug in your FTDI cables one at a time. If you go into your Device Manager (Control Panel/System) after you plug each one in, you'll see which ports they're assigned to. Now set up the GPS simulation software and the terminal so each is using a different one of those ports, and set the baud rate to 4800 for each.
Now we're going to connect them to ArduPilot. Set up a breadboard with header pins and plug your two FTDI cables in on each side, with one 3-pin header off to one side on its own row. Use jumper wires to connect the 3-pin header to the following ArduPilot pins on its FTDI port: GND, TXO and RXI.
Depending on which FTDI cable you're using you can figure out which pins are which this way:
--If you're using the Adafruit cable, the black wire is ground, the yellow wire is TXO and the orange wire is RXI.
--If you're using the Sparkfun breakout board, the pins are labeled.
Now wire up the breadboard as follows:
The "GPS" cable (the one that's associated with the GPS simulator) should have its RXI pin connected to ArduPilot's RXI pin. The "telemetry" cable (the one that's associated with the terminal program) should have its TXO pin connected to the ArduPilot's TXO pin. All the grounds should be connected together.
It looks like this when you're done:
Needless to say, you should disconnect ArduPilot's GPS module, but otherwise keep the autopilot in the plane wired up to the servos and Rx as usual. Power it on.
In your GPS simulator program, enter a starting location lat/lon (it doesn't matter which if you're just doing RTL, although you might want to keep it in your hemisphere!) and pick move or circle and some speed at which you want it to fake the aircraft's motion. In your terminal program, there's nothing to do as long as you've got the right port and speed selected.
Now press "Start" in the GPS sim. It will start spitting NMEA sentences down the FTDI cable, which ArduPilot will think are coming from its GPS module. Meanwhile ArduPilot will start sending data (wherever there's a Serial.println command in the code) out its TXO pin to the other FTDI cable, which should show up in the terminal program. The autopilot should also respond the way you would expect if this was real GPS data, including moving the rudder to steer back to its starting position when you toggle it on with your RC transmitter.
Of course it won't really steer home because A) it's on the ground and B) we haven't enabled a feedback loop yet. But you can at least test program logic and see what the autopilot is thinking as it gets moving GPS data.
In the next post, we'll use a flight simulator program instead of the GPS simulator utility, and we'll discover what a "human in the loop" simulation is!
Read more…
