Team Six/Final Paper
| Line 13: | Line 13: | ||
===Design=== | ===Design=== | ||
| − | We decided that modularity and easy integration would be | + | We decided that modularity and easy integration were very important for our design. Because of this we made 3 decisions about the code, that later helped us considerably: |
| + | **Multi-thread: | ||
| + | The code would be multithreaded, so that it could be more easily debugged, and the implementation of timeouts would be easier. | ||
| + | **Config file | ||
| + | We would have a main config file that would have all the configurations of the robot, such as number of the pins used by the sensors, proportional constants and gains, definitions of what was and was not present on the robot, etc. There was a considerable amount of macro preprocessing o the code for convenience. By changing a 0 to a 1, we would add new members to our sensors module or change how they were updated. | ||
| + | **Single main function | ||
| + | Since early in the development, we were trying to avoid write code that could not easily be reusable. Instead, we had a single main function on the source that took parameters, and those parameters would redirect the flow of the main function to run the tests. This made sure that all the code could be compiled together, and that it was easy to implement tests that made use of mutiple modules of the robot. | ||
| + | |||
| + | Everything on the code had "unity" test cases to show that they worked on the robot, and had also simple integration tests, to show that it didn't conflict with other parts of the code. This made it easy to debug when something was going wrong. | ||
| + | |||
| + | Since the beginning of the development we had a make file to compile all the code together, so that we wouldn't have to spend time later having to spend time figuring out what .o files were missing for our code to compile. | ||
===Threads=== | ===Threads=== | ||
We had 8 threads running on the robot. A high level decision thread, a motor control thread, a servo control thread, an actuator thread,, a logging thread, and two threads listening for interrupts for the encoders. | We had 8 threads running on the robot. A high level decision thread, a motor control thread, a servo control thread, an actuator thread,, a logging thread, and two threads listening for interrupts for the encoders. | ||
| + | |||
The data was shared among the threads by the use of shared memory (class public member variables, getters and setters). | The data was shared among the threads by the use of shared memory (class public member variables, getters and setters). | ||
| Line 22: | Line 33: | ||
Our sensors thread (or sensors module), updated the data from all our sensors and applied a simple filter to the data acquired. It update rate was considerably higher than the one from any of the other threads, since all of them depended on the data from the sensors. This thread was also responsible for updating the time elapsed (in microseconds), which would be used on the rest of the robot to calculate speed, or time elapsed for tasks. | Our sensors thread (or sensors module), updated the data from all our sensors and applied a simple filter to the data acquired. It update rate was considerably higher than the one from any of the other threads, since all of them depended on the data from the sensors. This thread was also responsible for updating the time elapsed (in microseconds), which would be used on the rest of the robot to calculate speed, or time elapsed for tasks. | ||
| − | All the sensors were private members of the main class of this thread, and the other threads could only access the data from the sensors by reading the public variables | + | All the sensors were private members of the main class of this thread, and the other threads could only access the data from the sensors by reading the public variables of this class. A pointer to the sensors module object was passed on the constructor of many of the other classes. |
Revision as of 07:42, 2 February 2015
Contents |
Introduction
Janky the cocoabot won the competition on MASLAB 2015. It had a very simple design and its code was very modular.
Software
The whole code can be found on our github repository: [1]
Language and Libraries
The whole code was written in C++11, with the exception of the code present in our Arduino, responsible for communicating with the color sensor, which was written in C.
We decided first to use C++ since most of the example code for the sensors was in C++ and no one in the group felt inclined about making use of JNI to interface with the hardware. Then later, we moved to C++11, to make use of the Thread support library "<thread>" and Date and time utilities "<chrono>".
We used Opencv for our computer vision code. We used standard C++ libraries, "string", "unistd", "cmath", "cstdio", "fstream", "iostream", "signal.h", besides libraries related to containers, such as vector.
Design
We decided that modularity and easy integration were very important for our design. Because of this we made 3 decisions about the code, that later helped us considerably:
- Multi-thread:
The code would be multithreaded, so that it could be more easily debugged, and the implementation of timeouts would be easier.
- Config file
We would have a main config file that would have all the configurations of the robot, such as number of the pins used by the sensors, proportional constants and gains, definitions of what was and was not present on the robot, etc. There was a considerable amount of macro preprocessing o the code for convenience. By changing a 0 to a 1, we would add new members to our sensors module or change how they were updated.
- Single main function
Since early in the development, we were trying to avoid write code that could not easily be reusable. Instead, we had a single main function on the source that took parameters, and those parameters would redirect the flow of the main function to run the tests. This made sure that all the code could be compiled together, and that it was easy to implement tests that made use of mutiple modules of the robot.
Everything on the code had "unity" test cases to show that they worked on the robot, and had also simple integration tests, to show that it didn't conflict with other parts of the code. This made it easy to debug when something was going wrong.
Since the beginning of the development we had a make file to compile all the code together, so that we wouldn't have to spend time later having to spend time figuring out what .o files were missing for our code to compile.
Threads
We had 8 threads running on the robot. A high level decision thread, a motor control thread, a servo control thread, an actuator thread,, a logging thread, and two threads listening for interrupts for the encoders.
The data was shared among the threads by the use of shared memory (class public member variables, getters and setters).
Sensors thread
Our sensors thread (or sensors module), updated the data from all our sensors and applied a simple filter to the data acquired. It update rate was considerably higher than the one from any of the other threads, since all of them depended on the data from the sensors. This thread was also responsible for updating the time elapsed (in microseconds), which would be used on the rest of the robot to calculate speed, or time elapsed for tasks.
All the sensors were private members of the main class of this thread, and the other threads could only access the data from the sensors by reading the public variables of this class. A pointer to the sensors module object was passed on the constructor of many of the other classes.
