10DOF AHRS Project IMU

[Droneman1982]

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?

[Parmin]

.Sounds good.
 Are you going to share?

[Droneman1982]

Of course 

The main program cycle is only to testing and debugging the subroutines, but the subroutines, i think, are at a stable version.

Are you working on a similar project?

[Parmin]

No, just very interested.

[Droneman1982]

I will have to start designing the front-end with the RC receiver and maybe also moving the GPS module communication on the frontend too.

Another issue will be the magnetic declination, a couple of deegres is fine but more will cause "toiletbowl effect" or even a flyaway...

one possibility is to store a lookup table in the EEPROM memory of the PIC or design an algorithm to calibrate the compass.

so much work 

[Droneman1982]

I have decided to split the device into two distinct microcontrollers. One will be devoted only to the IMU and motor control, the other will manage GPS, receiver, ground station etc.

The communication between them will be indirect using a shared I2C ram. To detect when the bus is busy i will use a pull-up resistor connected to the open collector (RA4) of both PICs. The ram will store the IMU attitude (roll, pitch, yaw and altitude) coming from the PIC1 and the angle and altitude setpoints, mag and accel calibration constants, distance and heading coming from the PIC2, and PID parameters. This way the first pic will work at the highest frequency without any waiting times driving the ESCs using a PID algorithm and imu calculations, the second will manage AI and all the communication with the user.

I have to find a 1K I2C ram to work with