This is the lightest, most robust FPV setup for acro quads, that I can come up with. Photos show it on a WarpQuad 200, but the system can fit any Acro quad with a 30x30 centre mounting point. The Mobius mount has been described in a previous post, this describes how the FPV camera and VTx is mounted:
Flat polycarbonate top plate, replaces standard top plate on the quad. Should ideally be made from carbon fibre, I'm only using 2-3mm polycarbonate because it's easier for me to work with. Top plate extends a tiny bit ahead of the front point of the camera lens for protection, EPP foam offcut under the camera to set the preferred angle - keeps it stable and provides shock absorption.
VTx module is mounted flat with antenna coming out flat backwards. I have a square hole completely through the polycarbonate that neatly fits the metal can side of the module. Tiny bit of hot melt glue on the corners to keep it retained and two small cable ties for good measure. This keeps the VTx square in the polycarbonate, allows some 'give' in a crash, and allows heaps of airflow top and bottom, keeping it cool.
With a flat mounted VTx and straight antenna connector there is less leverage on the antenna point in a crash. The antenna coax can be bent up or down as needed, flexes on landing or crashing. A right angle antenna could be used instead. This increases vulnerability in a crash, but keeps the antenna vertical. Trade off is crash resistance vs range. Antennas with plastic...Continue Reading
With this little 15g carbon fibre mounting solution, it's easy to attach a Mobius to a high performance X-frame quad like my WarpQuad. AUW including the Mobius is 60g.
Getting smooth video is now easy as attaching a battery!
The mounting solution consists of two thin CF plates that 'sandwich' the Mobius in front of the battery. The Mobius is set a little bit back from the very front edge of the top and bottom plates, and holes are drilled in the bottom plate to reach the controls and see the LEDs. The image needs to be inverted in the Mobius setup.
Velcro on top and bottom of the battery and the mobius mates up with velcro inside the plates, and velcro on the outside top and bottom of the sandwich allows mounting the whole assembly to the frame as if it was 'just a big battery'.
It doesn't seem to get any jello because the non-rigid velcro mounting of the 'sanwich' to the frame provides a bit of free play, and the mass of the battery provides inertia. Together these factors block the high frequency vibrations that cause jello.
Props don't appear in the video as they are too high (unless you choose a wide angle setting on the Mobius).
The low mounting location doesn't affect balance of the quad, and most high performance acro quads can easily carry another 60g when you want to get video.
In a bad crash, the whole assembly flies off the quad and the carbon fibre plates protect the Mobius and the battery. The Mobius is very well protected. And it is so easy to attach and remove.
The original was made from 4k carbon fibre, the top plate from 1mm and the bottom 0.5mm sheet. It could be made from just about anything.
Hope you like the idea and enjoy collecting some great videos! :-=)
Here's video simultaneously collected from a head mounted GoPro and the mobius under a WarpQuad 270:
But… have you ever noticed that if you try to push forward at a significant angle, Horizon mode becomes unstable and almost uncontrollable?
One moment it is angled forward nicely, but with just a tiny bit more forward stick, it starts to pitch quickly forward into the dirt. If you pull back just a little, it then lifts up more than you'd like? It becomes very difficult to fly forward at high angles, or do steeply angled horizontal circles, for example. It just becomes too unstable.
This high-stick-angle instability is inherent in the current MultiWii 2.4 implementation of Horizon mode code, and it's been like this for some time.
This is why. When the stick angle gets to the point that Acro behaviour dominates the levelling tendency, the quad starts to pitch at ever increasing angles, forcing you to pull back. With typical rate settings for flips, the instability makes it very difficult to fly.
The code changes I’ve made seem to make things much better. The new code includes both the angle of the quad itself and he angle of the sticks - both work together to smoothly reduce the levelling. This has a number of benefits. The transition to acro is smoother and starts sooner (at lower stick angles). At higher stick angles, the quad flies smoothly and with greater control. At very high angles, even past or over vertical, up to nearly fully inverted, control is retained with that classic Horizon feel. You can do...Continue Reading
Posted by ctzsnooze |
Mar 02, 2015 @ 10:22 PM | 1,885 Views
Have you ever 'reset' your flight controller in the GUI? If so, you get the default values stored in the EEPROM file. This can be useful if you think that you've stuffed something up. The downside is that you will lose your switch settings and must remember to restore them.
Wouldn't it be great to store your working PID settings and switch values in your sketch, so the whole lot can be restored anytime?
One way is to archive your original sketch, and then customise the EEPROM.cpp file in your working sketch with your current optimised PIDs and switch settings.
Doing the PIDs is easy. There are obvious places to write them. Storing default switch positions is more difficult.
Both go in EEPROM.cpp, so open it in Arduino, and scroll down to the section where the PIDs are stored.
Edit the PID values and your favourite RC rate and expo values; it's fairly obvious where, I use PID controller 1 so change the lines under #if PID_CONTROLLER == 1 to your preferred values.
To set your default RC rate to 1.40, RC expo to .5, RollPitch Rate to 0.65, Yaw rate to 0.4 and TPA to 013, edit the following lines so they look like this:
conf.rcRate8 = 140; conf.rcExpo8 = 50; // general flying near centre
conf.rollPitchRate = 65; // flip rate
conf.yawRate = 40; // yaw rate
conf.dynThrPID = 13;
The above values are my favourites for most of my acro style quads! :-)
Posted by ctzsnooze |
Mar 02, 2015 @ 10:06 PM | 1,753 Views
For MotoWii owners, its not too difficult to use the VBAT code show in my other blog posts to make FET driven LED's on your WarpQuad flash when the battery gets low.
The LED's need to be driven from a FET as per the circuits in my earlier blog posts, with the gate of the FET connecting to the normal LED high side. I use the simple code.
This post shows how to add LED's, where to put the voltage divider and the FET. Look closely at how I soldered two SMD resistors to make the voltage divider, then joined them to pin A3 on the CPU. Soldering the fine wire to the CPU is difficult, the wire must be very fine, and you need a lot of flux paste. Take care!
If your voltage divider is 22k to 4.7k (positive to negative), then the following values in config.h will get your LED's flashing around 3.5V, accurately and reliably:
#define VBAT // uncomment this line to activate the vbat code
#define VBATSCALE 57 // (*) (**) change this value if readed Battery voltage is different than real voltage
#define VBATNOMINAL 13 // 12,6V full battery nominal voltage - only used for lcd.telemetry
#define VBATLEVEL_WARN1 105 // (*) (**) 10,7V
#define VBATLEVEL_WARN2 102 // (*) (**) 9.9V
#define VBATLEVEL_CRIT 100 // (*) (**) 9.3V - critical condition: if vbat ever goes below this value, permanent alarm is triggered
#define NO_VBAT 4 // Avoid beeping without any battery
Posted by ctzsnooze |
Mar 02, 2015 @ 09:28 PM | 1,822 Views
If you enable one of my VBat monitoring techniques for the AlienWii brushed flight controller, and probably for most other 1S Atmel 32U8 based flight controllers, these values in config.h should get the LED flashing WARN1 at around 3.5 V:
#define VBATSCALE 55 // (*) (**) change this value if readed Battery voltage is different than real voltage
#define VBATNOMINAL 42 // 4.2V full battery nominal voltage - only used for lcd.telemetry
#define VBATLEVEL_WARN1 36 // 3.6V - low priority alrm
#define VBATLEVEL_WARN2 34 // 3.4V - medium alarm
#define VBATLEVEL_CRIT 32 // 3.2V - critical alarm; all are transient
#define NO_VBAT 16 // Avoid beeping without any battery
#define VBAT_OFFSET 0 // offset in 0.1Volts, gets added to voltage value - useful for zener diodes
After each flight, check the residual cell voltage (which will be higher than the set-point, from recovery of the battery), and also check how much capacity goes back in. To fine-tune the alarm point, adjust the VBATSCALE value up or down by 1-2 steps at a time, then go fly - for example, if it alarms too soon, drop VBATSCALE by say 2. After a while you'll have it flashing at just the...Continue Reading
Posted by ctzsnooze |
Feb 16, 2015 @ 05:39 AM | 2,470 Views
If you're an Orange Tx module user and having intermittent drop-outs, open it up and check the soldering on the two pins near the Antenna socket. These are used to connect the two boards together at video ground level. Pressure on the socket can push in on them, cracking the solder. See the attached photo. If they fail completely, just run a flexible wire in parallel and epoxy them solid.
Posted by ctzsnooze |
Feb 13, 2015 @ 02:38 AM | 2,031 Views
Thanks to Goebish I found a simpler way to make the LED flash when the battery is low. I don't know the originator of this code, but it works very well.
My more complex code provides three levels of warning, but requires more complex changes in the Alarms.cpp code, as well as code changes in def.h to swap the buzzer pin and the LED pin. It's an elegant solution, but a bit complex than this one.
This works with just about any MultiWii code and the only hardware requirement is that the battery voltage (not more than 5V, so a divider is needed for 2S or bigger) is presented to an analog input on the CPU (typically A3). Some boards have this by default, others you have to hardwire it yourself.
This code just flashes the LED when the battery is below Warn1 level. It does not provide different flashing patterns for different voltage level. Only one part of the MultiWii.cpp code requires modification. The flashing is a bit random - what actually happens is that the LED starts transiently blinking out under punch-outs. When the battery voltage is consistently below the set-point, the LED will mostly be off with regular flashes on.
Typically I would set it to alarm around 3.4V, and land as soon as possible after it started flashing while in level flight. You should bench calibrate it so you know the exact voltage at which it starts flashing before relying on it.
You'll only have to uncomment #define VBAT, set a suitable VBATLEVEL_WARN1 level for your battery...Continue Reading
Posted by ctzsnooze |
Feb 02, 2015 @ 07:22 PM | 2,413 Views
Many clear polycarbonate quad frames for 1S battery micro quads include special holes for mounting LEDs that 'glow' from within the frame.
Each LED should have its own resistor. The resistors suggested here are suitable for 1S batteries ONLY and allow about 20mA per LED; exact values are not critical. Blue LEDs need lower resistors (say 22 Ohm) because they have a higher forward voltage requirement than Red LEDs (68 Ohm resistors). I'm not sure exactly what would be best for green or yellow LEDs - try and find out!
The LEDs and resistors can be made to fit neatly into the tiniest of frames.
I attach a circuit diagram and some photos of how I've done this with a polycarbonate cross-X frame. Push the LEDs into the frame and curl their legs neatly around. Solder carefully. You have to identify which leg of the LED is positive and which is negative BEFORE fitting them in the frame. Don't bend the legs hard or they snap. Join the two positive legs of pair of LED's towards the centre - as I have in the photo - the negative legs should go to the sides. Then using insulated wire, connect the front and back positive legs to each other (front to back with a red wire) and similarly join the two negative sides to each other with a black wire. Then your leads providing power from the frame can be soldered red to red and black to black so as to end up with a circuit as per the diagram. Test with a spare battery before wiring up to the frame.
In Arduino there are three main places where changes are needed:
1) config.h - enabling buzzer and bat monitoring.
2) def.h - sending the buzzer port to the LED port.
3) alarms.cpp - changing the default flashing behaviour for low battery messages (optional but recommended).
Quite a few changes are needed. I strongly suggest backing up your starting sketch and checking compile at each step. If you don't understand what I say below, and are not familiar with sketch editing, please don't attempt this change.
Here are the details:
1) in config.h we must enable the basic things
- uncomment define #BUZZER
(we intend to use the buzzer system to drive the LED, so it must be enabled)
- uncomment #define D8BUZZER
(the AlienWIi sketch uses the ‘normal’ buzzer pin for the Sat connection, uncommenting D8 buzzer allows you to enable the buzzer but assign it to a different pin so that the Sat keeps working)