I wrote down that this did not work. So when you pressed the button on the joystick, the QR did not go to panic.

Do some fancy bitshifts and filter tha sensrz

Write some code that implements a feedback loop on the X32

each message should have
control byte
2 value bytes
checksum byte

Give feedback to the user about the speed of the motors

List of values to be shown:

• Motors RPM
• Sensor values
• Control/Filter variables
• Lost packets
• Joystick values

It still does not send the values 255 and >60000 or something

So that we can show this during the lab demo

Send an error message when overflow and/or divide by zero

now it is *2 or *1/2 and it should also be possible to do *3/4

Minimum measurements that must be conducted (and documented) include
the internal control response time of the ES (typically, the control loop time in ms), the system response
time as perceived by the user (i.e., the time between joystick movement or key-press, and QR response), and the associated QR yaw, roll, and pitch response (in terms of a time plot) in order to properly assess achieved stability performance.

Make sure that the QR is not turing the motors when you've just switched to yaw or full control mode.

Logging data from QR to the PC.

Possibly buffered in the ES RAM first > see X32's programmer manual.

QR ==> PC

• Sensors
• outgoing actuators ( ae[i] )
• System time
• system mode
• Control loop time
• incoming joystick keyboard data
• Control parameters & Signal processing data
• whatever

PC ==> QR

• User response: joystick/key press and system feedback

Max 10Hz update rate

also: don't log every loop if in safe or panic mode

This function should send all kind of predefined errors
At the pc these errors must be mapped to a string that the user can read
also define error messages like:

define ERROR_MESSAGE 'E'

define ILLIGAL_MODE_TRANSITION 'M'

define MODE_CHANGE_MOTOR_TURNING '1'

define MOTOR_CONTROL_NOT_ALLOWED_IN_THIS_MODE 'C'

Make sure that RPY has enough effect on the motors

what is the time that it takes on the QR to act upon the JS?
What is the typical control loop time

Currently, messages are 'sent' via printf. We need to send back in the same way as we receive on the QR (so with control, value and checksum). There must be some put_char function in X32 to do this.

The main file is becoming too long. Main should be small and there should be separate files/methods for communication, sensor reading and filtering, feedbackloop and motor actuation.

There are ~20 global vars, maybe a reduction is possible by making some calls more functional

Make sure that a status LED is on the QR as well (just as on the nexys). Maybe we can make a fancy blinking LED thing.

Make sure that we can adjust all important values via the keyboard. When giving the demo, we can then just tune it a bit if the TA's ask us.

Instead of having magic chars everywhere in the code, specify an enum (of defines) with all the control values. This makes sure that they are all in one place and make the overall code less sensitive to errors

Everything includes:
-Joystick axes RPY
-Throttle
-Offset
-RPM

0-600 in a small interval, 600-max in a longer interval

check if last throttle event was 0, before sending mode change>=manual

messages like: start new line

Except for PANIC and SAFE