So, what do you do when you have some old hardware lying around, and want to reuse that instead of buying the new ArduMegaPilot: Build you own ground station and modify parts of the code for the Ardupilot.
First of all I got tired of LabView, and the other standard parts, and found later versions of Ardupilot too messy to manipulate. Second, most of the available ground stations are written for Windows, not good at all on a Mac. Third, I needed some functions, that is not obviously available when using Ardupilot.
What I have done is to implement a simple ground station in Java, using standard components. It shows the basic information transmitted by the Ardupilot. It uses Google Earth to show the planes position on a map. Further more, it supports two way communication with the Ardupilot. This means that I am able to adjust gains, upload waypoints from a Google Earth .kml file and so on, while the UAV is in the air.
If anybody is interested I will make the sourcecode publicly available.
Best regards
Niklas
EDIT: I have add'ed the source code for the ardupilot and the source for the Java groundstation. The code is not commented at all, and is highly customized for my setup. Feel free to use any parts you want. Any questions, hit me! The code also contains quite good examples of how to encode at decode binary GPS data. Enjoy.
Here is a video of the first test made on my GAUI base. The Quad is stable even with a 3000 mAh battery (heavy). Notice that the brain card is at the same level than Motors !!! i think that's important for the stability !!
A trip to Radio Shack found me with a protoboard and a handful of IC sockets about 150 soldering points to practice with. A delivery from Sparkfun provided a “Simon” kit for soldering practice. The Simon kit went together without any problems in about 40 minutes while I was in a conference call. The practice was good. I don’t think I will have problems assembling the ArduMega.
A week ago I ordered a Skywalker, motor and ESC from BEVRC, as a bonus I added a Falcon EPO (Flying wing) to the order to get Free Shipping. It was a simple choice, $50 for shipping or add $50 to my order to get Free Shipping. The Skywalker arrived last Friday and the Falcon arrived yesterday. I will not complain about the shipping from BEVRC.
I am going to pick up the FrSky Module for my radio (Futaba 9C) with my next HK order along with a 5.8ghz transmitter/receiver combo.
Airframe Path
I am waiting on 10mm carbon fiber tubing for my tail booms. Yesterday 3mm and 6mm square carbon tubing arrived. The 6mm tubing will be used as the main wing spar and will be the step at the 50% mark for the KF3 airfoil.
I can start work on constructing Airframe #2 and should have the main wing done in a day or two.
I'm currently copter-less and waiting on new motors to arrive from China, so I had some spare time this weekend to do a quick side project. It's a ground up re-write of the original Ardupilot using the latest Libraries for APM. The only difference is I had to use some tweaks to avoid filling up all the flash ram. With the Ardupilot GCS code, it's less than 1k from full. But it's all in there.
I could use some help testing because I can't get away to fly anymore. All of the systems seem to work correctly. The only trick is that the AP_config.h file needs your exact radio pwm values.
/***************************************/
// RADIO
#define CH1_MIN 1112 // (Microseconds) Range of Ailerons/ Rudder
#define CH1_MAX 1938 // (Microseconds)
#define CH2_MIN 1102 // (Microseconds) Range of Elevator
#define CH2_MAX 1936 // (Microseconds)
#define CH3_MIN 1101 // (Microseconds) Range of Throttle
#define CH3_MAX 1931 // (Microseconds)
#define CH4_MIN 936 // (Microseconds) Range of Rudder
#define CH4_MAX 2101 // (Microseconds)
You can use the AP_RC_Channel example sketch in the Library to get those values.
Otherwise it works with HappyKillmore's GCS and the latest GPS modules.
RAM is totally freed up using the PSTR macro so no more code crashes...
For know you can leave a comment here for bugs and fixes. Then I'll do a Beta and start using the issues list.
Code is on the Ardupilot Trunk and called Ardupilot_2_8
And here above, a small video of one of our first run up...
Blades are free floating (no pitch control link attached). Qty(2) motors are powered although not synchronized. One motor under current consumption monitoring (drawing 8 amps). Only 25 % of motor normal regime. Still a lot of data to be gathered. What a nice sound ! No!
Minimal distance to takeoff 1km or a mile. Must follow the plane and maintain visual contact as per actual laws. Electric winged machines only. Extra points for motor-off gliding over target.
I'm delighted to announce that APM 2 is now out of beta! The current version is 2.1, and is both available in the downloads section of the code repository (for those who want to play with the code), or can just be loaded as normal through the Mission Planner.
This code largely reflects a ton of bug fixes, small enhancements, efficiencies and lessons learned from preparing for and competing in the Sparkfun Autonomous Vehicle Competition (in which it placed 2nd). It should work well with the latest Mission Planner, HK GCS and Xplane simulation.
Huge thanks to Doug Weibel, Paul Mather, Michael Oborne, Andrew Tridgell, James Goppert and Michael Smith, who drove this version.
This version has had a huge amount of testing over many months, but as always, there may be some remaining issues or bugs on unusual hardware configurations, so if you find something, please post a report in the Issue Tracker.
With the APM together, it can display much information on the screen, e.g. the attitude of the plane, GPS data, NAV data, etc. The details of displayed information can be found in the web site of Remzibi OSD and the ARDUmV1_71.txt. Blake Krone has done great works to integrate the OSD and the APM. However, due to the fast development of the APM, some source codes are out of date, and thus a few modifications are needed to make them work properly. In this article, we give a detailed instruction of those modifications.
Our work is based on
1. APM 2.12 source code. Arduino-0022 IDE.
2. The firmware of OSD is ARDUmV1_71.hex
3. The serial port of the OSD is connected to serial port 3 of the APM (i.e. Telemetry port). Because the OSD does not send data to APM, the TX pin of the OSD is not required to be connected. You can also connect the Xbee to the serial port 3 of the APM in the meantime. In such case, the RX pins of the Xbee and the OSD are connected in parallel, and You MUST NOT connect the TX pin of the OSD. The Baud rate of the OSD is self-adaptive, and it is usually below 115200.
Here are the modifications:
First, download OSD_Remzibi.pde, and then modify some parameters according to the definitions in the code of APM:
These macros tell the APM to use the serial port 3 to connect to the OSD under the REMZIBI protocol. The channel 7 is used to control whether the OSD displays. You can change the serial port or control channel if it is needed.
② ArduPilotMega.pde ：
In function medium_loop(), add following codes before the break statement in case 3：
#if OSD_PROTOCOL != OSD_PROTOCOL_NONE
print_osd_ahrs();
#endif
In function slow_loop (), add following code before the break statement in case 1:
#if OSD_PROTOCOL != OSD_PROTOCOL_NONE
print_osd_data();
#endif
// Read OSD Mode Switch
#if OSD_PROTOCOL == OSD_PROTOCOL_REMZIBI
read_osd_switch();
#endif
③ defines.h ：
Add following codes after “//GPS type codes”：
// OSD type codes
#define OSD_PROTOCOL_NONE -1
#define OSD_PROTOCOL_REMZIBI 0
④ commands.pde ：
In line 251, add following code at the end of function init_home()：
// Save Home to OSD
// ----------------
#if OSD_PROTOCOL == OSD_PROTOCOL_REMZIBI
osd_init_home();
#endif
Now, all the modifications have been done. Copy the OSD_Remzibi.pde to the folder of the source code of the APM 2.12（APM Trunk\ArduPilotMega）, start Arduino, build the sketch and upload to the APM.
I attended the first annual UAV airshow and was happy I did. I learned OSU aerospace design team has been winning the AIAA contest for so many years, they dropped out this year to start their own contest. They divided the students into two groups, the Black and the Orange. The goal was to fly as fast as possible from point to point and around pylons.
This event was truly impressive. These small plains reached over 180mph. They where hand made of carbon fiber with off the shelf electronic components. I spoke to several of the students and they where more than happy to describe each step of the process. Besides the contest there where also flybys for vintage planes and some great models as well.
With over 700 attendees this first year I'm guessing next year there will be even more contestants and spectators in years to come.
When I started with my copter, I thought of making a Linux based GCS, as I don't run Windows. However, I decided that trying to duplicate all the work on the Windows GCS was counter productive. On top of that, my laptop is dying, so in the field it would be less than useful anyway.
I recently got an Android phone, in part for its programmability. Linking it up to a quad (or hexa etc.) seemed like it would be useful. Therefore, I've been working on an Android based GCS, and although by no means done, I thought I would share and maybe get some feedback on desired features.
The phone really only has WIFI and Bluetooth for connectivity, and my quad has neither of those as options. Finding a 802.11 link for on the quad proved tough, and the range on Bluetooth is not good enough for what I am looking for. To solve that I made a Bluetooth <-> XBee link: its small and just stays in my gear case while letting me use the phone at long range from the quad. When using my laptop, I can just use it's bluetooth connection and still use the standard configurator.
I needed a place for code, so if interested, its hosted at Copter-GCS Wiki. There are screenshots there showing features, but in a nutshell:
-Configure PIDs -Calibrate Offsets and Transmitter -Sensor graph for current outputs -Map the quad GPS position, as well as the phone's
Like I said, its not done, and has some things to work out. Once I do I will make the code available (if there is interest). There are a bunch of things I want to try with this, like GPS following etc, but this seemed useful for in the field calibration/testing. When Arducopter 2.0 comes out, I will update so that the MAVLink protocol is compatible.
The CanberraUAV team did our first flights with our full onboard computer system (a pandaboard) on a SkyWalker test plane this weekend. This allows us to capture images of the IR lamp used in the outback challenge from the air, combined with the telemetry we need to start working on our image recognition algorithms.
In the above photo you can see our basic setup. We have the pandaboard, a USB hub (powered), a 64GByte SSD, a ptgrey chameleon greyscale camera with a IR pass filter, a UBEC to power it all, and of course the usual APM, GPS, magnetometer and XBee radio.
Rather than cutting a hole in the side of the plane as most people do for a SkyWalker, we cut the foam barrier out from under the wing (where some people put an extra battery), which gave a good top access hatch to the main compartment. The pandaboard and other electronics fit nicely down into the plane from there, and it provides easy access to the ethernet interface on the pandaboard for diagnostics, as well as all of the USB ports.
This is what it looks like when we put all the bits inside the plane:
One quite unusual aspect of the setup is that the APM is connected via USB instead of FTDI. The USB cable goes to the pandaboard, which runs a copy of mavproxy to gather the telemetry. The panda also controls the camera, which means the same clock is used for time-stamping both the telemetry and the images, which really helps in matching them up for image recognition.
The camera was fitted in the bottom of the plane, below the leading edge of the wing, pointing straight down through a large hole in the fuselage, with a large IR pass filter in front of the lens.
We flew several missions over the weekend. The first was a simple search pattern (the same 18 point pattern we flew last weekend), to ensure the camera system was working well. We captured over 3000 images (each at 1280x960 in 16 bit greyscale), and got some quite nice ones of the new runway at CMAC:
On saturday afternoon I concentrated on improving my flying skills. I flew over 90 takeoffs and landings that afternoon, which really improved my confidence.
On Sunday morning we flew a search mission again, but this time with the IR lamp in place to allow us to get a better idea of what 'Joe' will look like from the air. You can see the IR lamp in the picture below (circled in red with the circle automatically placed by our very simple search code).
You can also see the edge of the foam hole in the plane near the bottom of the image. The velcro we were using to keep the camera centered on the hole was not as good as we'd hoped.
At the end of this flight we had our first crash with this plane. The USB connector between the APM and the pandaboard came loose, causing mavproxy to reconnect, which rebooted the APM. The reboot process took 5 seconds, during which time the plane went crazy, flying upside down for some of the time!
I knew this could happen (as I hadn't found a way to stop the DTR drop on the USB serial link from the panda, the normal termios calls don't work), so I had the APM setup for air-start. Unfortunately I didn't realise the APM had rebooted until later, and at the time I thought a control surface had come loose. I switched to manual and tried to bring it under control, but failed, and it hit the ground. There wasn't much damage (the SkyWalker is tough!), but it is a shame I didn't just trust in the autopilot to regain control after rebooting, as it would have been a good test. The mavlink logs show the reboot took 5 seconds.
After that we added a bit more tape to the nose where it suffered some crumple damage and went flying again. Andrew and Steve had some time flying the plane to get some practice in, then I started some more serious practice as part of my long term goal of earning my MAAA wings. After practicing takeoffs and landings on Saturday I thought it was time for something more ambitious, and did some barrell rolls and loops. It sure is easier doing acrobatics with STABILIZE mode to recover! I did quite a few rolls and loops over a period of a couple of hours before calling it a day.
We're getting ready to launch the beta ArduCopter 2.0 (formerly known as ArduCopterMega, or ACM), and much has changed. First, it's our first real quadcopter UAV code, designed from the ground up for fully scripted autonomous missions as Jason's runs at Sparkfun demonstrated. It's also totally built on the APM code base, so sophisticated MAVLink mission planning and telemetry is built in and it inherits APM's mature navigation algorithms.
Replacing the LabVIEW configurator that we used in ArduCopter 1.x is a configuration utility built into Michael Oborne's fantastic APM Mission Planner. This both gives you command-line (CLI) access to the ArduCopter 2's interactive setup process, as well as a graphical display of all the sensors at work, so you can see at a glance that everything is working right. And because it's all MAVLink-based, you can use it equally well on the bench via USB as at the field (or in the air) via Xbee. And it will work for any MAVLink-based UAV!
Unlike the old Configurator, you don't need to install LabVIEW to use this. Although the Mission Planner is Windows-only right now, you can use ArduCopter 2's built-in CLI to set up the board and software on any operating system, which will give you a text-based version of all the same data. Our aim is to be totally cross platform, just like Arduino.
As with APM, the Mission Planner will also load the code, so there's no need for Arduino anymore (unless you want to tinker!). Our aim is to make ArduCopter the easiest quadcopter UAV setup on the market. We've still got a ways to go on that, but the progress so far has been very impressive. There are a lot of RC quads out there, which are increasingly easy to set up, but very few real UAV quads with autonomous mission planning. We'd like to make setting up a UAV no harder than setting up a RC aircraft. ArduCopter 2 is a big step in that direction.
As for the release of ArduCopter 2, we're very close. The dev team will review the last outstanding issues on Sunday, with the target of releasing the first beta next week, with documentation.
