Category: Projects

Continuing to work on the quadcopter with Multi-Wii Pro board I added a bluetooth module to it

and used the android application EZ-Gui Ground to communicate and upload the waypoints for a misson

Starting with a simple circle of the field. This was uploaded to quad, the quad taken off and then the mission activated the quad then made its own way round the waypoints programmed as you can see from the video below:

At the end of the video you can see Scott’s Corsair, then the quad way landed manually.

https://www.youtube.com/watch?v=ssuJI0qoQWU

 

Since first building the quadcopter with the HobbyKing flight controller board we had a few issues with stability. Robert purchased the MultiWii-Pro board, and was having some issues with the configuration software, so has lent me a second board he purchased. The MultiWii board has many advantages over the KK base HobbyKing controller board. Over the 3 axis giros which are fitted to both boards, the MultiWii has 3 axis accelerometers, magnetometer (compass), barometer and GPS capabilities, although the MultiWii pro normally comes with a GPS unit, they are sensitive to being wired up wrong which is why Robert bought a second unit and this one doesn’t have a GPS. So I purchased a Crius Neo 6 version 3.1 which is based on the U-blox Neo 6M chipset. This is capable of outputting navigation data 5 times per second and an accuracy down to about 2 meters, although the configuration needs updating. This was done by connecting it to a computer through a USB FTDI serial adapter (or similar) and the U-Centre software from U-blox (http://www.u-blox.com/en/evaluation-tools-a-software/u-center/u-center.html).

The default baud rate of the board is 9600, I connected up, used the View->Configuration view and updated the baud rate to 38400 baud (in the ports section), above this tends to introduce errors, this rate gives a good transfer of data with fewer errors. Once this was updated I updated the baud rate of the connection and reconnected. The Updated the navigation update rate (in the rates section) to 5 times per second (200ms). Updated the SBAS settings to apply SBAS correction data. This improves the accuracy of the GPS unit, but it does require a bit longer to get a full fix. I then went to the NAV5 section and updated the Dynamic model to ‘Pedestrian’. This seems to be the recommended settings for using these on quadcopters and similar. Clicking send updates these settings on the GPS unit, going to Receiver->Action->Save Configuration then also saves the configuration to the non volatile memory on the GPS unit so the settings remain even after the unit is powered down.

 

The GPS was then connected to the MultiWii board.

Looking round on the web I found this guide to updating the software and settings on the board https://www.youtube.com/watch?v=9TIUif3PE9U

So I downloaded the code from https://code.google.com/p/mw-wingui/downloads/list downloading the files MultiWi2_3-navi-b5-baro_fix.zip and WinGUI_2.3pre8(b5).zip. Then downloaded the IDE for Arduino boards from here: http://arduino.cc/en/Main/Software (http://arduino.cc/download.php?f=/arduino-1.0.6-windows.exe)

After unpacking the MultiWi2_3-navi-b5-baro_fix.zip file and installing the arduino ide software, I opened the multiwii software, (file, open, find the unpacked software and open the MultiWii.ino file) selected config.h file from the down arrow on the right of the screen and updated the config.h file, to my GPS baud rate, I also updated the setting #define MOTOR_STOP which changes the default idle spin up of the motors when the unit is armed, and updated various other settings for this specific board and the X configuration quad copter (my final config.h is available lower down this post). From Tools->Board, selected Arduino Mega 2560 or Mega ADK selected the serial port that the board had been assigned by windows and clicked upload. This compiles and uploads the code to the board.

I then ran the WinGUI software connected and updated the flight tuning parameters to set the P values to 5.0, 5.0 and 8.0 for roll, pitch and yaw respectively. Click write settings to update these settings to the board.

Then go to RC Control settings, I have a 6 channel receiver, so have 2 extra channels which I can use to change the various flight modes. Each channel can be used in 3 positions, low medium and high. I used the first channel to add the ‘Horizon’ (self leveling) mode to the mid and high position, and ‘Mag’ (heading hold) to the high position this way on the flap switch I can use off as just giro stabalisation, mid position as self leveling and high position as self leveling and heading hold. I then used the second channel mid position (only) for GPS hold, and high position for Return to Home. Again write the setting to the board.

The MultiWii board also has connections for a camera gimbal, to keep the camera level regardless of the orientation of the quadcopter (within normal flight conditions obviously). I managed to get the gimbal pictured below 3d printed. To activate it this needed more updates to the config.h file enabling the #define SERVO_TILT setting, and also going to the windows gui and enabling the camera stabalisation, since I didn’t have any more channels, I added it to channel 1 on all 3 positions so it was always on.

I did find that the software didn’t seem to work very well, shifting the platform in the wrong direction and not to the appropriate proportion, looking at the software this seemed to be changed by the Servo Rates settings, but I couldn’t get this to work, so I made these changes to the output.cpp file:

Changing:

#if defined(SERVO_TILT)
servo[0] = get_middle(0);
servo[1] = get_middle(1);
if (rcOptions[BOXCAMSTAB]) {
servo[0] += (int32_t)conf.servoConf[0].rate) * att.angle[PITCH]) /50L;
servo[1] += (int32_t)conf.servoConf[1].rate * att.angle[ROLL]) /50L;
}
#endif

to:

#if defined(SERVO_TILT)
servo[0] = get_middle(0);
servo[1] = get_middle(1);
float camTiltPitchProp=1;
float camTiltRollProp=1;
#if defined(TILT_PITCH_PROP)
camTiltPitchProp=TILT_PITCH_PROP;
#endif
#if defined(TILT_ROLL_PROP)
camTiltRollProp=TILT_PITCH_PROP;
#endif
if (rcOptions[BOXCAMSTAB]) {
servo[0] += ((int32_t)(camTiltPitchProp*(float)conf.servoConf[0].rate) * att.angle[PITCH]) /50L;
servo[1] += ((int32_t)(camTiltRollProp*(float)conf.servoConf[1].rate) * att.angle[ROLL]) /50L;
}
#endif

This allowed me to add the settings #define TILT_PITCH_PROP -2.00 and #define TILT_ROLL_PROP -1.00
to the config.h file which I set to be -2.0 and -1.0 for pitch and roll respectively after a bit of testing this seemed to the appropriate setting to make the platform correctly counter the pitch and roll of the quad.

My current output.cpp and config.h can be found here:

http://blog.smfc.co.uk/wp-content/uploads/2015/01/config.h

http://blog.smfc.co.uk/wp-content/uploads/2015/01/output.cpp

 

2 weeks ago in the fog I gave it a quick test:

http://www.youtube.com/watch?v=PMG5xhxUmcQ

As you can see the pitch seems ok, you can see the rotors moving up and down in the frame as the copter’s frame pitches forwards, but the horizon stays quite well level, the roll is far further out, although there is some effect, it is not enough and the camera is rolling with the frame

I was very glad at one point that the return to home worked as I lost it in the fog, fortunately it managed to find its own way back. As you can see the roll was much too low, I think the roll setting was slightly too low, so I updated both pitch and roll to -2.0 although last week the weather was a bit windy to make another test flight, and this week I couldn’t make it.

I would like to test this, and record with the GPS on screen data to get some idea of the speed and fly-ability of the quad, hopefully it is not far from being able to do some air to air recording. I will update this post with details and videos as I get them.

Earlier this year I tried a new flying change – slope soaring using a Spectre flying wing. Following this initial experience, I decided I wanted to build my own conventional type of glider and started looking at kits and glass/carbon fibre planes. However, having spent many years messing with, building and racing cars, I thought it may be a interesting idea to try some of the techniques and methods used in developing and building car bodywork, hence this design and build exercise.

I started by researching designs using information from various sources including:
http://www.phoenixmp.com/articles/slope.htm
http://www.rc-soar.com/tech/perfanal.htm
http://charlesriverrc.org/articles.htm
http://www.flyingobject.com/

My first activities were to develop a design spec based on the phoenixmp article, full size wing drawing and produce a short piece of wing section from a split aluminium sheet mould to understand the weight and strength. The spec is attached to this blog, where ‘1850 Mk1’ is the current build which started with a target 12oz / ft2 wing loading (I was dreaming…) and ended up at 21oz to achieve the balance, hence the flying brick. The ‘1850 Mk2’ worksheet shows my initial thoughts for my next build with the primary focus on reducing weight.

Design Spec v0.2

To give an idea of the build, I have included some photos showing the wing moulds and views of the model.

Key points from this initial prototype:
– the tail and back end of the fuselage needs to be lighter;
– extend the nose length to reduce the ballast up front;
– reduce the size of the ‘V’ as this was based on the suggested ratio, hence change in ‘V’ tail spec;
– change the wing build method from two single sheets of 200g Woven Roving layed-up across both halves of the mould and folded over the spares, to producing two separate halves then join together over the spares;
– Use a metallic silver paint base coat instead of normal cellulose to reduce weight;
– reduce the diameter of the fuselage where the back used a split and tapered 1 1/4 “ waste pipe and rolled lemonade bottle for the front, this will necessitate putting the ‘V’ tail servos in tandem;
– Stiffen wing control surfaces.

The maiden flight was carried out at Burton Dassett with a westerly wind, not the ideal direction, limited lift and turbulent. flew my wing first and struggled with lift at times as it is 50% over the recommended weight, but in for a penny, in for a pound decided to try the brick. Before Robert threw it off the hill we checked the controls surfaces and put on a few degrees of flap. Much to my amazement it flew straight and level but did struggle to make height, eventually after a few turns landing on the slope. The second flight was better but still struggled to make height particularly on the turns, its 2.165kg weight was showing. It should be easier to fly with a more stable lift, Great Orme beacons or at least a true SW wind at Burton Dassett. In the meantime, build Mk2.

A while ago Mr Mel mentioned autopilot systems, at the time I was having enough trouble flying at the best of time without teaching a machine to fly so I didn’t give the idea much time, but more recently I have looked into this.

The first system that I discovered instructions on was the Arduino system, which appears to be a very extensible modular system which appears to allow you to fit together various modules and sensors to build pretty much anything you want (http://en.wikipedia.org/wiki/Arduino). This seemed great, but looked like it would need a lot of time and effort to get a simple system working. Carrying on looking I found some proprietary systems which had proprietary price tags. Eventually I came across the arudpilot system which appears to be a nicely packaged and programmed autopilot system based on the arduino systems, and it wasn’t that expensive. So I purchased a ardupilot, GPS with compass and an OSD module for the telemetry and for about £50 or so everything was delivered.

The Mission planner software which is used to program the ardupilot is rather impressive, but also a bit daunting at first view.

once connected to the ardupilot it starts receiving telemetry information. So I need to start with the basics, I’ll move onto full mission planning when I’ve managed to get the basics working.

The ardupilot hardware will work as an autopilot for planes, cars, helicopters and various configurations of multi-copters. The first step was to install the Ardupilot firmware onto the device so that it has the basic information that will allow it to fly a plane. The next step is to hook it up to the radio and the planes control systems

The ardupilot has a split power system with the input and the output power separated in this way:

Since the bec on the Catalina’s ESCs was probably 3amp at the very most I decided to use a second bec. I know the ESCs will power all the servos, so this is connected to the output line and powers all the control surfaces, and I connected another 3amp bec to the radio which provides power for the radio and ardupilot, both connect to the same battery using a 2 to 1 XT60 connector.

I powered up the system and configured the radio top and bottom points as per these instructions: http://plane.ardupilot.com/wiki/arduplane-setup/first-time-apm-setup/ I setup a mix on the gear switch and the flaps which combined gave 6 positions for the flight mode control. These I have setup with the options, Manual, Stabilize, Fly By Wire A, Loiter, Return to Launch, and mode 6 appears to be locked to manual as the systems ‘failsafe’ option.

Finally I hooked up the mavlink telemetry to my FPV gear and checked the information that gives on the screen:

As you can see its quite a lot, I think I will have to try to reduce the amount of information shown on this screen as soon as I can get hold of the appropriate cable and configuration software.

So the next step will be to test fly it…

Unfortunately my ground station for some reason did not record. I did get higher resolution shots from the on board camera, but this didn’t give the telemetry. I am really disappointed by this, and will update this post as soon as I can get some ground station recording done.

First Flight

Loiter was engaged at 1:26, Return to launch appears to be engaged at about 2:05. The plane seemed to be heading rather far over the house and away so I bottled it and disengaged it and went back to manual at 2:37 back to loiter at 4:18 I think, then off and back to manual at 5:00. Then a bit of a bouncy landing.

http://www.youtube.com/watch?v=N2d4lAGdBQ4

Mr Scott also followed the catalina with his Riot, but because I didn’t know quite how the ardupilot would perform I did fly rather high which made following it a challenge. Also as with all the videos the low autumn sun plays havoc with the camera trying to expose the recording correctly

 

http://www.youtube.com/watch?v=YV5Ur1Y7vzY

Second flight

At 49 seconds return to launch was engaged, the plane then flew itself until 2 minutes and then manual for a better landing.

http://www.youtube.com/watch?v=jke0LVjnth0

Really happy with the way it worked, would have been happier if I had some telemetry recording from the ground station to know more about what was going on, but will get this next time. Once I have a bit more GPS information recorded I can also move onto full mission planning, setting waypoints, and ultimately takeoff and landing 🙂

 

Update:

Although it is very stuttery, here is the onboard with the on screen telemetry, I think the stuttering is because there is so much more on the screen, so the compression on the recorder is so much more difficult and the recorder isn’t great. But it gives a good idea of what happens when each of the modes are engaged.

Working from the top left downward is:

Air speed, Ground speed (I dont have an air speed sensor so not sure if this is accurate), Throttle, battery percent (battery sensor not connected), Climb rate, GPS satellites in view, current and battery voltage (again battery sensor not contected), Longitude and Latitude. Middle column shows Roll angle, home direction arrow, warning text, artificial horizon, RSSI (looks like a bomb, but is not connected) and telemetry heartbeat  at the bottom. Right hand column shows, home distance, home altitude, current altitude, stopwatch, windspeed (linked to the air and ground speed, not sure how accurate this is, looks about right for today), pitch angle, WP distance and direction (don’t know), current flight mode (manual, loiter, return to launch0 with current heading to the right of this, and the heading rose under this.

https://www.youtube.com/watch?v=kJGKxXd_8l0

Update 30/11/2014

A slightly better onboard video

https://www.youtube.com/watch?v=PobaFpuAS-U

But an Awful landing!

This seems to be a question that is asked, but never really answered. The normal response is a full range receiver has enough range to work as far as you can see the plane. This was correct, but more recently we have been flying FPV which has allowed us to explore this question further, and with the GPS overlays have a reasonably accurate idea of the answer.

We have had 3 incidents which I based this post on, the first was the balsa E-Fair glider which was posted about here:

http://blog.smfc.co.uk/2014/06/fpv-and-taking-it-a-bit-too-far/

An AR400 full range receiver was installed in the glider which was correctly range tested to over 40 paces. At about 1 minute 10 seconds into the second flight control was temporarily lost, from the GPS coordinates this was calculated to be a little over 500 meters from the landing point.

The second example was a new video which was a flight of my polystyrene Catalina containing an AR6210 full range receiver (genuine not Chinese fakes which are about at the moment and correctly range tested):

http://www.youtube.com/watch?v=WDcQ0IntN0c

At about 1 minute 19 seconds into the video control was temporarily lost, although the overlay data is not on this video since it was recorded on the camera not the ground station the distance from the landing strip was a little short of 1600 feet (somewhere just over 500 meters)

The third incident is a little less clear. It is Scott’s balsa Decathlon flight. This contained an Orange DSMX 8 channel full range receiver:

http://blog.smfc.co.uk/2014/08/the-decathlon-that-caused-a-marathon/

Although the wind was blowing the plane away from the strip and the video was lost here which means that there is no direct evidence that the control was lost this was at around 1600 feet from the strip.

So the range of a standard Spektrum DSM based full range receiver appears to be about 500 meters. When flying FPV the pilot does not point towards the plane, so the orientation of the transmitter aerial will not be optimal, and in both cases where control comes back, the plane rotates then control returns, so the direction of polarization of the signal also appears to be taking an effect. We have also seen a notable drop in range of the FPV video gear when it was fully contain within even a foam plane, so perhaps the range could be extended slightly by externalizing the antennas. It is also possible that interference has caused these radio brownouts, we have seen brownouts before, but since both of these control losses happened at about the same distance in opposite directions from the strip, this offers less credence to this theory. Even with all these considerations I cannot see them extending the range to 1Km or more as I have see quoted on the internet. For normal flight 500 meters appears to be about the range of vision to reasonably see and control what your plane is doing. Our 250mw FPV gear with circular polarised antennas also appears to have about this as a range, higher powered FPV gear may need longer range control radios.

After learning the lessons of my previous flight (http://blog.smfc.co.uk/2014/07/fpv-on-a-new-glider-in-the-wind/) and with Scott kindly donating a Super Cub to the cause I have now fitted the FPV equipment, GPS and OSD.

Firstly I removed the brushed motor, speed controlled and unfortunately the receiver since this is a single unit, and because I don’t have a battery with an EC3 connector, or an adapter.

Replaced this with an AR400 receiver, 35amp brushless speed controller (top right of the picture below) and 1300 kv brushless motor with a 8×6 prop.

Then mount the GPS unit on the back of the plane behind the main wing, this gets 5v power from the receiver. The OSD (on screen display) unit is mounted to the side of the fuselage (bottom left of the fuselage cavity in below picture) behind the 5.8Ghz transmitter (bottom right), and the antenna of the transmitter being on a flexible stalk will fit over the side of the fuselage to be tucked under the main wing. The FPV and OSD both get their 12v power from a jst-xh connector connected to the balancing connector of the main flight battery. The DORA unit (in the centre, but not visible) also plugs into the receiver and the OSD to display the RSSI (Received Signal Strength Indicator) on the FPV screen.

Finally the wing goes on and the camera on top

all ready for a test flight