Here's a modification of original ArduPilot, running on Arduino Pro Mini.I'm just posting photos for now, since there's still lots of things to do for my planes to fly. Maybe when things are tuned, I'll post also modified code.My first testing or original ArduPilot few weeks ago was disaster, I tried to see my plane to see directly follow path, so I skipped slow testing of everything in small steps. Result was plane out of control, flying away to distance. Later I found it using bike, 1.5 km away. I had luck that time, I could have some $350 flown away, or maybe breaking someone's roof. Anyway, my previous plane was not flying nice, so this one is replacement, and it flies good in manual mode.
See the Arduino Pro Mini, compared to ArduPilot. It's smaller, and it lacks mux and failsafe chips. So great care must be done for switching between autopilot/manual modes on main cpu. Luckily tests show that it can be done relatively nicely using interrupts, so if main program control locks, interrupts still keep running, providing the possibility to gain control over plane.
Arduino Pro Mini on left, ArduPilot board on right.So far I play with FMA copilot replacement, implementing just stabilization. 6 RC channels are read, and 4 are written, the code can pass 4 channels through unmodified, or read them and mix with other values.
ArduPilot is great piece of hardware, no doubt. However it comes to its limits, mainly with limited memory, just one serial port, limited connectivity to other peripherals.So I have idea in my mind about improved setup, which would still use ArduPilot as hardware interface board for servo signals (5 channels IN from RC receiver,4 channels OUT for controlling plane), and of Infrared stabilization reading.Then it would connect to bidirectional serial link over Bluetooth module, which would connect ArduPilot with a smart phone located on the plane.One well-tuned firmware would be uploaded to ArduPilot once, this would provide work with signals and communication over BT module. These are ArduPilot's strong points.The central brain would be a mobile phone (or PDA) stored in plane. The phone would get servo positions from RC receiver through ArduPilot and over BT serial link, and the phone would also send servo positions back to ArduPilot for controlling plane. The phone would compute stabilization and navigation.GPS signal may come from external Bluetooth GPS module mounted somewhere on plane, or from phone's built-in GPS module (if the phone can be placed in plane with good signal reception).These are main benefits:- easier waypoint configuration (sending to phone over Bluetooth or memory card)- possibility to have multiple waypoint paths stored on phone, selectable on airfield from phone's menu- tuning autopilot parameters (e.g. PID loops) in phone's menu - no need for connecting laptop- using phone's camera for taking photos of video- logging flight data to memory card- much more memory for program and data- using mobile Internet connection or SMS allows for:> uploading new waypoints in mid-flight> reading telemetry in large distance> sending photos or video during flightThe phone would run on Windows Mobile or Symbian OS.Considering power, many phones and GPS modules allow charging over mini-USB plug, so this equipment could be charged during flight from same 5V source as used for ArduPilot. Or just left to use their own batteries.I'm waiting for my first Bluetooth serial module to come, then I'll make testing with such possible connection.And also still waiting for better weather, for trying original ArduPilot in air...
Posted by Michal B on February 15, 2009 at 12:30am
It's still freezing cold outside, so I'm playing by PC with more simulations.My first UAV is ready to go, for now I hooked by FTDI cable to PC, and checking if everything is OK, before going out to make a real flight.The plane may look fragile and ugly, well it is, but at present it is my working plane which I'm used to. Also it was cheap, and is very easy to cut holes in it for adding more wires and putting in more electronics. It weights about 400 gr. Once I make this fly and tested, I plan to go higher to a new 1100gr fuselage.My simulation setup is described in this blog.I run the simulation, and watch if real plane turns servos as expected. Only motor signal is disabled for now (don't need too much wind on my table). All looks fine, so now just waiting for springtime...Plane details:
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.
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.
Original ArduPilot controls 2 servos (throttle/yaw) by autopilot code or from RC receiver. Other 2 servos are controlled by FMA copilot (or again manually by RC). Although there're servo IN3/4 and servo OUT 3/4 connectors on ArduPilot board, they're at present unused (actually only pass-through control from IN3/4 to OUT3/4 is connected).Yet there's simple way to control all 4 servos from ArduPilot code, and use other two servos for interesting tasks, such as moving plane's camera tilt. Or even better - provide full stabilization in basic ArduPilot, which is at present only planned in ArduPilot Pro.While I don't know yet if stabilization code would fit into 16KB memory of AT168 (together with navigation code), I'll just post how to control all 4 servos from code. We'll see what comes out of this.On hardware side, there's simple wire soldered between digital 6 pin and MUX IN 3 pin. Also connector is added at servo OUT 3 at top right for connecting the servo:
This is for controlling servo 3, for adding control of servo 4, add another wire from D7 to MUX4 and another connector to Servo OUT 4.Now programming part... For controlling servo, we need to output PPM signals at pins 6/7. And do it at 50Hz frequency. Luckily we can set interrupt function that will be called 50 times/second, and generate PPM pulses there. This functionality will use up to 10% of CPU (for delays while generating PPM signals). All the code is here.In your code, call Servo_3_4_Init once, then Servo_3_set or Servo_4_set whenever you need to set angle for particular servo.That's it! We can control now 4 servos from inside code. And possibly add stabilization part to the code...? Let's hope so.
If you don't like too short connection cable of GPS to ArduPilot, then here's a fix. Longer cable and better connector will solve 2 problems:- more flexible assembly into a plane- easier program upload to board (since GPS cable must be disconnected before uploading)Original connection:
We don't need to use original GPS connector on ArduPilot, and can connect directly to one data pin and Ground/VCC. So we need just 3 wires, and ideal choice is standard servo cable.I used Servo extension cable, cut it close to female connector, and soldered it to the board as shown here:
Then cut original small GPS cable to half, and solder it with servo extension cable male part:
ArduPilot code, modified version for use on Microsoft Visual Studio. Compatibility with Arduino studio still maintained.Also contains parser of KML files, for importing fly paths drawn in Google Earth.Installation instructions:1) Download and extract ArduPilot_20090211.zip2) Download Arduino AVR studio3) Extract above into ArduPilot.vs\arduino-0012 folder4) If you don't have Microsoft Visual Studio 2005 yet, you can download free edition here (choose Visual C++ Express 2005)
5) The code is still compatible with Arduino studio, simply run arduino.exe and open project from ArduPilot.vs\ArduPilot folder
Build instructions under Visual Studio:- Open workspace ArduPilot.sln- Workspace contains folder "Source files" with ArduPilot code, this is where changes can be made
- Another folder "System" is containing source files from Arduino studio needed to run ArduPilot executable, do not modify these- Build project as usual, if you see "Created ArduPilot.hex" in log window, then everything is OK
- To upload to board, use Upload.bat from command prompt (you need to specify correct port in -P parameter)Note: if you change anything in *.h files, hit Rebuild Solution, because source dependency is not working in this caseWhy using MS Visual Studio for building ArduPilot code, when Arduino studio does the same thing?Well, if you're a programmer, then answer is clear - VStudio has better text editor, it will assist you in writing code by tools such as finding variable/function definition and declaration, text editor code highlighting, provides auto-complete, etc.Alghough we don't use C++ compiler from Visual Studio, rather custom build step is used with AVR compiler, mentioned advantages will help to make the code reliable and robust.On other hand, Arduino studio has very simple text editor, usable for the task, but if we have better tools, why not using them.Note: Visual Studio can be used on Windows only, so using Arduino studio makes sense for Linux/Mac users.How to use KML parser:This tool transforms KML file from Google Earth into ArduPilot friendly file.Usage:- In Google Earth, use Add -> Path (Ctrl+Shift+T)
- Click to define waypoints
- Do not connect last waypoint with first, it would create polygon which is not supported- Save the path in KML format (not KMZ)
- Use KML parser to extract coordinates and create ArduPilot compatible file; the utility accepts 2 parameters - source KML file and destination H file; first is your KML path file from Google Earth, second is usually set to ArduPilot\waypoints.h, this will create waypoints file compilable by ArduPilot code. There's testing KML file as well as KML_test.bat file which puts proper parameters to the KML tool.- Compile ArduPilot executable and upload to boardSource code is provided for KML parser tool. It is compilable under MS Visual Studio, and runs on Windows.Problems and tasks:- Google Earth doesn't allow to define altitude for individual waypoints, or to export KML file with absolute altitude,so we end up with same altitude for every waypoints for now.We can fly on same altitude level, or manually tune altitude in generated waypoints.h file, or come with some other fix (suggestions are welcome).