vasylgry / cortex-ap Goto Github PK

Implement pressure to altitude conversion

Find a suitable radio module for telemetry 
Interface radio module with Bluetooth module 

DCM algorithm seems to have some issues with tight turns.

Find a logo

What steps will reproduce the problem?

download mission data with droidplanner

What is the expected output? What do you see instead?

Expected HOME position near aircraft
HOME position at (0, 0) instead

Please use labels and text to provide additional information.

Steps to reproduce the problem.
1. connect cortex-ap PPM input to 40 MHz Robbe RC receiver output
2. make sure RC transmitter is off
3. power up cortex-ap

Expected behaviour.
- normal working, with blue LED toggling every second

Actual behaviour.
- blue LED freezes (either light or off) after 3 to 15 seconds
- halting the debugger always finds the code inside some I2C routine
- I2C is in an error condition
- task switch doesn't take place.

Additional information.
- problem doesn't arise with home made RC receiver
- PPM signal of Robbe receiver is much more noisy 
- problem remains with transmitter turned on, only after a longer time
- code doesn't get stuck in the hard fault handler 

Hypotheses.
1. Stack overflow
2. Timer interrupt retriggers, 1. There could be a problem with pipeline races 
that delays clearing the interrupt flag before exiting interrupt handler. This 
causes the interrupt routine to reenter immediately after. According FreeRTOS 
website, adding an instruction that reads the interrupt register should force 
the CPU to wait until its completion, thus avoiding returning before flag has 
been cleared.
3. Timer interrupt retriggers, 2. Due to the fact that only noisy signal causes 
the problem, the interrupt could reenter before its finished. 
4. Wrong interrupt priorities, known issue with FreeRTOS ports for Cortex M 
processors.
5. Stack gets scrambled by automatic variable allocated inside interrupt

Actions.
1. Apply method #1 and #2 from FreeRTOS web site.
2. Add an instruction that reads the interrupt register before exiting routine.
3. Verify that interrupts are disabled when entering timer interrupt. Verify 
that same interrupt / interrupts with same priority can't interrupt itself.
4. Verify priorities assigned to interrupts, compare to those of kernel.
5. Make variable a global one

Results
1. No stack overflow caught.
2. Solution seems only to increase the delay before the problem manifests.
3. TBD
4. TBD
5. TBD

PID implementation has no unit test.
Results of simulation tests are controversial.

Mavlink telemetry sends constant "3" in gps fix field.
Can't understand from GCS if GPS has got fix or is still searching.

Many commands of Multiwii protocol are still to be implemented

What steps will reproduce the problem?

1. read gyro registers with ReadBuff() function
2. save UART log output to sensor.txt file
3. turn board around X, Y and Z axis in sequence
3. convert log file to excel, plot angular rates

What is the expected output? What do you see instead?

Expected to see variation in X, Y, Z axis, in sequence.
Only variations in X and Z axis, Y axis with low level noise.

Please use labels and text to provide additional information.

Y axis values always < 0, most significant byte always = 0xFF !
MSB of Y axis is the (N-3)th byte read from gyro.
ReadBuff() function changes working principle exactly at byte # (N-3).

1. connect cxap board to GPS simulator
2. open MAP window in the GUI (MultiWiiWin, MultiWiiAllinone)
3. start GPS simulator

Expected to see a clear track of aircraft while it moves.
Tracks shows jumps in the longitude and in the latitude direction.

Longitude and latitude reported by telemetry are read from nav.c module.
Same variables are written to by GPS parser routine.
This may result in corrupted lat/lon data if telemetry reads them before
GPS parser has completed.