Following the successful maiden flight at Leckhampton yesterday I thought I should take a couple of pictures of it whilst it is unscathed… Pike started out as an experiment to make half a wing using balsa covered foam to compare weights with the glass fibre wings. This showed a 50% reduction in weight for the equivalent wing area in glass fibre. I also wanted a thinner wing section to help with the speed range to the extent that the aileron servos are mounted to the wing core within the fuselage and using a torsion bars. To test the wing I built a crude balsa box fuselage with V tail and painted the whole lot in clear acrylic varnish.
The initial maiden was carried out at the field where it performed in a similar fashion to the Skua being a light wing loading (9.8oz /sq foot). for maiden at Leckhampton, Mel launched it and to my surprise it was easy to fly and more stable that the Skua which maybe due to the bigger wing span, 1.87m against 1.5m for the Skua. The only real problem was the crow braking which caused the nose to climb, more down aileron needed.
What next, slicker stronger wings, sleeker fuselage…
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.
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.
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:
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:
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.
Following on from the ‘Flying Brick’ lessons learned which is ready for the right conditions i.e. lots of lift… I had a rethink on my second prototype requiring it to be significantly lighter and have a motor fitted (hidden when soaring) to enable it to be flown at the field assuming it does fly.
The key differences to try and meet the lighter weight is; a carbon fibre boom and moving tail as the back end of the Flying Brick is the primary contributor to the overall weight as the balance weight had a ratio of 2.8:1.
To improve the build finish and help keep the weight the wing skins are made as two separate pieces using aluminium moulds then bonded together with spares glued in. The fuselage mould is mage from 2” aluminium tube; shaped then split on the vertical axis.
I have attached a couple of initial photographs; one of the moulds and the other of the part assembled components. I will be providing updates as I get a little further through the build.
We are now getting closer to painting, need to fit the wing servos and tips… The controls for the moving tail and rudder are complete ready to fit after spraying, but what colour(s) shall I use?
The final painting and assembly is complete with an ready to fly weight of 1.4kg a touch heavier than wanted and may push the motor to the limit when field flying, that’s assuming it flies… I used base coat metallic silver as it thin and should be lighter that standard gloss cellulose.
Assuming it flies at the field and is not destroyed, the next step will be to replace the prop spinner with a glass fibre nose for soaring.
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:
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.
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.
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.
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
At 49 seconds return to launch was engaged, the plane then flew itself until 2 minutes and then manual for a better landing.
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 🙂
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.
A rotary wing aircraft that I can fly outdoors has been something that I’ve been wanting to try for a little while, I even priced up the required items to build a quadcopter on hobbyking, but then procrastinated about buying it until I spoke with Scott who fancied building one too. So I ordered 2 full sets of kit so we could both build one each.
The shopping list I had for each copter was:
1 x Q450 V3 fibre glass frame
1 x Hobbyking multi-rotor controller V3.0
1 x QBrain 4 x 25amp brushless ESC
4 x Turnigy 1000kv D2830-11 brushless motors
1 pack of 4 10×4.5 slow fly props clockwise
1 pack of 4 10×4.5 slow fly props counter clockwise
It all arrived, so I built up the frame putting a drop of thread lock on each of the screws, and attached the 4 motors to the end of each arm, again with thread lock. I connected each motor to the speed controller, and just to check everything worked plugged it into the controller board and receiver and powered up… Nothing happened… So I thought I’d better read the instructions. First the speed controller required calibrating to the radio, setting the top and bottom of the throttle throw. So I did this. The instructions for the hobbyking controller board were ‘sparse’ to say the least, I eventually found by trial and error that setting the throttle to lowest and the rudder full left seemed to initialise the controller board, then every thing sprang to life. I now know this is ‘disarming’ the nav board… As opposed to arming which is done by moving the rudder to the right. Still none the wiser as to what that is if anyone knows?
Of course the first thing I had to sort now was the order of the motors, this was actually in the hobbyking instructions, but the firmware which shipped with the board was for a quad with a motor in front, behind, left and right. I wanted an ‘X’ configuration with a motor front-right, front-left, back-right and back-left. Fortunately I had a USBasp connector to update the firmware on the board, so when I eventually found the firmware update utility I update this to the X configuration from the hobbyking site, change the order of each motor to its connection on the controller board, powered up, put in left rudder to start the board and then a little throttle. This time all the motors appeared to start, and adding aileron and elevator appeared to speed up and slow down the motors as I would expect. All is going well, next was to check the motors are all spinning in the correct direction and with a helpful little image in the instructions this wasn’t too much of an issue by placing a finger on the side of the motor case to see which way my finger was pushed, then reversing 2 wires if it was spinning the wrong way.
So next is attaching all the bits to the frame. Reading advice from other copter builders all seem to say that the controller board needs to be damped from vibration, my setup with the single ESC would seem to be advantageous in this situation since I could attach the controller board to the top of the ESC case using foam tape, then the ESC to the frame using foam tape the weight of the ESC should then help to damp the controller board from the vibrations in the frame. Although the heat management may be affected by attaching this to the ESC. We shall find out the effect soon anyway.
So after tidying up all the cables and tying them down this is what my copter looks like:
At this point I got a little cocky and decided to spin it up with the props attached to see if it will shuffle around the floor in the correct directions, yaw the right way, etc. So I put a little bit of throttle on, not enough to take off, but enough to start taking the weight, then just touched the rudder slightly and the copter launched and smashed into the TV. After I extracted it, I removed all the props again (replaced the broken ones) and turned all the giros to minimum, and reduced the rates on my transmitter to 50% (with the dual rates switch set so I can increase this if needed) and put some expo in too. Strangely the pots on the board seem to need to be turned clockwise to reduce the rates. Turning them this way gave the lowest change in motor speeds for any given input, this way seemed a little counter intuitive to me. But I now felt confident again and being even more careful now I put the props back on and tried again, this time success, although there is a lot of effect from the walls and floor generally it seemed to shuffle in the way I expected.
All put together, this is now how it all looks:
I still need to put a bit of tape on the receiver antennas, but next stop… a field test.
At the field we noticed that the single cable that I’d seen used elsewhere actually cross connected the Ailerons and Elevators, although we had set everything up so that the motors were working correctly of course the controller board didn’t have the motors set up correctly, so the first test flight was extremely unstable, the giros sending the copter more and more out of control. This was corrected, we then needed to add a significant amount of trim on various axis, but after this the copter took off and was controllable, but still a little wobbly. We turned up the gain on the giros on the controller board, this improved stability, this is the resulting flight by Mr Scott:
I then flew a little higher and further, caught a bit of wind which started it swaying, because it was a bit further away it was difficult to tell which way it was swaying. I should have simply left it to the giros to sort itself out, but instead I lost my cool and knocked the power down which then made things worse and ultimately led to it crashing
But I do take a lot of positives from the days testing. We managed to get some genuine flying time, the copter performed well and we did get a lot of information that we can take forwards and improve them and do better next time. And Scott managed to do all this without smashing his up which is even more of a plus so he can take it forwards without too much work.
Good fun… needs a bit of work 🙂
I mounted the FPV and OSD removed from the catalina when I updated to the Ardupilot, the following was flown Line Of Site, but recorded from the Ground Station
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:
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):
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:
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.
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.