Raspberyy PI Quadcopter For Arduino Quadcopter see here
Hardware consists of:
Raspberry PI 2 B v1.1
OS: Currently standard Raspbian, will upgrade when RT Kernel is stable
£120 Navio Board - Invensense 9250 MPU, MS5611 Barometer, U-blox NEO-7M GPS unit, PCA9685 PWM Generator (and other stuff, full specs can be seen here - Emlid)
£60 4x 30 amp Afro simonk compatible esc's reprogrammed to work forwards and backwards with fixed calibration.
£45 4x (280W) 2200KV 53g A2212-6T Motors from brchobbies.co.uk
£20 4x 8x4.5 Auro=naut CAM Carbon Light (+spares not included in price)
£20 5500mah 3S(11.1V) Lipo
£20 Hobbyking x525 frame
£12 Pinguino micro (PWM->Digital transmission to PI, simple unidirectional variable rate method using 4 pins+ground)
£70 Flysky 6 channel radio system (got 4x receiver tho so not only used for this quad, also did a Lipo conversion)
£5 GT Power Voltage and current meter (handy thing, 5v-25v, 0-30A)
12/03/2016
Ho hum, wainting for daylight and weather to get better so I can test things with a little space (and many obstacle's).
In the meantime been playing with a few things, got a particle photon and tested potential data rates on the 120mhz cpu, with 4 data pins it maxed out at 120k bytes per second
Ran some indoor tests on the test ahrs, made a routine that corrected the pitch and roll based on the magnetic inclination of the Earths magnetic field.
Current plan is to get the DMP version back where it was and see if I can improve it, perhaps I was a bit quick at disregarding it as a possible option. (tho admittedly not given the new program much real testing, mostly due to weather there's only so much you can do holding the quad in your hand)
8/01/2015
Looks to me like there are 3 levels of seperate Bias/scale calculations that need to be estimated for a dead reckoning system.
Level 1 is hardware bias, easily (for the most part:see note) removed by recording the average gravity value with the IMU stationary and gravity as close as possible to being along each axis in the positive and negative directions. (If its stationary then )
Level 2 is down to external influances on the chip (temperature/voltage/interference) and much more difficult remove.
Level 3 Software inaccuracies. If the gravity value isnt quite correct then removing it wont result in good acceleration values. Also tricky to make sure it's right
Level 2 and 3 are only possible to improve by using other sensors.
Some psuedo code for one axis for Level 1 is as follows...
// this code is for one axis, say z so positive and negative are the 2 opposite readings where the z values are maximised (in the case of my quad upright and upside-down)
// assumes the scale is -1 or +1 for gravity
datalengthpositive = sqrt(xpositive*xpositive+ypositive*ypositive+zpositive*zpositive) // normalise the positive reading
nxpositive = xpositive/datalengthpositive
nypositive = ypositive/datalengthpositive
nzpositive = zpositive/datalengthpositive
datalengthnegative = sqrt(xnegative*xnegative+ynegative*ynegative+znegative*znegative) // normalise the negative reading
nxnegative = xnegative/datalengthpositive
nynegative = ynegative/datalengthpositive
nznegative = znegative/datalengthpositive
// now we can calculate bias values based on the normalised values
bxpositive = nxpositive-xpositive
bypositive = nypositive-ypositive
bzpositive = nzpositive-zpositive
// as we are calculating the z axis bias average the 2 values, to calculate the other axis' you need to repeat the code but use the different readings and average the bias of the axis you want
averagezbias = (bzpositive+bznegative)/2
zscale = 1/(zpositive+averagezbias)
now you can calculate the zacceleration with zadjusted = (zvalue+averagezbias)*zscale
Note: The sensors might not be aligned perfectly at 90 degrees to each other, this can result in a corelation (apparently) aka rotating on the x axis alone could result in a small y axis rotation too
2/1/2016
Checking a few possibilities, the pi is sampling the pinguino cycle pin 6 million times a second if I remove the sleep (has some potential for data transfer especially if I use the DE0 nano at some point)
Tried the other 2 6050 imu's, looks like same offsets (bought them together so probably same batch). Maybe orienting them differently and using all 3 could do something but for now think I'll not.
Added my little test AHRS class to github: github code
31/12/2015
A few other changes I dont seem to have mentioned, I managed to clamp the navio board onto the pi with the 60 degree C mouldable plastic turned out it was easier than I expected, didnt have to make any new hole's in the box that contains them all (the screws are accessible when both boards are locked together)
Been running some tests on the pinguino comms program, seems it maxes out at around 34k bytes per second (lower than I expected, but should be ok. the pi can keep up with that easily).
Also ran some tests with a 6050 connected to an arduino, managed to get the i2c bus to run fine at 1mhz which means I should be able to read an imu on the arduno at 1khz and have 50% of the cpu power still available.
Just tested a 3rd imu (or technically 5th one I've played with), the z axis was offset by a big 0.25G not seen that before, I've either been lucky on IMU's or it's normal to have offsets like that. Guess I should solder up and test the other 2 6050's.
30/12/2015
Lots of changes... Got a new computer so spent a while transferring everything accross.
I Managed to get the quad to sporadically hover in place completely statically but only sporadically and only for a few seconds. Thought that was interesting, so I looked into the DMP data and it seemd to be changing attitude slightly every few seconds even when stationary. So decided to write a version of the program that used the raw data.
Ran a few flight tests with the new code, still adjusting the PID values and the weather has been pretty bad for it lately.
Been also side running a test class based on data from the quad when held in my hand (turning it round or leaving it flat in different orientations), the barometer is a bit noisy (around +-1.5 meters). The IMU is pretty good, but there's some offsets that seem to need to be accounted for, if I rotate the accelerometer data to the original position of the quad based on the sensors (and my code) then there is a significant velocity offset. Even when I post calculate a best case accelerometer bias (the scale seems to be being influenced by the movements more so is a bit more tricky).
Its pretty close with the post processing...
The 2 numbers at the top are the scale of the image and length of the data (all length's will be the same as its the same log file) values are x-y-z
Recorded Acceleration:
Calculated attitude (mostly from gyros)
Calculated Acceleration (based on origin). See the offsets from 0 between the movements :( (if you look at the images in full resolution)
Estimated Velocity (the quad was held almost stationary apart from attitude adjustments and motors unpowered, but if the code was incorrect the values would be much worse)
Post process bias's are:
bax 0.0053013610839843751G
bay -0.013683898925781259G
baz -0.015343297958374027G
02/11/2015
Some more testing on the PID, made some logs and calculated the average angular offset. It didnt seem to be reaching low numbers very much and there was an obvious offset to one side (probably due to the centre of mass not being completely central), adjusted the PID a little and managed to improve it with the result it showed the IMU wasnt calibrated well enough (created a largish consistent drift to the left even tho the angular offset suggested it was pretty good), adjusted the calibration a little and had a good result. Needs more improvement tho.
Ran some tests on the GPS seems one antenna has issues with the connector, another works but has a short cable :( (might be able to get the antenna working if I reorient the way its connected to the socket). Also looking at the ucenter data to see if it's doable to use the GPS to automatically counter the drift from the IMU. When completely stationary the GPS seems to have a low drift speed around 20cm/s and a maximum deviation of about 8 meters, wind will cause issues but can calibrate it on a windless day.
Still got issues with the Navio board not being clamped to the PI very well, I'm planning on making a pair of mouldable plastic clamps to go on the sides it should hold it in place.
25/10/2015
Found some issues with the PID, I term was being incorrectly calculated (stupid type conversion wasnt converting from unsigned long long to double correctly, surprised I hadnt noticed that before)
10/09/2015
More testing on the Accelerometer, looking good :) Just needs some fine tuning. I removed the barometer code for now, will tune the accelerometer better then add a lower power version of the barometer code.
Intermittent wobble is still there and can be quite bad at times, need to sort that one out I have some clues as to the cause, will need more data. (disabled the gps reading to see if that affects it - spi bus wasnt being locked correctly)
08/09/2015
Had some promising tests with using the barometer to stabilise, but ultimately it's not doing what I want it to. So thought I'd have another look at improving the accelerometer data, it was very very noisy so created a variable with a weighted average and ran some tests. Looking a lot more promising than the barometer tests were doing, just after one attempt its a tad jittery and difficult to gain height (might be due to the barometer code), but it seems to be holding height significantly better.
Also attempting to improve the prop balance, 3 props seem fine, 1 is a little problematic.
Random spikes seem to be gone, will need to look into why the radio data isnt transferring correctly (maybe add a checksum byte or something)
07/08/2015
Ran more tests and doing some logging, looks like it was the transmitter data causing the random spikes, will look into that in more detail later.
Logs show the barometer is working as I expected, however it is going to need something more to get it steady so been looking at getting horizontal and vertical accuracies from the gps (the gps data is next to useless without that). Also been doing improvements to the vertical speed algorithm.
03/08/2015
Had some marginal success improving the height stabilisation, added an I term and changed the pitch/yaw throttle compensation to use 1/cos(angle) I spotted the previous calculation was completely wrong (that alone seems to be a big improvement when moving). Could possibly do with using the GPS height too at some point.
Currently goes into a slight wobble phase for a second or 2 but then corrects itself sometimes during flight, not sure if its just PID adjustments or the props need better balancing (will probably improve the prop balance anyway at some point)
Been trying to find the cause of the random spikes, managed to get some log data out that looked interesting. I saw all 4 motors were being increased or reduced significantly for 1 frame every few mins. I was also recording the throttle at the time and the large up spike also co-responded to a strange throttle value (163%!), I guess the down spike could co-respond to a random value in the upside-down switch value so I've added a sanity check to the pinguino comms (on the pi) and as its fairly rare made it drop the datapacket 1 packet in 2 or 3 mins should be fine. (its got a radio loss detection program in it and if there is no data from the radio for period of time it goes into an emergency landing mode, probably needs more work done but should be safer than just dropping out of the sky)
31/07/2015
After a little break...
Invertible props are a no go, the APC props are more efficient even upside-down so been working on improving the height stabilisation. The barometer assist doesnt "seem" to be doing a lot to help so currently ramping that up (damn recharge times). I've also added a weighted average to the barometer pressure as it was very jittery (+- 1.5 meters), this introduces lag but improves accuracy (down to +-15cms).
14/05/2015
After some inverted tests, I found the Yaw wasnt correct and the pitch was inverted. Fixed the yaw and pitch (just sign). It does seem tho that the APC props have been damaged (there's a couple of small nicks in them and the ends dont seem right)
So thought I'd try the invertible props before rebalancing a new set of APC props, I'm not sure but the invertible props seem to be a lot less efficient upright than I expected. More tests needed and I need to balance them out better.
On the Plus side, when I was using the APC props I had a few nice lift offs upside down. It looked like it was stabilising correctly :)
I have a spare set of APC props so if the invertible ones dont work out well I can use them.
19/04/2015
17/04/2015
After some issues with it the Pinguino micro seems to be functioning fine. CPU usage on the PI is currently at between 8-12% of one core @ 50hz update. (the digital transmission is at between 4-6%). The raspberry pi is outperforming the Pinguino hugely tho, >100000 samples of the port per second for just ~8000 bits transferred (and the PI is going into a sleep state quite a lot, CPU usage indicates about 95% of the time). I can probably optimize the Pinguino a bit more, but not sure its worth it atm.
Inverting the height stabilisation appears to have worked, must have been incorrect. Throttle less sensitive, oscillation still there but seems more controllable.
11/04/2015
Found an interesting board that I'm planning on replacing the nano with, its called a pinguino, runs at 3.3v but has 4 5.5v tolerant pins (I'll use those for the radio+2 others level converted). The CPU is 5x faster than the nano which should increase PWM precision as well as speed up the communication to the PI (which will reduce the CPU usage on the PI) and as the pins are 3.3v I can connect them directly instead of needing voltage level conversion.
I also inverted the height stabilisation, while the effect of increasing that seemed to be reducing the oscillation, it should not have been increasing sensitivity of the throttle. So going to run some tests with it inverted. Also logging the barometer and accelerometer data so I can check.
09/04/2015
Some more fairly good flights, been altering the height stabilisation some slight improvements. Noticed the throttle seems to be very sensitive tho, even with the x^3 throttle curve, so might be something incorrect there (might have been a calibration issue which I've improved but not tested).
Adjusted the D calculations to remove control kick and allow updates to run at a different frequency, tested that still works at 50hz. Also Altered the I calculations but not tested yet.
Removing the control kick improved the stability, still an issue somewhere it still has a fast but shallow wobble from time to time. (might just be down to motor & prop balancing, I haven't really balanced them at higher power levels fully and I've seen at least one prop adapter go wobbly a couple of times)
Yaw seems to be working, but that might be because I zero'd the I term. It stays pointed in the correct direction, but is a little slow to correct need to increase the P Term.
07/04/2015
Another good test flight today, wobbling reduced but still not gone. Above head height again (about 60% max on the throttle, works out as ~41% of motor power when taking into account the x^3 throttle curve and the hoverspeed reduction)
Vertical oscillation has been reduced a bit, still just using the accelerometer and not set up as a PID atm, there's no I or D terms so its only reducing acceleration. I have an I term I can use based on accumulating the accelerometer and combining a speed estimate from the barometer - I dont trust the accelerometer alone to be totally accurate. I think if the quad was moving vertically at a constant speed the accelerometer would show no acceleration (because the speed is constant) so integrating the accelerometer alone would result in drift (due to inaccuracies).
Fairly certain I've found the issue with the Yaw, the P term was negative (and should be because the value is backwards compared to the output) however the I term was positive, this resulted in an incorrect accumulation of the I term until it reached its coded limit (that's why the constraints are there :p), the P term was counteracting it so it was offset by around 45 degrees.
Added another pin output from the arduino input to the pi using resistors to lower the voltage, was hoping it would let me reduce CPU power by improving the link between the arduino+pi but it seems I had fairly accurate timing without it so just down to 7.2% I can now add another data pin from the arduino if I like which should halve the CPU usage on the PI in theory (I could also take it up to 8 data pins which would reduce CPU usage by a factor of 8 by this particular part of the program).
03/04/2015
Managed to tune the PID mostly, the wobbling is 95% gone, still a slight one if I try to rapidly adjust the controls/height.
There's a large up/down oscillation(height) while in the ground effect but this seems to be fine once out of it (managed to get it up above head height for the first time with the PI 2 and new motors today). Slowly adding more power to the height stabilisation (based on the accelerometer only at the moment, I have added some code to use the barometer but testing one thing at a time).
27/03/2015
Hmm, so much out there on the internet that is slightly incorrect. PID=Proportional, integral, derivative. P has a direct correlation to the error and simply scales with that. I is the integral that accumulates based on the error. D is the derivative is the rate of change of the error. P simply says if the error is big then we need to do a big correction or small for a small one. I says how long has the error been around if longer then bigger correction or shorter then smaller one. D says is the error increasing if so increase the correction or if the error is reducing then reduce the correction. stupid me trying to use negative D values :p (I made a simple mathematical PID simulator and tested some values in it)
Also removed some legacy stuff (from the arduino) and added some changes to make the I and D terms simpler to understand.
I noticed the P term is dependant on the throttle, higher throttle=lower P term is stable so going to work out a scaler
25/03/2015
Made the program log the sensor data to a csv and managed to graph some of the values to see what is happening.
First image, one from excel showing the 3 raw gyro values (1-x,2-y,3-z)
Second one White is final output power on the front-back axis, green is stabilisation power and blue is gyro. Scales arent the same for each (graph is from a c# program I made to simulate the PID based on the sensor values, sort of like a playback)
In the second image it looks like the gyro's are the cause of the issue. There's a couple of ways to try to fix this, going to see if a light filter will work.
Also after running the sim I noticed in some cases the throttle wasnt getting as high as I thought before it left the ground, this meant the I term wasn't accumulating during some liftoffs, so reduced the value. (in the second graph it wasnt accumulating at all) Probably because of the change I made to the throttle. Also after playing around with different I values in the sim its not affecting it as much as I expected (although the graph is only 12 seconds long) so I'll probably increase the I term.
21/03/2015
More testing today, some better results
One of the power spider connections had come loose so took that apart and resoldered it (should be better now)
As a test I increased the D on the stability PID, this had a positive effect so kept increasing it. Was originally -0.05 is now up to -0.90, at -1.0 it will basically result in no stabilisation and is having an effect on the controls too. But it seems to have reduced the wobbling a large amount. Going to have to think about why exactly that's happening, its possible some adjustments to the rate D will improve it (although the rate PID seems to function close to perfectly with the stability disabled)
Yaw was behaving in a manor that's explainable, I saw a few times it going left then right then left again etc., just needs some PID modification (the D and I yaw values were zero'd). the centre of the oscillation was about correct
Still gets crazy wobbles when I take it more than 10cm off the ground, but managed to keep it in the air for longer and had enough control over it, also much less random drifting.
Also notice a nut got loose that was holding the PI down, might have an effect on why it needed recalibration. I'll locktite them down once I know its working
When zero'ing the throttle when in the air I've noticed the quad tilts a few degrees, this is likely due to not synchronising the PWM output (sort of akin to turning off vsync on your display) a rapid reduction in power can have an effect of the motor reduction being 50th of a second late. I might up to 100hz again at some point, but I want it to cope at multiple frequencies. (100hz barely has an effect on CPU power, the biggest usage atm is GPS (around 3-4% and the digital input from the arduino at around 8% which are possible to reduce)
19/03/2015
Did some lift off tests, very unstable and moving at random (with a slight bias towards backwards). If I gained any height it would become completely unstable and have to land. I did manage to keep it a few cm off the ground for 3 seconds, but required a big adjustment on the controls.
Increased the stabilisation I term (I'd zero'd that to make sure it didnt have an effect on getting the P/D correct - someone remind me next time to not reduce/zero things :p). Increased Rate D as well (hand tests showed it was wobbling a bit when moving it fast with rate only enabled). Also increased stabilisation D, the values are now identical to how they were previously (apart from I).
I noticed one of the motors had a definite balance issue (the prop adapter was visibly vibrating at slightly under hover speed) so rebalanced it (I also rotated the prop a little which seemed to help. It was previously hitting an RMS of 16+ now down to 3). Will probably go over them again. The sum of the 3 axis' gyro's RMS for 2 of the motors is at around 3 degrees/s and less for the other 2 (at 1460+150 PWM, that's also individually not sure what the RMS is combined).
Going to go back and check some fundemental stuff, the vibration doesnt feel that bad when held
17/03/2015
Lots more testing, found a few problems.
I went through some unit's and found the rate PID was constrained to a max of 58 degrees/s (this affects the acceleration but not the maximum rate of rotation). Also with the new motors double the power of the old ones it meant it was putting out more power at 58 degrees than with the old ones, so I've adjusted the code to take into account the hover power. This reduced the power going out at 58 degrees to 75% (75% makes sense because with the same calculation with the old motors would have meant an increase of 25% so it should scale with the motor power). I had reduced the constraints when moving over to the new motors so going to increase those (was done as a precautionary measure which may have caused more issue's than it resolved :p)
Also due to the extra vibration I am going to reduce the power on the rate PID if needed but increase the constraint (this means the maximum power is higher, but overall it will put out less power which will reduce rotational acceleration and possibly stability)
2nd problem is simple the Navio board I think isnt seated perfectly, I need to clip the display connector a little more :p it moves now and then and I have to keep recalibrating.
3rd problem, yaw is misbehaving. sometimes when attempting lift off it starts to randomly rotate left or right (currently not using the magnetometer) its probably something simple to do with the angular subtraction routine I added.
Solved problem, the pitch/roll stabilisation PID is likely fine using the same values as the previous motors.
I also did a little test to make sure I can grab a picture from the USB camera I have. Had to add some uvc driver
10/03/2015
Managed to reduce the wobbling in the stabilisation PID, it's still wobbling when I try fast(ish) movements, but I'm pretty certain I can remove that. I'm probably going to go back to the rate PID and increase the power (and adjust other values so it doesnt wobble). I had reduced a bunch of power levels as the new motors are more powerful and wanted to be careful.
Found some formulea to apply to the barometer to calculate the height, added them to the program. The barometer seems a little jittery so also added a filter to try to improve that. Will add the accelerometer gravity to the data at some point.
8/03/2015
After some more testing, realised its not actually a vibration issue, just needs to be tuned correctly. Tuned it roughly and its looking much better :)
it was previously making a noise indicating the motors were increasing & decreasing very fast I assumed that was due to vibrations but my adjustments to the PID values has proved that wrong
Still some big wobbles with the stabilisation PID activated but rate PID is looking good (might need some power increases tho).
Throttle is currently set to max out at 74% which is twice the approximate lift off throttle (might need a small upward adjustment but tests show its close).
I'm fairly sure 74% is pretty good tho due to a small incident I had. I was calibrating the throttle and didnt realise it was armed, went to 100% it shot up in the air I immediately zero'd the throttle but it hit the ceiling and I caught it on the way back down. 1 broken prop(I have spares) and a hole in the ceiling the shape of the dome on a prop adapter :p (it looks like the ceiling is made of a layer of plaster with fibreboard behind, it went through the plaster and made a big indent in the wood. Could have been much worse)
Vibration wise, 1 motor is creating about 10x less vibrations than the others. probably a random co-incidence of prop/motor being a good match.
Weight with the PI 2 and different props+new motors seems to be around 1450gramms
05/03/2015
I have been having big vibration issues with the new motors, so in the meantime I've adapted the PPM port for use as a digital communication method instead of sort of analogue based on timing with the use of one gpio output to the arduino. Which has improved the accuracy of the transmitter and reduced the CPU usage. (the pi outputs a "clock" signal to the arduino via the gpio output pin, the arduino reacts to a change in the clock signal and outputs the next bit through the ppm port)
Also upgraded to a raspberry PI 2 its currently running at 15% of one core :p
I "might" have solved/improved the vibration issue, although the arduino quad used to work this way and I must have changed it for a reason but iirc it was at an early stage.
15/02/2015
New motors have arrived, soldered on connectors and fitted them to the quad. Decided to try a 2200kv motor @ 280 watts.
Performed some quick tests and did a rough balancing. Going to need to spend more time balancing these out correctly but looking ok. (one of the motors has a strangely behaving connector so might have to redo that one or it might need better insulating)
09/02/2015
Ran some tests on a new motor (2200kv 190 watts) with both the 8x3.8 props and the 8x4.5 bidirectional props. Max's out at around 75% throttle (the 4.5's slightly lower, more like 70%) with around 15 amps and a hot metal smell. So going to test a 280 watt 2200kv version.
01/02/2015
Weighed the quadcopter, turns out to be 1541 grams, removed the USB battery and fed the BEC power round to the USB port by customizing a USB power cable. That reduced the weight down to 1464grams.
Weighed the plastic lid of the container I'm using to protect the electronics, the lid alone comes to ~60grams.
Tested the new bidirectional props, they can barely get off the ground at full power but the current is also low.
So going to buy and test a couple of motors to improve it's power (I did buy 30 AMP ESC's, I bought the EMax motors because they were double the power of the Arduino ones and act as a stepping stone to even higher power motors).
In the meantime I seem to have introduced an issue with the yaw that needs fixing, and I can look at barometer/gps. Going to use the Aeronaut 8x4.5 props for now
I also figured out the cause of the hovering 2 cm off the ground, stupid cable tie was taking some weight :p
28/01/2015
With the props on upside down it wont take off when upright which shows that's the cause of the power loss.
Upside down, its sort of working, power is better but not stabilising correctly. I could watch the I term correcting, but when it got close to being correct it suddenly started wobbling. There are a few things I can try before leaving upside down for the acro mode only (moving the centre of mass closer to the plane of the props and reducing the stability power levels come to mind).
26/01/2015
Put on the 4.5 pitch props and adjusted the PID to handle them better (the wobble seemed to be amplified, I think that's reduced now). The new props improved the throttle range (lift off much closer to 50%) max current was 9.8 with it locked down. (the motors can apparently handle 16amps for 15 seconds, according to ecalc it'd probably cope with 9x4.5's at 13 amps per motor)
Did some testing upside down, it's looking like the efficiency loss from the props is too high :( So I ordered some 3d quad props (designed to run forwards and backwards) 8x4.5 there will be a loss of efficiency on upright flight, but can always swap the props over for a longer upright flight time. I might try turning the current props upside down to see if it really stabilises correctly when inverted. (might also work as a help to see if something else is causing the losses if I test upright flight too)
24/01/2015
A little test flight, still some wobbling which will probably be tuned out.
22/01/2015
Tested upside-down a little, seems to be stabilising correctly there is a strange offset tho, needs a bit more testing.
In order to avoid burning out the motors when transitioning (going from +50% to -50% has a large potential to draw a lot of current if done too fast) I've set the throttle to change over 1 second.
I might look into using motor reversing to counter loss of 1 prop. but thats a long shot, I'm sure it'd wobble badly, but if it keeps it upright(ish) then thats a good thing.
Motor centre doesnt seem to be correct, when configured in upside down mode with 0 throttle it seems to pulse, that needs sorting.
Upside down flight needs a significant increase in throttle
20/01/2015
I think I've got the terms sorted as much as I can in the limited space I'm using at the moment (adjusted stability P and reduced the I term). Still got a little drift but that can be accounted for by the accelerometer not being perfect as its not randomly drifting in different directions.
Still a bit of a wobble on it while close to the ground, which seems to smooth out at about a foot (getting perfect calibration in the low ground effect is tricky).
Going to need some outdoor tests if I get good weather for it (no rain, none or light wind and daylight)
Also added an upside-down link to the channel 5 switch, going to need some testing (the system self rights without this)
Of course I could use the other 2 channel space for arduino ultrasound sensors I've been looking at arm assembly lately
18/01/2015
Went back and checked the rate PID, increased P by a factor of 3, reduced D a little (turns out the sign was correct, negating it made it very unstable) which removed a large amount of the wobble (I was using the same values as pre DMP).
Checked the stability PID, added an I value, which seems to be coping with the offset centre of gravity. There's a random drift on liftoff, which either means I is too strong or P is too low (I think P is too low, controls are slugish, going to test some other values).
I also noticed a weird/interesting situation where it locks itself in position at around 2cm off the ground after lift off again, probably a ground effect thing. (its surprisingly stable when this happens)
16/01/2015
Before retesting the gravity, thought I'd go over the PID and see if a better I term would work. Ran some tests, not a lot of success, but discovered the D term was vastly lower than expected by a factor of 100. Spotted a difference between the arduino program and the PI one that accounts for that, but I might have used the wrong sign on the D term (which if true its assisting the PID and increasing instability as opposed to dampening it, more tests to run - I did kinda get to a point on the arduino quad where I thought "If it works, why fix it?")
14/01/2015
After lots of testing, changing PID values and other power levels, going to go back and recheck the centre of mass, there might be a yaw issue (which can be down to slightly different power/weights of the props/motors) which is affecting my ability to get a good centre of mass. I do remember from the arduino quad, this all took some time to perfect. Just a note, the PID is keeping the yaw correct, so thats a plus :) (and according to my own arduino quad blog, a good centre of mass makes a big difference)
I'll probably adjust the throttle curve, lift off seems to be at 66% (which due to the current throttle curve is 67.5% power or around 4.7 amps) and at 66% thats the higher end of the curve so there's a loss of precision, I might also adjust the arduino quad's throttle curve
Ordered some aero=naut CAMcarbon Light Electric Prop 8 x 4.5 but going to get it stabilising with the 8x3.8's first
12/01/2015
Added the GPS and Barometer reading, not using them yet. CPU usage went up to 50+% which I've now got back down to ~25%
Made it run at 100hz correctly
Screwed everything down and didnt kill the SD card this time :) (tho I have a spare, bought another EVO card)
Found the centre of gravity (approximately - I do it by copying the throttle directly to the motors with no stabilisation and just as it starts to lift off it will tilt, do this a couple of times, then adjusting the CoG accordingly and rinse and repeat until the tilt seems to randomly move with no discernible preference. Had a large lean to one side, which is the side I have a usb battery on so not a big surprise) and calibrated the accelerometer/gyros (may require some manual adjustment to perfect it, at least thats what I did with the arduino quad)
Attempted a couple of lift off's from the ground, it actually hovered at one point, about 2 cm's off the ground for about 3 seconds probably just random as the controls are way too sensitive, so scaled them down. Lift off seems to actually be closer to 4.5-5amps, probably about right, my calculations indicated I could add another 250 grams battery wise to make 6 amps/motor (minus the usb battery)
oh and I should mention I used the KKmulticopter programmer to program the ESC's using the arduino Linker :)
10/01/2015
Ran some test on the rate & pitch/roll/yaw stabilisation, managed to get that working (just signs/scales again).
Copied the magnetometer code over from the arduino. Reading the magnetometer needed to work differently, as the 9250 is on SPI. Also had to correct the initialisation, but the calculations are now identical and work exactly the same way they do on the arduino :) Got the +-10 degree wobble again and after looking at the raw mag data I think thats actually normal (and just needs to be averaged out)
I adjusted it to 100hz and its at ~83hz (I can reduce the sleep to make it hit 100hz its sleeping 9000us per cycle) with the magnetometer code in there too (I could optimize stuff, but get it all working first, it was hitting 95hz without the magnetometer code) CPU usage is 17%
08/01/2015
Found the cause of the sd card problem, tried to screw it all in again and killed the 4gb sd card (thats why I didnt put the sandisk one in :) ). After examining where its screwed in it seems there's a screw (with electrical tape over it) pushing the sdcard up so I guess it was putting too much pressure on it (even though I wasnt exactly tightening it up). So going to use a longer screw & nut and add foam padding under the PI (might even help with vibrations). Switched to the Sandisk card now. (as a side note, I'm sure I read you could drive over them with a truck and they'd survive oh well, guess I found a way to break them :p)
I had put in bad default values for the PPM channels, which explains why it was at 3.5amps when at 70% throttle (shame, was hoping I could put higher thrust props on)
Extended the DMP version of the program to handle PWM output and PPM input. Turns out that due to the way the PPM input works it was using 20% CPU power alone, I reduced the accuracy and now have the program running with a PID (not corrected the scales on it all yet tho). PID+PPM input+PWM output is at 10% of CPU power at 50hz, most of the CPU usage is down to the PPM input (just the IMU alone comes to 1.4%-1.6%, the 5% was with printf's displaying the data) So I can most likely up it to 100hz without an issue, 200hz apparently isnt good for the DMP but not tested it myself (results in noisy data, but if you are running at 200hz you might aswell use the raw data anyway).
Ported across an Accelerometer/Gyro Calibration routine (it uses the mpu library I ported across, so was fairly simple). Runs fine, will be handy when I can bring myself round to screwing it all down again :s
I also snipped down the display connector so the Navio board would fit better on the PI, think I knocked the green LED's transistor when cutting it down so thats not working now :( oh well, a small reduction in power usage :p
07/01/2015
Managed to get the DMP to function on the PI over SPI, code is available here Code. Uses less than 5% CPU usage at 50hz (needs to be linked to the Navio MPU9250 library)
06/01/2015
Just went through a balancing process using an RMS calculation from the gyros on the Navio board to gauge the improvements (spent a couple of hours trying to find a good smartphone app yesterday to test the vibration before I realised I might as well use the Navio board itself). Some improvements from balancing the motors without the props, now have a few pieces of tape stuck to the motors (I also removed the stickers that were on the motors). Replaced the inserts for the props with some better fitting ones from another set of props (made quite a difference, the ones that came with the props didnt fit the shaft well).
It starts to lift off at around 3.5 amps, however that doesnt correlate to 30% on the throttle (more like 50-60%), indicating that I could probably use higher pitch/larger props at some point but these should be fine for testing.
New SD card has arrived (sandisk ultra 16gb), but not using it yet going to stick with the 4gb one. It occurs to me the Samsung one could possibly have been a fake :( (which could explain why it died after 2 months, as it exceeded its true capacity maybe) so testing the sandisk one actually has 16gb capacity with h2testw (finished, no errors :) ).
Also ran some tests on the stabilisation (just pitch and roll at the moment, yaw should be relatively simple to add via the gyro's), all looking pretty encouraging, fiddled with signs (the controls were reversed and pitch stabilisation was backwards too) and a slight power level increase - I'm starting with it low to make sure its all correct. Its definitely levelling itself, even tho the PI isnt screwed down or accelerometer calibrated yet and I'll have to find the centre of gravity at some point.
30/12/2014
Turns out the Samsung Evo 32GB SD card had decided to stop working, so reinstalled to a spare and ordered a new one. Just finishing off the re-installation
28/12/2014
Woo, now my PI B+ seems to be dead, so that puts a dampener on things :(
25/12/2014
Ordered one of (175W) 1025KV 53g Hyperion Z2213-20 to see if it reduces the vibrations, The current motors are not too bad at my guesstimated hover speed but I dont think it'd work well at full power and probably not inverted (efficiency is lost when inverted due to the props so requires more power). If it works well, it might be worth replacing all 4 motors if not I'll have to find some other solution (smaller/lower pitch props for example but that will come with a power loss).
Another thought I've been mulling is using the arduino nano and a bunch of transistors to block the signal to the ESC's in the event of radio loss (the arduino quad basically works like that due to how its coded and its a handy feature while testing). But just a thought ;)
23/12/2014
So testing again today, the Navio board decided to vibrate off the pi again but this time because I had the +5v jumpered over from the ESC's the props didnt stop running (I carefully unplugged the main power). But to stop that happening again I'll be powering it from the USB port on the PI and tightly taping the Navio board to the PI, with some luck that'll hold it together and if it does disconnect the Navio board will lose power (I think, if not next time I'll unplug the servo extensions as they are easier to get to. its also possible to glue it down it seems, but that'd make it very difficult to take apart again).
20/12/2014
More testing on the stabilisation. think I'm going to have to trial and error all 8 combinations (ed. its actually 6 as I can test them independently) - + or - yaw pitch or roll to get it working (testing it in my hand while wearing protective gear)
Managed to modify the code to reach ~700hz
Used channel 5 to arm/disarm instead of ssh
Also did some work on converting the Arduino DMP code to the PI (just a curiosity thing - override I2Cdev and convert to using SPI instead)
16/12/2014
Added a second thread to handle the PWM outputs. (was surprised at how quickly I got that one working, worked second compile which would have been first but I made a copy paste mistake :p)
Added code to handle pitch and roll from the ppm inputs (only had throttle before now :p) need to add a small deadzone to help with testing stability (need to get the gyro sign correct and check the power levels - currently limited to 5%)
Fixed a plastic box to the quad to protect the electronics (and bolted in the raspberry pi), just need to make some holes for all the cables to go (just the pwm outputs, maybe one to make it easier to remove the sd card if needed and one for the antenna - radio and gps)
13/12/2014
Seems to be working, here's a link PWM2PPMFast
Been testing the PI quadcopter and i've got the rate PID functioning fine now (with all props on), just needed to get the sign correct on the gyro's, reduce the sensitivity and allow a greater spread (and fixed an issue where it was trying to update the pwm output to the ESC's and the colour LED at 1khz :p). Next I'll fix the stabilisation (pitch and roll). Then it'll be onto yaw (and the magnetometer)
It certainly seems to have more power than the arduino quad, from my testing it looks like it'll lift off at between 3-4 amps (3S) I made it jump once :p, arduino quad was at 6-7 amps (but 2S) both with a max of 12 amps. I might have to adjust the throttle curve.
11/12/2014
Found an issue with the PWM2PPM code where I was using long's to store the time and it was overflowing every 35 mins, changed to unsigned longs and made it detect the change (it just resets all the timers at the moment). I'll test that works correctly and then upload, it seems to be heading for the +-4us resolution of the micros function :)
9/12/2014
Improved the PWM2PPM code, largely sped up at the cost of configurability. (will cascade upload after I've tested a few more improvements)
Tested the PI quadcopter using the transmitter, with 1 prop on and the pid's turned off (direct throttle translation). Prop Managed to stay on fine, even when I accidentally had it at full power for a split second :) (1 prop should have just about enough power to flip it but I had my finger over the ssh disarm button and pressed it pretty fast)
Have altered the constraints I was using on the old arduino PID (mostly reduce them as its got more power and as its a new quad reduce them for safety)
Temporarily removed(commented) the GPS code from the PI quadcopter, its going to need another thread and major reduction in UBlox messages. (and is kinda redundant until I have the magnetometer working (again) which requires getting the attitude PID system working beforehand) Its a little fun computing the axis used and the direction.
6/12/2014
New prop adapters have been locktite'd up PI code modified to self level (stabilisation as well as rate PID) also added a PPM controller (just throttle atm, for testing). Gave it an Armed mode and a calibration mode (activated via SSH atm, but my android tablet does the job). It should be calibrating the magnetometer on the fly too.
I also randomly hooked up my old caterpillar track robot to an arduino, a bluetooth adapter and a 2A dual motor controller just out of curiosity. got it working, used my android tablet to control it using bluetooth + awsd&space to stop :p took about 1 hour. (would have been quicker but I forgot to reset the PWM when it changed direction)
2/12/2014
Tested all the motors again (without props) on the pi quadcopter, all seems fine. Throttled up to full power and straight to full power reverse, they give a squeak as they switch directions but very fast (will probably be a lot longer with props on).
Finished off a PWM2PPM arduino program (4 channels but pretty simple to extend).
29/11/2014
Upgraded the 6050 to the 9250 on the arduino quadcopter, recalibrated and adjusted the code to work correctly with the 9250. Managed to get the magnetometer values out too, so will see if I can use the data correctly.
Also Bluetooth again :p turns out it was the PC bluetooth software causing issues, I tried an app called BlueTerm on my nexus 7 and it all worked fine (once I hooked it all up correctly).
A serial GPS board is on the way too, UBLOX NEO6MV2 or something.
Also did a few more tests on the accelerometer only based height stabilisation. Still something wrong with it, but at least I can now get debug data over bluetooth :)
Will resume with the PI quad once I have reliable working hardware (I just mean the motors/props now, ESC's Navio board and even the power distribution seems fine atm) and at least I can test stuff on the Arduino. Its difficult to test things on the PI without any actual thrust being produced :(
The arduino program I think seems to be saturating the processing power and is reaching it limits, so I might have to adjust to fixed point math instead of floats.(Serial comms seem to use quite a bit of time)
22/11/2014
After replacing the bad motor, ran a few tests. Lots of vibration, so going to have to do something about that (possibly balancing the props correctly and maybe slightly loosening the frame). Managed to overtighten a prop adaptor so need to replace that (+prop as that got damaged too. d'oh should have just used locktite damn hardware problems).
So with the PI quad out of commission atm, I might upgrade the 6050 on the arduino quad to a 9250 and see if I can get the magnetometer data from it while continuing to use the DMP. (that or make a 4 channel pwm->ppm converter using an arduino nano so I can use the PI on the arduino quad, but I think I'd prefer to keep them seperate)
16/11/2014
Rate PID seems functional now, needed to adjust 2 motors to spin the correct direction (technically they will reverse in code, but best to keep the system consistent). Needed to increase the power levels but that's probably just because I'm testing it at 0 throttle and it has to account for the deadzone, motors operated forwards and reversed correctly depending on how the PI was rotated.
Managed to get keyboard input working over ssh (within the program), going to have to add some ansi functions so I can create a nice debug display over ssh. Eventually I'll write an Android program to control it over wifi (dont need range on it at the moment, so wifi should do for now - will give it a heartbeat to detect connection loss).
Raspberry PI B+ mounting holes dont fit, so I'll have to make a mounting platform (just a solid piece of plastic that can be screwed onto the frame+make holes for the PI, but yet another thing to do)
Ugh I think I have a bad motor, ordered a spare (it feels different turning it than the others and thats not a good sign) Should be able to test functional capability even with a bad one, just wont be as reliable and wont fly.
14/11/2014
Power spider made (bought a temperature controlled soldering iron and better solder) and a little test, all 4 ESC's are getting power. Not powering the PI from it yet, but thats just a case of a jumper, the LED does light up fine tho with ESC's plugged into the PI which shows its all connected up ok :D
Now to get to work on getting a simple version of the software running. (and physically attaching the PI+Battery but that'll be after initial testing)
12/11/2014
Still sorting out the power distribution on quad2, doesnt help that I've little soldering experience.
I think I've worked out how to use the magnetometer now tho (at least on the arduino), just needed pitch and roll compensation from the accelerometer :) Need to extend the pitch and roll calculations to handle a full +-180 degrees instead of 90, but looks like it could work :) (I gave up trying other peoples things and used my own math - similar to stuff I wrote for a little test game engine 15 years ago :p). So I now have a 2D vector that points to magnetic north consistently :D
3/11/2014
Navio Board has arrived :D done some testing and it's all working perfectly. Just need something else to arrive so I can make the power distribution system and I'll be getting to work on it. (got a 5.5AH 3s lipo for it)
ESC's will plug directly into the Navio board and power the servo rail + its on board RGB LED.
Accelerometers/Gyros/Magnetometer/Barometer and GPS all functioning as expected :) (well mostly, after some experimentation with quad1 it turns out the DMP on the 6050 was more useful than I thought, it gave it a much higher frequency gyro reading than 50Hz. fortunately the raspberry pi is capable of around 1khz anyway)
