Team Name
Nerf Herders
Timeline
Summer 2020 – Fall 2020
Students
- Matthew Grossweiler
- Joyce Avila
- Henry Malinowski
- Daniel Scott
- Brandon Zimlich-Vining
Sponsor
Lockheed Martin
Abstract
Our sponsor has tasked our team with the design of an Advanced Control Actuation Drive System (ACADS). This system is used to control aerodynamic surfaces such as fins and canards and to provide precise and instant control of said components. The ACADS will allow a user to enter a degree of rotation for multiple motors and provide various statistical variables as feedback as well as logging information of performance. A crucial section of this project is the introduction of a regenerative braking circuit which allow for the system to be more efficient. The system shall report the amount of regenerated voltage back to the client. The multiple motors will work as a four-quadrant operation meaning both the motors and the regenerative circuits will work in forward and reverse.
Background
Motors are used everywhere to convert electrical energy into mechanical energy. Any device that requires physical movement requires a motor of some sort. In aviation, one of the critical components that use motors control the motion of the fins and rudders for navigating the aircraft in the desired direction. Motors are controlled by actuators, which provide signals to motor so that it knows how to move and the direction to take.
Our sponsor has become interested in using motors that have four quadrant control to conserve energy in these components. Tesla has made the concept of regenerative breaking mainstream as they use the concept to save energy in many of car designs by converting energy from when the car brakes to charge the battery of the electric vehicle.
The reason for interest is the ability for these motors conserve net energy to run the motor. The physics behind this device is that the motor is generating kinetic energy when negative forces are applied when the motor changes direction. The kinetic energy from this will be converted to electrical energy and stored in a battery in the motor for future use of the motor so less incoming electricity is needed. This device is sought after because in any type of aerial vehicle electrical energy is a scare resource. Saving electricity in one component means less consumption or more redirected to another system in the vehicle.
In order to make this a reality our sponsor needs to create interfaces to simulate the regenerative motors as well as actuators to control those motors so they can monitor and test them and get a proof of concept. As our sponsor, they will be fully involved in all aspect of the project to ensure the work is within their specifications. The end result they are hoping for is a proof of concept they then can deploy in their aviation designs.
Project Requirements
- Record data (motor position, input/output voltages, status, etc.) from the system and display it on the user interface.
- Have user input and data output be calculated and displayed in real time.
- Have an option to export data and logs.
- Allow input from the user control motor position from -40° to 40° in 1° increments.
- Web server as well as data collection and storage hosted on the hardware itself.
- Access the user interface webpage from any web browser.
- The user should be able to turn off the system at any time through an abort command or shutdown sequence.
- The motors should be able to detect current position and/or go to a determined position (0°) when the system is turned on.
- The system should detect and display any errors or malfunctions that occur.
- The system should be able to drive two four-quadrant motors.
System Overview
This project is split into 4 distinct layers in which make up the ACADS system. The Front-End Layer handles all user interaction and receives all input for the system. The idea is to create a mechanism in which the user can accurately control the ACADS system as well as receive feedback on what the system is doing. The Communications Layer handles the data transmissions between the Front-End and Micro-controller. The Micro-controller Layer is responsible for receiving and sending signals to and from the hardware. The Motor-controller Layer the composition of physical hardware components that drive the motors.
The Front-End Layer is responsible for all user interaction. The layer consists of a web interface which has a mechanism to control the position of the motors as well as displays current system information and statistics. The interface will also be able to retrieve system logs for troubleshooting purposes. The Front-End communications with the device control loop using periodic AJAX calls where it receives JSON as a response. The web server in which runs the interface will run on the hardware of the carrier board.
The communications layer defines the communication between the web interface and the control loop. The control loops purpose is to listen for inbound TCP connections from the web interface as well listen for inbound signals from the hardware. The communications between the control loop and the web interface. On inbound TCP connection the control loop will send JSON as a response with data collected and parsed from inbound signals.
The Micro-controller layer consists of two interconnected parts. The first part is a carrier board which runs an ARM version of Linux. The second part is an interconnected micro-controller board. The reason for the two parts was to facilitate the number of signals as the carrier board didn’t have enough. the micro-controller boards function is to receive all signals from hardware layers, encode then send a informational response to the carrier board control loop.
The motor controller layer is the physical hardware which drives each of the two motors which the primary goal is to generate enough voltage to drive the motors as well as host a slew of different sensors. The inputs and outputs to the Motor-controller layer consists of commands passed through the other layers from the users, and signals sent from various hardware components back to the control loop to be logged and relayed to the user interface.
Results
With many discussions between team member of our team and various others, we decided to use an approach in which we start at one end of the project opposite the Electrical team and work towards a center point. As a result of this our goal was very clear, to make a great user interface and begin work on the I2C communication. In the Demo video below, you can see that we accomplished our goals in making an interface for the user that will allow commands to be sent to the control hardware and read back the required variables to be displayed. Afterwards we can confidently hand off this project to the next team knowing the work we did will serve as a solid base for them to work off and continue making progress.
Future Work
There are still several pieces of this project remaining that will need to be worked on in the future. When looking at this project it’s built that the web interface and backend then handoff to the project worked on by the electrical engineering team. Since no ability to do simulations and being able to test with actual hardware has been done yet most of the future work needing to be done has to do with integrating the two projects together.
A major piece of this project that still needs yet to be completed is the motor control algorithms. The work on this consists of using two available sensors in order to determine position as well as being able to control speed and direction. This will be a crucial element to a completed project. The sensors available to detect position are the use of hall effect sensors in the motor, as well as a motor encoder which will also feed data via GPIO. The hall effect sensors determine the quadrant in which the motor is located, and the encoder will determine speed and direction. So with that data being available the idea is to be able to control the motors in an efficient matter and being able to find the proper as given in the interface.
More work that will need to be done in the results of changing some of the outputs on the web interface. Since we had no simulation, our component monitors where developed as a basis of what we were able to determine from the documentation. actual hardware is in place a clear view of the type of sensors available and what types of data they will have at their disposal to show more information to the user.
When simulations are available, we will also have to added in more logs to give a verbose outlook of what is going on with the system. Log entries should be placed for each determined signal using the predefined log function as well as the results received from the Tiva C. Once incoming data is called back the logs will be reflected in the user interface.
More future work that will be needed is they will need to be updates to the Tiva C code as the project progresses. We have an idea of the pin layout and did incorporate that into the project, but from recent reports it looks like the project is evolving. Because of the evolution of the project more than likely the red board code will need to have some changes to things such as pin layouts. As added information is received there will also need to be updates to the code base of the Tiva C to receive the information, encode it as a byte structure and send it on to the API so the results can be displayed in the user interface.
Project Files
Project Charter (link)
System Requirements Specification (link)
Architectural Design Specification (link)
Detailed Design Specification (link)
Poster (link)
References
Any references go here, properly formatted
