In this post, I will discuss the tradeoffs of using the Round Robin, Round Robin with Interrupts, and Function Queue Scheduling approaches when building an embedded system. Let’s consider that we will use an Arduino to perform tasks such as capturing sensor data and downloading to a host machine (e.g. your personal laptop computer).
Round Robin
Definition
The Round Robin architecture is the easiest architecture for embedded systems. The main method consists of a loop that runs again and again, checking each of the I/O devices at each turn in order to see if they need service. No fancy interrupts, no fear of shared data…just a plain single execution thread that gets executed again and again.
Pros
Simplest of all the architectures
No interrupts
No shared data
No latency concerns
No tight response requirements
Cons
A sensor connected to the Arduino that urgently needs service must wait its turn.
Fragile. Only as strong as the weakest link. If a sensor breaks or something else breaks, everything breaks.
Response time has low stability in the event of changes to the code
This Round Robin with Interrupts architecture is similar to the Round Robin architecture, except it has interrupts. When an interrupt is triggered, the main program is put on hold and control shifts to the interrupt service routine. Code that is inside the interrupt service routines has a higher priority than the task code.
Pros
Greater control over the priority levels
Flexible
Fast response time to I/O signals
Great for managing sensors that need to be read at prespecified time intervals
In the Function Queue Scheduling architecture, interrupt routines add function pointers to a queue of function pointers. The main program calls the function pointers one at a time based on their priority in the queue.
Pros
Great control over priority
Reduces the worst-case response for the high-priority task code
Response time has good stability in the event of changes to the code
Cons
Shared data
Low priority tasks might never execute (a.k.a. starving)
Before we discuss the shared data problem when building embedded systems, it is important to understand what interrupts are.
What are Interrupts?
The most basic embedded software has a main program that runs uninterrupted…that is, it runs until either it stops on its own or something else causes it to stop.
For example, if you unplug your refrigerator, all programs that were running will immediately stop, and the refrigerator will shutdown. Otherwise, while the refrigerator is plugged in, programs will continue to run uninterrupted. This is called embedded software without interrupts.
You also have software where the main program executes normally but stops either periodically or due to some code (that is not part of the main method) that must get executed immediately. The main program stops, some other code is executed…(i.e. code that is not part of the main program). We call this an interrupt service routine. When this interrupt service routine is finished, control is shifted back to the main program, and the main program gets back to doing what is was doing prior to being interrupted.
Here is an image that shows what I just explained:
You likely trigger interrupt service routines all of the time without even knowing. For example, normally your desktop computer runs various background programs when you are not on your computer. Let’s call this the main() program. As soon as you click your mouse or type on your keyboard, you trigger an interrupt service routine. The computer handles this interrupt service routine by exiting the main() program temporarily, reading what you just did and doing what you commanded it to do (i.e. servicing the interrupt).
After that, the computer exits the interrupt service routine, goes back to doing what it was doing before you interrupted it (i.e. control shifts back to the main() program). That is a lot like how interrupts work in embedded systems, and you will find them in many if not most embedded programs in some form or fashion.
A big problem in embedded systems occurs in embedded software when an interrupt service routine and the main program share the same data. What happens if the main program is in the middle of doing some important calculations using some piece of data…an interrupt occurs that alters that piece of data…and then the main program finishes its calculation? Oops! The calculation performed by the main program might be corrupted because it is based off the wrong/different data value. This is known as the shared data problem.
Real-World Analogy: Running a Bakery
Imagine you own a bakery. You are trying to calculate how much money you made in 2018. You have just entered the revenue for each month listed in a Google spreadsheet. It looks like this:
Starting with January through March, you add the first three months of revenue into your calculator “10000 + 10000 + 10000 +” and then all of a sudden, your assistant (whose job it is to keep revenue updated periodically), interrupts you and asks if he can update something in the spreadsheet. You say, “Sure.”
You get up from your chair and go to the break room.
In the meantime, your assistant (i.e. the “interrupt service routine”) then gets on your computer.
While you are in the break room, your assistant changes the revenue on your spreadsheet in January 2018, increasing it from $10,000 to $15,000. He then leaves the room.
You then return from the break room. You get back in your chair and continue entering in the numbers in your calculator for the other nine months, for April through December. You conclude that the revenue for 2018 was $10000 per month for 12 months (i.e. $120,000). You record that number so that you can use it for your tax filings. Oops! See the mistake?
The main program (i.e. you) was unaware that the interrupt service routine (i.e. your assistant) made a change to the January 2018 revenue data, so the value of $120,000 is not consistent with the updated data. It should be $125,000 not $120,000.
This in a nutshell is the shared data problem. We need to make sure that you, the main() program, are NEVER interrupted while you are in the middle of making important calculations on your calculator. You and your assistant both share responsibility for making sure revenue is accurate, but we need to make sure you both aren’t working on the revenue at the same time.
In the real world, this would take the form of you posting a “DO NOT DISTURB” sign on your door to keep your assistant out when you are making critical calculations. In software engineering, we call this “disabling interrupts.” While interrupts are disabled, nothing can interrupt the main program.
Disabling interrupts is like the main program putting up a big DO NOT DISTURB sign. Source: Wikimedia Commons
Real-World Example: Designing an Automatic Doggy Door
Let’s look at a real-world example to further show you the shared data problem.
Problem
Imagine you are a software engineer working at a company. Your team is responsible for designing an automatic dog entry door. This embedded device can be wirelessly updated with RFID tags for dogs or other pets to be allowed entry.
The door needs to automatically unlock for dogs that are in the vicinity of the door. A pet must be allowed to enter even when the table of RFID tags is being updated. The RFID tag IDs are shared data since the interrupt service routine that must update the tag IDs and the main() program that is responsible for automatically unlocking the door when dogs are in the vicinity both share and use this data. A problem will occur when the doggy door is in the middle of an RFID tag ID update when a dog needs to get through the door. We wouldn’t want to let the poor dog wait outside in the freezing cold while the device is in the middle of an RFID tag update!
How do we create a solution that solves the shared data problem? The RFID tags need to be updated regularly but that same data is needed regularly by the main() program to let dogs enter when they need to. Let’s solve this now.
System Requirements
Dogs wearing RFID tags/cards need to be able to enter the door (i.e. gate) when they get close to the doggy door.
This embedded device can be wirelessly updated with RFID tags.
Dogs or other pets must be allowed entry when they are in the vicinity of the door.
Dog must be allowed to enter even when the table of RFID tags is being updated.
RFID tag IDs are shared data which must be managed.
In the shared data problem for the doggy door controller, we need to make sure the dog can enter at all times while the RFID tags are being updated. Because this is a dog, it is unacceptable for the door to remain locked and keep a dog waiting.
Implementation
To solve this problem, I would design the following loop for the main program in pseudocode:
While (True)
// Begin Critical Section of Code - Can't Be Interrupted
Disable_interrupts()
Scan to see if dogs are in the area (i.e. RFID scan)
If a valid dog is in the area, unlock the door
Else, do nothing
// End Critical Section of Code That Can't Be Interrupted
Re-enable_interrupts()
Update RFID table (interrupt service routine)
// In the meantime, dog is walking through the door
Check if the door is unlocked
If the door is unlocked, delay 30 seconds to give
the dog sufficient time to enter
Make sure the doggy door is locked
Go back to the beginning of this loop
The above architecture satisfies the requirements and enables a dog to enter even when the table of RFID tags is in the middle of an update.
In this post, I’ll show you how to send roll, pitch, and yaw data over I2C using Raspberry Pi and Arduino. We’ll also capture GPS data on the Raspberry Pi to make things interesting for when I mount everything on a quadcopter.
Requirements
Here are the requirements:
Using the IMU connected to the Arduino, capture roll, pitch, and yaw data.
Using the GPS connected to the Raspberry Pi, capture latitude, longitude, and altitude data.
Send the IMU data via I2C to the Raspberry Pi.
Send the IMU and GPS data via Bluetooth from Raspberry Pi to my host computer (e.g. my personal laptop).
Display the data on my host computer.
To make things interesting, I mounted all the equipment on a quadcopter.
Design
Hardware
The following components are used in this project. You will need:
Here are the steps for the GPS Poller, responsible for capturing Latitude+Longitude+Altitude data on the Raspberry Pi:
Open a new file to log the GPS data
Create a GPS Poller class
Log the latitude data
Log the longitude data
Log the altitude in feet
Delay 5 seconds
Close file
Here are the steps for the IMU I2C program on the Arduino, responsible for capturing Roll+Pitch+Yaw data and sending to the Raspberry Pi:
Set the delay between fresh samples
Define a flag to stop the program
Make the Arduino a slave to the Raspberry Pi by defining a slave address
Declare a byte array of size 12, which will be the roll+pitch+yaw data (with the sign) to send back to Raspberry Pi
Declare variables used for digit extraction
Declare function to end the program
Display some basic information on the IMU sensor
Display some basic info about the sensor status
Display sensor calibration status
Create method that sends a byte array (of size 12) when reading request is received from the Raspberry Pi
Create method that retrieves the digit of any position in an integer. The rightmost digit has position 0. The second rightmost digit has position 1, etc. e.g. Position 3 of integer 245984 is 5.
Create Arduino setup function (automatically called at startup) — 9600 Baud Rate
Initialize the sensor
Set up the Wire library and make Arduino the slave
Define the callbacks for i2c communication
Need callback that specifies a function when data is received from the RPi Master
Need callback that specifies a function when the Master requests data from the Arduino
Arduino loop function, called once ‘setup’ is complete
While not done:
Get a new sensor event
Display the floating point data and capture the roll, pitch, and yaw data. Cast the floats to signed integers.
Store each digit of the roll, pitch, and yaw data into a byte array (which will be sent to the RPi)
End program
While true infinite loop
Here are the steps for the I2C Python program on the Raspberry Pi, responsible for sending messages and requesting IMU data via I2C from the Arduino slave:
Open a new text file to log the IMU data
Set up slave address in the Arduino Program
Read a block of 12 bytes starting at SLAVE_ADDRESS, offset 0
Extract the IMU reading data
Print the IMU data to the console
Write the IMU data to the text file
Close text file when done
Request IMU data every 5 seconds from the Arduino
Implementation
The most straightforward way to connect the Arduino board to the Raspberry Pi is using the USB cable, as I have done in previous projects. However, we can also use I2C. I2C uses two lines: SDA (data) and SCL (clock). It also uses GND (ground).
Here are the connections that I made between the Raspberry Pi and the Arduino:
Raspberry Pi SDA (I2C1 SDA) –> Arduino SDA
Raspberry Pi SCL (I2C1 SCL) –> Arduino SCL
Raspberry Pi GND –> Arduino GND
Raspberry Pi 3 Pin Mappings. Image Source: Microsoft.com
The BNO055 (IMU) was wired to the Arduino Uno using the solderless breadboard as follows:
Connected Vin to the power supply of 5V
Connected GND to common power/data ground
Connected the SDA pin to the I2C data SDA pin on the Arduino (A4).
Connected the SCL pin to the I2C clock SCL pin on the Arduino (A5).
To get started with the implementation, I tested the GPS device to see if I can successfully capture GPS latitude + longitude + altitude data on the Raspberry Pi and save it to a text file. This data will later get sent via Bluetooth from Raspberry Pi to my Host computer (HP Omen laptop with Windows 10).
GPS was connected to the Raspberry Pi via the USB cord. The commands for this are as follows:
To start the GPS stream, I typed:
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
To display the GPS data, I typed the following command:
cgps -s
Here is what the display looked like:
Other commands I could have run are gpsmon and xgps.
gpsmon looks like this:
xgps looks like this:
Sometimes the GPS data did not show up immediately. When that occurred, I rebooted the Raspberry Pi by typing the following command:
sudo reboot
I typed the following command to shutdown the GPS stream:
sudo killall gpsd
Now, I want to do the same thing, but this time I want to save the GPS data to a text file. I will use this syntax in the command terminal in order to save the standard output stream to a text file.
command | tee output.txt
More specifically, I will type:
cgps -s | tee /home/pi/Documents/GPS/output.txt
The output.txt was created, and the data was logged in the file. However, it is more useful to output the GPS data in a more user-friendly format. To do this, I will run a Python script that is a GPS polling program. The code for this program is located in the Software section later in this report.
To create the program, I opened the Python IDE (Raspberry Pi -> Programming -> Python 3 (IDLE)).
I clicked File -> New File. I then added the code and saved the file as GPSPoller.py.
To run the script, I typed
python GPSPoller.py
To stop the script, I pressed Ctrl-C. I could have also pressed Ctrl-Pause/Break.
Here is the output of the locations.csv file. For the actual code when I flew the quadcopter, this file was named gps_data.txt.
Here is how gps_data.txt looks:
Next I connected Arduino to Raspberry Pi via I2C as pictured earlier in this section. I also connected them via USB in order to provide the Arduino with power and to easily upload sketches to the Arduino. BNO055 connects to Arduino.
Next, I followed the instructions inMonk (2016) to make the Arduino the Slave, and the Raspberry Pi the Master. I needed to write code for both the Arduino and the Raspberry Pi in order for them to communicate with each other via I2C (The code for Arduino and Raspberry Pi are in the Software section later in this report).
After writing the Arduino code for I2C communication and IMU data capture, I uploaded the code to the board. I then needed to enable I2C on the Raspberry Pi. I configured Raspberry Pi accordingly by going to Preferences under the main menu, and then clicking Raspberry Pi Configuration -> Interfaces -> Enable I2C.
I now installed the Python I2C library by using the command:
sudo apt-get install python-smbus
It was already installed. I then clicked:
sudo reboot
I had my Arduino Uno attached to the Raspberry Pi via I2C. I wanted to check that it’s attached and find its I2C address.
From a Terminal window on my Raspberry Pi, I typed the following commands to fetch and install the i2c-tools:
sudo apt-get install i2c-tools
It was already installed.
Next, I ran the following command:
$ sudo i2cdetect -y 1
Next, I needed to write the code in Python that the Raspberry Pi can use to make requests for IMU data from the Arduino. That code, as I mentioned above, is in the Software section of this post. I will run this Python script in the terminal window and redirect the IMU data response from the Arduino slave to a text file.
The command to run the Python program is as follows:
sudo python ardu_pi_i2c_imu.py
A file named imu_data.txt will capture the Roll+Pitch+Yaw data. Here is how the data looks:
Hardware
Software
Here is the Python script that logs the GPS latitude + longitude + altitude data into a text file on the Raspberry Pi. Don’t be scared at how long the code is. Just copy and paste it into your file:
from gps import *
import time
import threading
# Source: Donat, Wolfram. "Make a Raspberry Pi-controlled Robot :
# Building a Rover with Python, Linux, Motors, and Sensors.
# Sebastopol, CA: Maker Media, 2014. Print.
# Modified by Addison Sears-Collins
# Date April 17, 2019
# Open a new file to log the GPS data
f = open("gps_data.txt", "w")
gpsd = None
# Create a GPS Poller class.
class GpsPoller(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
global gpsd
gpsd = gps(mode=WATCH_ENABLE)
self.current_value = None
self.running = True
def run(self):
global gpsd
while gpsp.running:
gpsd.next()
if __name__ == '__main__':
gpsp = GpsPoller()
try:
gpsp.start()
while True:
f.write("Lat: " + str(gpsd.fix.latitude) # Log the latitude data
+ "\tLon: " + str(gpsd.fix.longitude) # Log the longitude data
+ "\tAlt: " + str(gpsd.fix.altitude / .3048) # Log the altitude in feet
+ "\n")
time.sleep(5)
except(KeyboardInterrupt, SystemExit):
f.close()
gpsp.running = False
gpsp.join()
Here is the code for the IMU I2C program on the Arduino, responsible for capturing Roll+Pitch+Yaw data and sending to the Raspberry Pi:
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BNO055.h>
#include <utility/imumaths.h>
/* This driver uses the Adafruit unified sensor library (Adafruit_Sensor),
which provides a common 'type' for sensor data and some helper functions.
To use this driver you will also need to download the Adafruit_Sensor
library and include it in your libraries folder.
You should also assign a unique ID to this sensor for use with
the Adafruit Sensor API so that you can identify this particular
sensor in any data logs, etc. To assign a unique ID, simply
provide an appropriate value in the constructor below (12345
is used by default in this example).
Connections
===========
Connect SCL to analog 5
Connect SDA to analog 4
Connect VDD to 3-5V DC
Connect GROUND to common ground
History
=======
2015/MAR/03 - First release (KTOWN)
2015/AUG/27 - Added calibration and system status helpers
@Author Modified by Addison Sears-Collins
@Date April 17, 2019
*/
/* Set the delay between fresh samples */
#define BNO055_SAMPLERATE_DELAY_MS (100)
Adafruit_BNO055 bno = Adafruit_BNO055(55);
// Flag used to stop the program
bool done = false;
// Make the Arduino a slave to the Raspberry Pi
int SLAVE_ADDRESS = 0X04;
// Toggle in-built LED for verifying program is working
int ledPin = 13;
// Data to send back to Raspberry Pi
byte imu_data[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
// Variables used for digit extraction
int roll = 0;
int pitch = 0;
int yaw = 0;
// Initialize the LED. This is used for testing.
boolean ledOn = false;
/**************************************************************************/
/*
This function ends the program
*/
/**************************************************************************/
void end_program() {
// Used for reading data from the serial monitor
char ch;
// Check to see if ! is available to be read
if (Serial.available()) {
// Read the character
ch = Serial.read();
// End the program if exclamation point is entered in the serial monitor
if (ch == '!') {
done = true;
Serial.println("Finished recording Roll+Pitch+Yaw data. Goodbye.");
}
}
}
/**************************************************************************/
/*
Displays some basic information on this sensor from the unified
sensor API sensor_t type (see Adafruit_Sensor for more information)
*/
/**************************************************************************/
void displaySensorDetails(void)
{
sensor_t sensor;
bno.getSensor(&sensor);
Serial.println("------------------------------------");
Serial.print ("Sensor: "); Serial.println(sensor.name);
Serial.print ("Driver Ver: "); Serial.println(sensor.version);
Serial.print ("Unique ID: "); Serial.println(sensor.sensor_id);
Serial.print ("Max Value: "); Serial.print(sensor.max_value); Serial.println(" xxx");
Serial.print ("Min Value: "); Serial.print(sensor.min_value); Serial.println(" xxx");
Serial.print ("Resolution: "); Serial.print(sensor.resolution); Serial.println(" xxx");
Serial.println("------------------------------------");
Serial.println("");
delay(500);
}
/**************************************************************************/
/*
Display some basic info about the sensor status
*/
/**************************************************************************/
void displaySensorStatus(void)
{
/* Get the system status values (mostly for debugging purposes) */
uint8_t system_status, self_test_results, system_error;
system_status = self_test_results = system_error = 0;
bno.getSystemStatus(&system_status, &self_test_results, &system_error);
/* Display the results in the Serial Monitor */
Serial.println("");
Serial.print("System Status: 0x");
Serial.println(system_status, HEX);
Serial.print("Self Test: 0x");
Serial.println(self_test_results, HEX);
Serial.print("System Error: 0x");
Serial.println(system_error, HEX);
Serial.println("");
delay(500);
}
/**************************************************************************/
/*
Display sensor calibration status
*/
/**************************************************************************/
void displayCalStatus(void)
{
/* Get the four calibration values (0..3) */
/* Any sensor data reporting 0 should be ignored, */
/* 3 means 'fully calibrated" */
uint8_t system, gyro, accel, mag;
system = gyro = accel = mag = 0;
bno.getCalibration(&system, &gyro, &accel, &mag);
/* The data should be ignored until the system calibration is > 0 */
Serial.print("\t");
if (!system)
{
Serial.print("! ");
}
/* Display the individual values */
Serial.print("Sys:");
Serial.print(system, DEC);
Serial.print(" G:");
Serial.print(gyro, DEC);
Serial.print(" A:");
Serial.print(accel, DEC);
Serial.print(" M:");
Serial.print(mag, DEC);
}
/**************************************************************************/
/*
Callback for received data
*/
/**************************************************************************/
void processMessage(int n) {
char ch = Wire.read();
if (ch == 'l') {
toggleLED();
}
}
/**************************************************************************/
/*
Method to toggle the LED. This is used for testing.
*/
/**************************************************************************/
void toggleLED() {
ledOn = ! ledOn;
digitalWrite(ledPin, ledOn);
}
/**************************************************************************/
/*
Code that executes when request is received from Raspberry Pi
*/
/**************************************************************************/
void sendIMUReading() {
Wire.write(imu_data, 12);
}
/**************************************************************************/
/*
Retrieves the digit of any position in an integer. The rightmost digit
has position 0. The second rightmost digit has position 1, etc.
e.g. Position 3 of integer 245984 is 5.
*/
/**************************************************************************/
byte getDigit(int num, int n) {
int int_digit, temp1, temp2;
byte byte_digit;
temp1 = pow(10, n+1);
int_digit = num % temp1;
if (n > 0) {
temp2 = pow(10, n);
int_digit = int_digit / temp2;
}
byte_digit = (byte) int_digit;
return byte_digit;
}
/**************************************************************************/
/*
Arduino setup function (automatically called at startup)
*/
/**************************************************************************/
void setup(void)
{
Serial.begin(9600);
Serial.println("Orientation Sensor Test"); Serial.println("");
/* Initialise the sensor */
if(!bno.begin())
{
/* There was a problem detecting the BNO055 ... check your connections */
Serial.print("Ooops, no BNO055 detected ... Check your wiring or I2C ADDR!");
while(1);
}
delay(1000);
/* Display some basic information on this sensor */
displaySensorDetails();
/* Optional: Display current status */
displaySensorStatus();
bno.setExtCrystalUse(true);
pinMode(ledPin, OUTPUT); // This is used for testing.
Wire.begin(SLAVE_ADDRESS); // Set up the Wire library and make Arduino the slave
/* Define the callbacks for i2c communication */
Wire.onReceive(processMessage); // Used to specify a function when data received from Master
Wire.onRequest(sendIMUReading); // Used to specify a function when the Master requests data
}
/**************************************************************************/
/*
Arduino loop function, called once 'setup' is complete
*/
/**************************************************************************/
void loop(void)
{
while (!done) {
/* Get a new sensor event */
sensors_event_t event;
bno.getEvent(&event);
/* Display the floating point data */
Serial.print("Yaw: ");
yaw = (int) event.orientation.x;
Serial.print(yaw);
if (yaw < 0) {
imu_data[8] = 1; // Capture the sign information
yaw = abs(yaw);
}
else {
imu_data[8] = 0;
}
if (yaw > 360) {
yaw = yaw - 360; // Calculate equivalent angle
}
Serial.print("\tPitch: ");
pitch = (int) event.orientation.y;
Serial.print(pitch);
if (pitch < 0) {
imu_data[4] = 1; // Capture the sign information
pitch = abs(pitch);
}
else {
imu_data[4] = 0;
}
Serial.print("\tRoll: ");
roll = (int) event.orientation.z;
Serial.print(roll);
if (roll < 0) {
imu_data[0] = 1; // Capture the sign information
roll = abs(roll);
}
else {
imu_data[0] = 0;
}
/* Optional: Display calibration status */
displayCalStatus();
/* Optional: Display sensor status (debug only) */
//displaySensorStatus();
/* New line for the next sample */
Serial.println("");
/* Update the IMU data by extracting each digit from the raw data */
imu_data[1] = getDigit(roll, 2);
imu_data[2] = getDigit(roll, 1);
imu_data[3] = getDigit(roll, 0);
imu_data[5] = getDigit(pitch, 2);
imu_data[6] = getDigit(pitch, 1);
imu_data[7] = getDigit(pitch, 0);
imu_data[9] = getDigit(yaw, 2);
imu_data[10] = getDigit(yaw, 1);
imu_data[11] = getDigit(yaw, 0);
/* Wait the specified delay before requesting nex data */
delay(BNO055_SAMPLERATE_DELAY_MS);
end_program();
}
// Do nothing
while (true){};
}
Here is the code for the I2C Python program on the Raspberry Pi, responsible for sending messages and requesting IMU data via I2C from the Arduino slave:
import smbus
import time
# Created by Addison Sears-Collins
# April 17, 2019
# Open a new file to log the IMU data
f = open("imu_data.txt", "w")
# for RPI version 1, use bus = smbus.SMBus(0)
bus = smbus.SMBus(1)
# This is the address we setup in the Arduino Program
SLAVE_ADDRESS = 0x04
def request_reading():
# Read a block of 12 bytes starting at SLAVE_ADDRESS, offset 0
reading = bus.read_i2c_block_data(SLAVE_ADDRESS, 0, 12)
# Extract the IMU reading data
if reading[0] < 1:
roll_sign = "+"
else:
roll_sign = "-"
roll_1 = reading[1]
roll_2 = reading[2]
roll_3 = reading[3]
if reading[4] < 1:
pitch_sign = "+"
else:
pitch_sign = "-"
pitch_1 = reading[5]
pitch_2 = reading[6]
pitch_3 = reading[7]
if reading[8] < 1:
yaw_sign = "+"
else:
yaw_sign = "-"
yaw_1 = reading[9]
yaw_2 = reading[10]
yaw_3 = reading[11]
# Print the IMU data to the console
print("Roll: " + roll_sign + str(roll_1) + str(roll_2) + str(roll_3) +
" Pitch: " + pitch_sign + str(pitch_1) + str(pitch_2) + str(pitch_3) +
" Yaw: " + yaw_sign + str(yaw_1) + str(yaw_2) + str(yaw_3))
try:
f.write("Roll: " + roll_sign + str(roll_1) + str(roll_2) + str(roll_3) +
" Pitch: " + pitch_sign + str(pitch_1) + str(pitch_2) + str(pitch_3) +
" Yaw: " + yaw_sign + str(yaw_1) + str(yaw_2) + str(yaw_3) + "\n")
except(KeyboardInterrupt, SystemExit):
f.close()
# Request IMU data every 5 seconds from the Arduino
while True:
# Used for testing: command = raw_input("Enter command: l - toggle LED, r - read IMU ")
# if command == 'l' :
# bus.write_byte(SLAVE_ADDRESS, ord('l'))
# elif command == 'r' :
request_reading()
time.sleep(5)
