Hi, I'm new to the forum
My current flagship project is a 10 degree of freedom IMU AHRS.
I'm using actually AltiIMU-10 v4 coupled with a LS20031 10 Hz GPS module, the microcontroller is a PIC18F26K80 (previously PIC18F2680), running at 64MHz (PLL), (16MIPS)
It may seem crazy to implement such a system on a PIC, but, as I said in my invitation request, i don't like arduino
The IMU parts are:
Accelerometer 3D, LSM303D
Magnetometer 3D, LSM303D (both on the same unit)
Barometric altimeter, LPS25H
Ratio gyroscope 3D, L3GD20H
GPS module LS20031
The communication between the PIC is performed through I2C (1MHz), while the GPS module communicates via USART (
For the calculation i used fixed point maths, usually with 15bit fractional part of a LONG variable (1.0000 is represented as 32768). The trigonometric rotines are a mix of lookup tables (memory usage reduced using sin(a+b) trig identities) and CORDIC routines, (i made them in past for the windlogger), and are optimized to reduce the time spent into calculating the functions.
The calculation of the Attitude is done by using quaternions (i designed some functions to perform basic quaternio math), and complementary filter (kalman is too proc intensive). The complementary filter actually has a variable coefficient (similar to Kalman)
I use all the set of vectors, including compass giving exactly the three angular components (roll, pitch,yaw) of the attitude (the yaw is affected by mag declination though)
The code was optimized trying to remove, where possible, processor intensive operations, sush as multiplication an division (replaced by bitshifts on the absolute value)
The first experiments gave a refresh rate of 20Hz on PIC18F2680, not it is 130 Hz including the GPS USART wait time.
The GPS gave me lot of problems, since i cannot request a NMEA packet, I have to wait for the data packet to arrive (and this wastes PIC proc time, and can be very deleterious for an UAV
) so i used the internal Timer of the pic to sinch with the 10Hz GPS refresh rate reducing the wait time to a calculation cycle time (currently 6msec)
It is a bit cumbersome. I have thought other solutions such as using another PIC as a buffer/frontend or reducing the GPS refresh rate but I don't think it is a good idea.
Next steps will be pulsing the PWM input of the ESCs (1-2ms square pulse) and reading the receiver signal (this time i will need a front end) in PPM or D-SBUS.
The project should evolve in a fixed wing marconi plane (marconi is a type of kite) for aerial mapping. The intrinsic safety it such an aircraft may be of interest for specialized UAV operations
Any questions, suggestions, requests?