Lab 1: The Artemis board and Bluetooth

• 1A: Setup and become familiar with the Arduino IDE and the Artemis board
• 1B: Establish communication between computer and the Artemis board through the Bluetooth stack
• 1B: Eestablish a framework for sending data from the Artemis to the computer

• Blink
• Apollo3 serial
• Apollo3 analogRead
• PDM MicrophoneOutput
• Simplified Electronic Tuner (Graduate lelel)

The following is a video that showcases the Artemis board flashing its blue LED light:

Video 1: artemis blinking

The following screenshot shows Artemis Echoing back what was sent to it:

Screenshot 1: artemis echoing

Firslty we have a screenshot of the Artemis' output from the temperature sensor and a photo of when it was sitting on the bench:

Screenshot 2: artemis temp sensor output while being on bench

Photo 1: artemis at the time of temp sensor output while being on bench

Secondly we have a screenshot of the Artemis' output from the temperature sensor and a photo of when it was being held in hand:

Screenshot 3: artemis temp sensor output when being held

Photo 2: artemis at the time of temp sensor output when being held

We can see that the leftmost measurement went from around 3-4 thousand, while on the bench, all the way up to 20 thousand when being held.

The following video showcases the difference in output when whistling next to the Artemis board:

Video 2: artemis reacting to sound

Screenshot 4: artemis microphone out ambient sounds of lab

Screenshot 5: artemis microphone out when whistling to it

We can see that the artemis is able of capturing differences in sound frequency.

To select the three frequencies that the tuner would identify I went to:
https://mixbutton.com/music-tools/frequency-and-pitch/music-note-to-frequency-chart
I selected the ones for the notes A, A# and B for the octave 7 so that the tuner would be able to work properly inside the noisy lab.

The following image is from mixbutton and it shows the frequency-note table:

Table 1: frequency-note table from mixbutton.com

Video 3: artemis reacting to 3500Hz

Video 4: artemis reacting to octave 7 A, A# and B

1. Echo
2. SEND_THREE_FLOATS
3. GET_TIME_MILLIS
4. Notification Handler
5. Effective Data Transfer
6. SEND_TIME_DATA
7. GET_TEMP_READINGS
8. Disscusion of differences
9. Effective Data Rate and Overhead (Graduate level)
10. Reliability (Graduate level)

After having created the virtual environment FastRobots_ble and sourced it with:

python3 -m pip install --user virtualenv

python3 -m venv FastRobots_ble

source FastRobots_ble/bin/activate

pip install numpy pyyaml colorama nest_asyncio bleak jupyterlab

Configured the MAC address of the Artemis and the new generated UUID (generation code shown in screenshot 6 below) in our connection.yaml file in our codebase.

Screenshot 5: MAC address of Artemis

Screenshot 6: left: conection.yaml file, right: command to generate new UUID

Additionally, in the ble_arduino.ino file, the following line was adjusted to reflect the aformentioned uuid:
#define BLE_UUID_TEST_SERVICE "1f43159b-1c6b-49dc-bf06-86977e06b15d"

The following screenshot showcases how to connect to the Artemis via Bluetooth by using the get_ble_controller() constructor and then the method ble.connect(). It also showcases the two example methods .receive_float() and .receive_string():

Screenshot 7: Establishment of Bluetooth connection between Artemis and Computer and example methods to read different types of GATT characteristics

Based on the output of GET_TIME_MILLIS, comparing it to that of SEND_TIME_DATA and GET_TEMP_READINGS we can immediately see that the latter 2 are much faster in terms of sampling. In those cases, the artemis immediately sends a whole batch of data with only one command being sent to it from the computer. This meanas that it can record a lot of data points quickkly and send them all together at the end. The negative side of that, however, is that the computer has to wait for the artemis to complete the collection of all data points before receiving even the first one. As always, there are tradeoffs. If we want faster sampling times but don't care as much about the delivery time, we'd go with the second method. If we wanted as "real-time" data as possible to be transmitted live, we'd go with the first option which samples more slowly.

Modifying the code like so, allows the determination of second method's data recording speed:

            for (int i = 0; i < 100; i++){ 
                temp_millis = millis();
                timestampArray[i] = temp_millis;
                }

                tx_estring_value.clear();
                tx_estring_value.append("T1: ");
                tx_estring_value.append(timestampArray[0]);
                tx_estring_value.append(" T2: ");
                tx_estring_value.append(timestampArray[99]);                
                tx_characteristic_string.writeValue(tx_estring_value.c_str());  
                        

In the following screenshot we can see the difference between the first and one hundredth recording to be 2ms.

Send a message from the computer and receive a reply from the Artemis board. Note the respective times for each event, calculate the data rate for 5-byte replies and 120-byte replies. Do many short packets introduce a lot of overhead? Do larger replies help to reduce overhead?

In the beginning, I wanted to see how long it takes for Artemis to send a 5 Byte and 120 Byte Estring to the computer. So I created the following two cases to see the time it takes for the message to get sent:

Through these, I learned that the time it takes to send 5 Bytes and 120 Bytes of data is 133 and 224 miscroseconds respectively.

        case GET_DATA_SPEED_5B:
            tx_estring_value.clear();
            tx_estring_value.append("ccccc");
            before_micros = micros();
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            after_micros = micros();
            total_micros = after_micros - before_micros;
            tx_estring_value.clear();
            tx_estring_value.append("The time it took to send 5 bytes is: "); 
            tx_estring_value.append((int)total_micros);
            tx_estring_value.append(" microseconds."); 
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            break;

        case GET_DATA_SPEED_120B:
            tx_estring_value.clear();
            tx_estring_value.append("cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc");
            before_micros = micros();
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            after_micros = micros();
            total_micros = after_micros - before_micros;
            tx_estring_value.clear();
            tx_estring_value.append("The time it took to send 120 bytes is: "); 
            tx_estring_value.append((int)total_micros);
            tx_estring_value.append(" microseconds."); 
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            break;
                        

To calculate the round-trip I make the following case which allows to send a number of messages back to back with a set sizeL

        case GET_BYTE_SPEED:
            int bytes;
            int num_of_packets;
            // Extract the next value from the command string as an integer
            success = robot_cmd.get_next_value(bytes);
            if (!success)
                return;

            // Extract the next value from the command string as an integer
            success = robot_cmd.get_next_value(num_of_packets);
            if (!success)
                return;

            tx_estring_value.clear();

            for (int i = 0; i < bytes; i++) {
                responseArray[i] = 'c';
            }

            for(int j=0; j < num_of_packets; j++){
            tx_estring_value.append(responseArray);
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            tx_estring_value.clear();
            }
            
            break;

                

I also created the following Notification Handler:

start = 0
dt = 0
def data_notification_handler(uuid, byteArray):
    string = ble.bytearray_to_string(byteArray)
    end = time.time()
    dt = end-start
    #print(string)
    print(dt)

Then, I ran the GET_BYTE_SPEED command 10 times for the following sizes: 5,10,20,40,60,80,100,120 and took the average round-trip time as well as data rate. The results are plotted below:

Plots 1,2

What happens when you send data at a higher rate from the robot to the computer? Does the computer read all the data published (without missing anything) from the Artemis board?

To test this out I made the following notification handler:

received_strings = []
def rapid_data_notification_handler(uuid, byteArray):
    string = ble.bytearray_to_string(byteArray)
    received_strings.append(string)

In addition to this, I also made a new case for the Artemis that would rapidly send 100 Estrings to the computer:

        case GET_RAPID_INFO:
            tx_estring_value.clear();

            for(int i=0;i < 100;i++){
            tx_estring_value.append(i);
            tx_characteristic_string.writeValue(tx_estring_value.c_str());
            tx_estring_value.clear();                            
            }            

            break;

From the following screenshot, we can clearly see that no messages were lost, even though there was a delay in receiving them. This indicates that there is some sort of Queue inside of the notification handler that just pops the oldest element at its faster speed.

Screenshot 17: All messages arrived to computer

Lab 1 successfully established the hardware and software foundation for the Fast Robots labs. The Bluetooth communication protocol is now functional and ready for extension in subsequent labs.

What challenged me the most was figuring out how to minimize the round-trip time for the Effective Data Rate and Overhead part.

I really like the incorporation of the "truest" time difference that I measured, which was the time it took the Artemis (and only the Artemis) to send the 5B vs 120B messages.