The UART for the telemetry link has an inbound and outbound buffer. We should enable these, but need to make sure that a partially filled buffer doesn't block any remaining incoming or outgoing data.

Should just be a matter of reading the PIC chip docs and configuring the UART.

Add ways to change the PID loop (Control Loop) gains dynamically based on changing conditions. For instance, if the airspeed is between x and y, change the roll gain to z.

Primarily split up functionality in the AttitudeManager.c file.

Things to optimize:
-communication with the VectorNav sensor
-control loops

Add velocity components to the IMU for better calculations of angle etc. (velocity taken from GPS+airspeed sensor)

We have never used integral control while flying. The code is partially there, however it needs to be completed and fixed.

-Make sure there is no overflow in the integral summation (make sure it doesn't max out)

The best option may be to convert all the control loops back into floating point calculations, and optimize the code elsewhere.

Implement Primary & Secondary Buffers to help improve data transfer and help mitigate potential for data loss / corruption, therefore hopefully minimizing the need / number of DMA re-synchronizations that are needed

Should get rid of it as it was merged into InterchipDMA.c and the init_SPI1() function

Get the units of the types in the struct (as comments).

See here. UWARG/WARG-Ground-Station#7

In this repo, need to modify net.h

The original intention was to have the UART debug screen look as such:

[error]PWM interface not initialized.
[warning]Zero values for altitude measurements
[error]Divide by zero occurred.
[debug]testing123

Currently, the [error], [warning], [debug] tags do not work. The concat function in debug.c causes a chip reset.

This is not a priority, it is a minor problem.

Pretty much everything in the nbproject (except for _____???) are generated files. These should be removed and .gitignore'd as appropriate. This will prevent the emergence of future merge conflicts on these files, which we don't actually need/want to deal with (since they are generated anyway).

It looks like there could be possible stack corruption in the adjustVNOrientationMatrix function within AttitudeManager.c. You can see we declare an array of 9 floats, and pass it onto the vectornav function
VN100_SPI_GetRefFrameRot .

void adjustVNOrientationMatrix(float* adjustment){

    adjustment[0] = deg2rad(adjustment[0]);
    adjustment[1] = deg2rad(adjustment[1]);
    adjustment[2] = deg2rad(adjustment[2]);

    float matrix[9];
    VN100_SPI_GetRefFrameRot(0, (float*)&matrix);
    ...otherstuff...
}

Inside this function however we see that its going to try to write 12 bytes onto the variable (look at for loop). This will cause a corruption of the stack. According to chris everytime the adjustVNOrientation matrix function is called, the picpilot crashes, so this would explain why.

VN100_SPI_Packet* VN100_SPI_GetRefFrameRot(unsigned char sensorID, float* refFrameRot){

  unsigned long i;

  /* Read register */
  VN100_SPI_ReadRegister(sensorID, VN100_REG_RFR, 12);

  /* Get reference frame rotation parameters */
  for(i=0;i<12;i++){
    refFrameRot[i] = VN_SPI_LastReceivedPacket.Data[i].Float;
  }

  /* Return pointer to SPI packet */
  return &VN_SPI_LastReceivedPacket;
}

The vision folder contains the image processing code we took to competition. It should be in its own repo and managed separately.

At competition we put in "last minute fail-safe" conditions. They were poorly implemented, but they did the job.

We want something more robust. This will involve checking GPS signals, datalink signals, RC controller signals and determining the required actions.

If we lose all 3 signals, kill within 5 seconds. Chances are it is already dead.

If we lose datalink and GPS, kill within 10 seconds. The ground station should notify in case of a datalink loss.
If we lose datalink and RC control, kill within 10 seconds. The ground station should notify in case of a datalink loss.
If we lose GPS and RC control, notify the ground station. Attempt to fly home using magnetometers.

If we lose RC Control, notify ground station. Appropriate action should be taken.
If we lose datalink, head home within 5 seconds. If a signal is not re-established within 2 minutes, kill the vehicle.
If we lose GPS, notify ground station. Use magnetometers to head home. Keep the vehicle at a constant altitude/or level.

Currently each coordinated turn only includes aileron and elevator action. Rudder action also needs to be included.

The rudder should MATCH the aileron action with some proportion.

Rudder = k * ailerons
Figure out k.
http://www.pilotworkshop.com/tips/rudder_coordinated_flight.htm

In a more complicated manner:
l = 1/2_ρ_V_a^2_S_b_C_l (β, p, r, δa, δr )
n = 1/2_ρ_V_a^2_S_b_C_n (β, p, r, δa, δr )
l and n are roll and yaw moments.
C_n and C_l are non-dimensional, non-linear aerodynamic coefficients dependent on δa, δr, pitch, roll and side slip angle.

We want the proportionality between δr,δa. This is difficult to solve for (there are a few other equations that we need to look at to do that, and it will be a non-linear algebraic system), therefore we need to make approximations.

Whenever the ailerons move, the rudder should also move to support the turn.
The elevator on the other hand (already implemented), is dependent on the roll angle (and not the roll rate). Higher bank angle = less lift = need for elevator

in AttitudeManager.c ~line 145

The struct for waypoint wrapper looks like this:

//Structs and typedefs
typedef struct _waypointWrapper{
    long double longitude;  //TODO: Longitude and Latitude is bulky. If problems arise, change the format.
    long double latitude;
    float altitude;
    float radius; //Radius of turn
    char type; //Regular or probe drop location
    char id;    //Array ID
    char nextId; //For use with insertNode() or operations that require reference to another node
    char previousId; //For use with insertNode() or operations that require reference to another node
}WaypointWrapper;

The groundstation/data relay station will send latitude,longitude,altitude,radius,type,next_id, previous_id

It however does not send the id field, which will cause the parsing of the nextId and previousId values on the picpilot side to fail, as the code relies on the exact structure that the struct is defined in

 Picpilot code:
case INSERT_WAYPOINT:
                amData.waypoint.altitude = (*(WaypointWrapper*)(&cmd->data)).altitude;
                amData.waypoint.latitude = (*(WaypointWrapper*)(&cmd->data)).latitude;
                amData.waypoint.longitude = (*(WaypointWrapper*)(&cmd->data)).longitude;
                amData.waypoint.radius = (*(WaypointWrapper*)(&cmd->data)).radius;
                amData.waypoint.nextId = (*(WaypointWrapper*)(&cmd->data)).nextId;
                amData.waypoint.previousId = (*(WaypointWrapper*)(&cmd->data)).previousId;
                amData.waypoint.type = (*(WaypointWrapper*)(&cmd->data)).type;
                amData.command = PM_INSERT_WAYPOINT;
                amData.checkbyteDMA = generateAMDataDMACheckbyte();
                amData.checksum = generateAMDataChecksum(&amData);
                break;

The code should be refactored slightly such that the fields that are used across the UPDATE_WAYPOINT, NEW_WAYPOINT, INSERT_WAYPOINT, etc commands are placed first in the struct, with padding bytes on the data relay where necessary to avoid parse errors.

To start off, the id field should be moved to the bottom of the struct, since its never actually used. It should be notes in the comments that the structure of the struct is vital, so that people dont insert fields in the middle of it.

Remember when we had to reset the plane after we launched?
That was the SPI and DMA desynchronizing the bits and giving funky data.
I was thinking to try experimenting with the slave select.
If nothing seems to work, maybe add a checksum and force an interface reset, or maybe a chip reset (I wouldn't do this unless you have to because it resets the ram too).

Not much to go on here.
Possibly:
-Add sonar to the aircraft, and figure out how to use it properly.
-Experiment landing using the altitude sensor (accurate to 1m) - This would need to be very accurately tuned to work.

Using a low pass filter on altimeter and a high pass filter on GPS.

GPS altitude is accurate if it has the same number of satellites. Once it changes satellites then it jumps around. But it will not drift over time when it has the same number of satellites.

Altimeter will drift over time at the same altitude due to pressure changes. But will not jump around.

Make a better way to communicate (and verify) the path on the ground station and the plane.
Currently, if the plane didn’t get all the path points, we won’t know until it actually gets there.
Maybe a checksum of the coordinates or just send back all the data or something.