'm having some trouble adapting the new IMU v3 to Jean-Louis' code written for tricopters. His code used the APM_Compass library and for some reason, it wont compile with any reference to that library. The new IMU doesnt use that library, so I havent let that stop me from trying. It compiles and gives me output, but something is still wrong. The debug wont print GPS and the attitude values although stable seem way off. I'm hoping some experts can look at my code and tell me what's wrong or even what is right.
I've included the code I have now. Please help if you can.ardimupter-120708b.zip
Replies
I was able to swap over one of the 500kv motors, pretty narrow clearance to the ground, I may need to have some longer Carbon Fiber feet made. Which could be a clean way to mount the variable pitch servo anyway.
I think I'll try to get the other motors swapped and sort out the Atmega328p PPM encoder tonight.
I've been sidetracked building and promptly crashing a EPS foam 3D plane... Flew it straight into the ground LoL. I got it to get better with orientation and of course I crashed the moment I nosed it in towards myself. I think this will really help my skills in the piloting area once I can keep it in the air for more than a few seconds hahaha.
This weekend is camping with just the wife and myself so I'll be flying a lot but not studying at all. It is a payday weekend too and I'm intent on getting into finishing some of the laundry list of outstanding projects I have going, so I can get back to being focused on just one thing at a time. I've got the hexacopter to assemble, a UAV plane (2500mm Reaper) to build, about 6 broken cars and trucks to go through, and an EDF jet coming as well. I went on a bit of a shopping spree in that I was buying faster than I was building and it's gotten a bit overwhelming...
I had to take a break from the flight control programming, just didn't realize how far away I had gotten. With a bit of work I should be back into the IMU and the various STM32 based counterparts after the next week or two.
Hope you've been having some fun playing too :-)
This I believe is the heart of the CCPM:
// roll factors
_rollFactor[CH_1] = cos(radians(servo1_pos + 90 - phase_angle));
_rollFactor[CH_2] = cos(radians(servo2_pos + 90 - phase_angle));
_rollFactor[CH_3] = cos(radians(servo3_pos + 90 - phase_angle));
// pitch factors
_pitchFactor[CH_1] = cos(radians(servo1_pos - phase_angle));
_pitchFactor[CH_2] = cos(radians(servo2_pos - phase_angle));
_pitchFactor[CH_3] = cos(radians(servo3_pos - phase_angle));
// collective factors
_collectiveFactor[CH_1] = 1;
_collectiveFactor[CH_2] = 1;
_collectiveFactor[CH_3] = 1;
I just haven't learned enough of the processor related math to build it :-(
But, I do know that servo1_pos=60, phase_angle=0 (on my heli), servo2_= -60, servo3_pos=180 ect...
ArduCopter.2.7.1/Libraries/AP_Motors/AP_motorsheli
I know this is what I am looking for, I just don't understand it well enough to implement it in Gregs's code...
Also I wonder how much faster the loop could be if all the debugging code was removed?
On other fronts, I've ordered all the hardware to do a variable pitch hexa copter (I'll start with the pitch fixed for simplicity and to help develop the ArduIMU, then get into the VPP stuff). I got tied up with the APM 2.5 fiasco, had issues with wiring the optical flow, had issues with the external gyro being enabled by default so I couldn't get the tail working... connector problems, the whole nine yards. But it's flying we'll now and is complete aside from wire management, that I will address after I know it is all solid as far as component location.
I feel good about going back over Gregs gimbal code with some idea of what I'm looking at. I certainly have a better understanding of what the header files do...
Rube-Goldberg copter, LOL now that's funny :-)
Well, I've been learning the programmers on my MinimalOSD board that I have no use for but has an Atmega328P on it (found an old CellShield lipo protector that is dead which also has a 328P too). Thought I had bricked it at one point when I set the fuse for Wire-Debug and couldn't get it back to ISP mode... Just exited the program without telling it to return the board to ISP LOL.
Once I get the hang of the programmers and IDE's I'll start tinkering with the ArduIMU. Kind of disappointed so far, spent $300 on Crossworks for AVR and ARM and I'm finding the free Studio 6 from Atmel much more friendly. Oh well, I'll master them all eventually.
When I over discharge a lipo I usually set the charger to do a NiMh pack and limit the current to like 500mA for a few minutes just to bring the cells back up to where the lipo balancer will play nice.
Spent the entire weekend soldering on the APM 2.5, had to solder the wires for the Optical Flow straight to the Data Flash SPI pins to get it to work, that only took me ~14 hours to sort out :-/ I think 3DR forgot to make a port for it again (on the 2.0 you had to solder the wires to the 2x6 for the daughter board).
Harry, when you have a minute could you post up where you are landing your servo's and PPM input?
I've got an FTDI programmer, but it's likely I will be using the AvrICE MKII to debug with, it is due Friday. I'll try the FTDI until then, guess I will be familiar with Arduino too...
I think the Optical Flow sensor hasn't worked well on the traditional heli's because when the APM corrects for drift it tilts the heli causing the Optical to sense drift, which has to be accounted for in code. This makes for a complicated loop in the software that must be hard to tune... eliminate the tilt for the Optical and simplify the tuning?
Then I could be playing with Greg's code parallel to yours :-)
I'd put the fronts in opposition to each other and let the rear do its compensation for its own torque imbalances. Maybe even set it with mechanical trim at a few degrees...
-
1
-
2
-
3
of 3 Next