Software framework implementation for a robot that uses different development boards - Gomes, Pedro Miguel Francisco (2019)
A software framework is a concrete or conceptual platform where common code with generic functionality can be selectively specialized or overridden by developers or users. Frameworks take the form of libraries where a well-defined application program interface is reusable anywhere within the software under development. A user can extend the framework but not modify the code. The purpose of software framework is to simplify the development environment, allowing developers to dedicate their efforts to the project requirements, rather than dealing with the framework’s mundane, repetitive functions and libraries. A differential wheeled robot is a mobile robot whose movement is based on two separately driven wheels placed on either side of the robot body. It can thus change its direction by varying the relative rate of rotation of its wheels and hence does not require an additional steering motion. If both the wheels are driven in the same direction and speed, the robot will go in a straight line. If both wheels are turned with equal speed in opposite directions, the robot will rotate about the central point of the axis. Otherwise, depending on the speed of rotation and its direction, the center of rotation may fall anywhere on the line defined by the two contact points of the wheels. The objective of this thesis, is to create a software framework for a wheeled robot, where we can change its development board, without having to make many changes in the code that is used to control the robot. The composition of the robot is: a development board, that allows the control of any electronic devices, that are connected to it; some sensors to detect obstacles; two motors to move the robot; a motor driver to power and control the motors individually; a chassis to assemble the robot; and a battery to power all the electronic devices. The most important device of the robot is the development board, which allows the control of every single electronic device connected to it through a program. In this project we use three development boards, which are: Arduino UNO rev3, NodeMCU ESP8266 v1.0 and Raspberry Pi 3 Model B+. The programming language used to control the devices and the boards is the C++ programming language, because it can be used with all of them. Since all the boards have a different external/internal design, there are some issues that we need to fix with the help of external hardware. Other important devices are the sensors to detect objects, which are: the sensor HC-SR04, which uses ultrasonic waves; and, the sensor Sharp GP2Y0A41SK0F, which uses infrared light. The framework also covers two types of servo motors: one that can continuously rotate; and the other one that only rotates about half a circle. The servo motors can be used, for instance, to rotate a range sensor. Then we need two DC motors to move the vehicle. To power up these DC motors, which are controlled with a PWM signal, we need to connect them to a device called motor driver which is connected to a battery. Finally, to assemble the robot we just need to connect all the devices to the development board and attach them to the chassis. This software framework was created with the purpose of programmatically connect every device (any sensor, motor or other device) to the development board and allow a user to do minimal code changes when he has the need to change the development board. All the devices that the framework supports have a datasheet explaining their behavior and operation, so that it was possible to develop a library to operate and control the device. By joining all these libraries together we have the framework presented here. The experimental methodology, used in two case studies, will show the features and the limitations of the framework. The first case study shows that the changes the user needs to do when changing boards are minimal but because all the development boards are different, there are some things we can’t program without having to make the user of the framework, sacrifice his GPIO connection choices. The second case study, shows that because of how the development boards work internally, there are some things that aren’t possible to program to work like they were designed as the other development boards.