+ ← + + Requirements + + Open UAS 2.0 + + → +
OpenUAS + ← + + Requirements + + Open UAS 2.0 + + → +
OpenUAS The main objective of the OpenUAS 3.0 model is to be affordable and simplistic in materials. The model is designed to serve as a kit with a set of detailed instructions. The 3.0 model is largely composed of posterboard and 3D printed materials. The instructions for this model breaks down each step with details, tips, and visuals to aid the reader's process of assembling the model.
+ ← + + Open UAS 2.0 +
OpenUAS #Open UAS 2.0
The OpenUAS 2.0 model has a major foucs on the use of 3D printed parts to create a framework that can be easily modfided and printed to meet the needs anyone wanting to use the model.
There were a few issues that arose with the construction of the 2nd iteration of the OpenUAS project. These were mostly forecasted issues the team had planned mitigation methods for, but that ended up not working the intended way. There were a few issues that arose that were not foreseen but directly related to the predicted issues.
The issues we were faced with all revolved around the tail of the UAS. The original idea was to create a tail that's lightweight and easily replaceable. In order to do this the tail was broken down into a few different parts. These included the carbon fiber support rod, and 3D printed parts including: tail supports, tail feather support, and connection rod of the tail.
The first issue that arose was the amount of twist that appeared in the end of the tail around the tail feather piece. We predicted that there would be a small amount of twist due to using 3 Carbon Fibers rods as the main part of the tail. We believed that it would be negligible, however once the tail was assembled it was clear the twisting was going to be more of an issue then originally predicted.
One way we attempted to fix this issue was adding more of the tail support pieces in order to add more stiffness along the carbon fiber rods. While this did decrease the amount of twist noticeably, it still did not remove the problem. Other proposed ideas for fixing for the issue was adding a stiffer such as balsa wood or popsicle sticks was taken into consideration however, while working to find a solution the team ran into another issue.
Another issue we ran into was not one that we had predicted. When designing the 3D pieces the team created generic ribs that would be used to create the body of the UAS. There were a few assumptions made however when applying the concept of the hinge ribs with the interfacing parts such as the back connection point and the nose cone connection.
One of the assumptions made was that the 3D printed parts would be printed to a high enough tolerance that connecting with glue while flush with each other would be a quick and easy method of connecting and if needed later removing from each other without having to completely disassemble the body or tail parts. This proved to not be the case when the time came to connect the two parts.
One thing that had been overlooked with the 3D printed parts was the flexibility of the pieces. ABS was the material used to print the ribs and the connection piece and while the material considered relatively stiff for our needs the material is still able to bend or warp without losing its shape if a force applied to it. When we went to attach the parts together, we clamped the two of them together; it became hard to hold them together while the glue set and the final product was not within the desired tolerance of connection. Instead of a solid connection we had half of the connection bowing outwards towards the end of the tail instead of inwards toward the body like we had planned.
The issue was made worse when the control surfaces were added to the tail feather and it was clear the added weight was making the problem worse. Much like the twisting problem we had a number of proposed ideas in order to correct the issue. Looking at table 1.
| Solution | How it would fix the problem | Why we went with it or not | Was it the final solution we picked? |
|---|---|---|---|
| Elastic bands | The elastic bands would be fastened to the top of the tail piece and then would be wrapped and unwrapped around a part connected to the body of the UAS when accessing the electronics. | After creating a mock-up setup of the idea using string we determined that the flexibility of the ABS material was keeping us from properly tensioning the string and would not be a great solution to the issue. | No |
| Velcro | The top surface of the body and the tail connection piece are meant to be flush when assembled. In order to keep the tail piece from bowing backwards velcro would be placed along the top of the back rib and the connection tailpiece. When we need access to the electronics and interior of the UAS the top piece of velcro would be removed in order to allow the hinge to work correctly. | When we tested the idea by placing velcro pieces on the surface it was seen that the bowing still occurred. Not only that but when moving the UAS the velcro came loose and was not effective. | No |
| Rod method 1 | This method would include attaching another carbon fiber rod at the base of the body and the end of the tail feather diagonally to force the tail piece upwards. | This method would have been hard to add to the current design as is and runs the risk of breaking during rough landings. | No |
| Rod method 2 | Similar to the 1st rod method the 2nd would involve adding a new rod. A big difference in the method would be removing the 3 smaller carbon fiber rods and replacing them with one large rod that would run from the nose cone to the end of the tail.Instead of adding the diagonal support from the body to the tail. | Like the first rod method we would have to re-design the 3D printed parts. In this case we decided that this approach would be effective in fixing the issue in the smallest amount of time and amount of labor. It would also result in fixing the issue with the twist of the tail feather. | Yes |
After mocking up and reviewing different ideas between the sub-teams we determined that using the 2nd rod method would be our best course of action. This was based on the fact the rod would not only fix the issue with the bowing but it would also address the twisting problem in the tail at the same time.
We were not able to mock up this idea in our lab space however, we were able to compare the stiffness from the assembled tail and the singular rod we would add. We did this by applying a small amount of force on each of the structures to determine how much bending would occur. (should we measure the amount of bending for quantitative data(plus another table would be cool)) +Once we determined that the singular rod would be the best solution to reduce the bowing in the part we took a look at the twisting. In order to incorporate the rod we had to redesign the tail feather and connection parts. Our theory is that by taking the time to redesign the tail feather we can reduce the twisting at the end of the tail. Primary because the bowing and bending of the 3 carbon fiber rods will no longer be a problem when the tail is one solid rod along the length of the UAS’s body and tail.
After the assmebly of the new tail was completed we came across another issue with the 2.0 model. The issue this time instead of being around the tail was the on the body/fuselogde of the model. This model includes the use of neodynimum magnets inorder to keep the clam shell design closed during however, it was discovered that the smaller magnets were not strong enough to hold the shell closed under minor turbulance.
| Solution | How it would fix the problem | Why we went with it or not | Was it the final solution we picked? |
|---|---|---|---|
| Velcro | The Velcro would be able to hold the two halfs closed during flight | We chose not to go with this soultion as there was not enough surface area for the velcro to be affective. | No |
| Zip Ties | Zip Ties is somthing we chose to use as a short term solution in order to close the clam shell | long term the soultion this is not sustanble as the zip ties would have to be cut and a new one to replace them each time we wanted access to the electronics | No |
| 3D Printed Part | A 3D printed part would be more of an insert piece that would screwed together in order to keep the two halfs closed | This was our chosen soultion as it would not add a lot to the system and would a good fit for the part | Yes |
The changes made during this round were needed for fine tuning of components for the function of the model instead of fixing dramic issues with model like previous changes.
After some observions of other air crafts we noticed that the motors for the propeller may benfit from an angled motor instead of a completly straight faceing. We angled our motor to the right and directed down of the model. In order to do this we added nuts to the motor bolts to create the spacing for the angle. This inculded four mounting points and a total of 5 nuts. Two of the nuts were placed on the upper right corner and the upper left corner.
+ ← + + Open UAS 1.0 + + Open UAS 3.0 + + → +
OpenUAS + Open UAS 1.0 + + → +
OpenUAS 
+ ← + + Electrical + + PID Tuning + + → +
OpenUAS + ← + + Components +
OpenUAS Here, you will find details on the electrical system on the current OpenUAS vehicle, including wiring diagrams, recommended components, and device pin-outs.
+ Components + + → +
OpenUAS OpenUAS
Dr. Kristin Y. Rozier
No open source UAS options exist that are fixed-wing and accessible (conceptually) to the general public. Some similar, available UAS’ are the Albatross (created and sold commercially by Applied Aeronautics) and Razor (created a UVA). Open source software options already available include ArduPilot and PX4.
We are producing an open-source, COTS UAS that can be used for education and research purposes; the UAS shall only consist of components available to the general public.
OpenUAS | Semester Week Beginning | Major Objectives |
|---|---|
| 01/17 | |
| 01/24 | |
| 01/31 | |
| 02/07 | Develop new position advertisements |
| 02/14 | Send out new member applications |
| 02/21 | |
| 02/28 | Host interviews, preliminary design review, Test flight time frame |
| 03/07 | Host interviews, first draft of documentation due |
| 03/14 | Spring Break |
| 03/21 | Review documentation, send out acceptance letters |
| 03/28 | |
| 04/04 | Onboard new students |
| 04/11 | Final Draft of documentation due |
| 04/18 | New flight model to be finalized |
| 04/25 | Order parts for new model (reduces strain on next semester) |
| 05/02 | Ensure documentation is wrapped up and ready to go |
OpenUAS The OpenUAS project is an undergraduate research initiative to design and build an open source, fixed wing unmanned aerial system ✈️.
Please read this document over if you are new to the OpenUAS team. It +contains important checklists, resources, and advice. If you have +questions about anything in this document, reach out to the Project +Leader or your respective Team Leader - contact information is listed +below.
| Role | Name | |
|---|---|---|
| Electrical/Software Team Leader | Varad Kulkarni | varadk@iastate.edu |
| Design Team Leader | Allison Howard | alhoward@iastate.edu |
| Manufacturing Team Leader | Sydney Turner | sydtur9@iastate.edu |
After officially becoming a member of the team, you will be added to our
+communication channels and documentation repositories.
Please verify that you are added to...
the Github repositiory
the Google Drive folder
the ISU Network Drive folder
the emailing list
the main Groupme chat
your team Groupme chat
Reach out to the Project Leader if you do not have access to any of the +above items.
Once you are added to the Google Drive folder and the Github repository, +you have access to all of the team's documentation over the past 3+ +years. This can be daunting at first, so please read the following +sections if you are confused about where to start.
The OpenUAS team keeps much of our formal documentation in Github.
+Github is a tool that hosts git, a file versioning system. For more
+information on this, this website does a good job explaining Github and
+git:
+https://blog.devmountain.com/git-vs-github-whats-the-difference/ (opens new window).
+After you have made a Github account and are added to the team's
+repository, start to take a look at our documentation. One good place to
+start is with the final reports created each semester by the team. These
+reports provide a variety of information including an overview of the
+project and teams, the status of the project, and the progress made by
+each sub-team for that semester. It also contains valuable lessons
+learned which may help you as you begin work on the project. The path to
+these reports is:
+OpenUAS/Documentation/Final_Reports.
+Another good place to explore in the Github repository are the progress
+reports made by each team member (under the ProgressReports directory).
+These reports are great insight on what a member of the OpenUAS team
+works on on a week-to-week basis. You will also have to create your own
+progress reports as soon as you start receiving credit for the research,
+so these are helpful to look at to know what is expected. For
+information on creating these items, see Section 4 below.
The OpenUAS Google Drive folder contains more of the team's informal +documentation and work. In this folder, you can find everything from +performance calculations spreadsheets to possible design configurations. +There isn't one area that you should look at right away, but as you have +time, explore the directories within this drive folder. You will learn a +lot about what the team has worked on.
Every student on the team is required by Dr. Rozier to create personal +documentation during their time on the team. This includes weekly +reports as well as a semester plan. Each is described in detail below. +There are templates for these reports found in the Github repository +under the ProgressReports directory. Create your own directory (folder) +within the ProgressReports directory with your initials as the name. +Then, copy both the weekly reports template and the semester plan +template into your folder and fill in the necessary information. These +documents are created in markdown, a fairly simple markup language. If +you are having issues understanding this format, this resource might be +useful for you: https://daringfireball.net/projects/markdown/syntax (opens new window). +It is critical that you complete this documentation by the end of the +semester as this is what Dr. Rozier uses to give you a grade for the +research credit.
Weekly reports are exactly what they sound like: a written update on +what you did during the week. This includes your objectives and +deliverables from the previous week and if you completed them. You are +also required to describe any road blocks you faced during the week and +describe in more detail your overall accomplishments for the week. +Finally, you create objectvies and deliverables for the next week.
At the beginning of each semester, you are required to create a semester +plan. This semester plan contains your goals, deliverables, and plan to +mitigate risks during the semester. There is also a table-calendar to +fill out. It is often necessary to update your semester plan multiple +times during the semester as new deliverables or tasks arise.
Ask questions constantly - no question is dumb. Everyone on the team +is willing to help you!
Look into the Git and LaTeX resources early. It is up to you to make +sure you understand these tools.
Keep up-to-date on your weekly reports. It can be easy to get behind +on this documentation, but it is a pain to make up as it is often +difficult to remember what you worked on weeks ago.
Find what you are passion about on the team. If you joined the team +in one area but find out your interests are elsewhere on the +project, talk to your Team or Project Leader about eventually +switching areas.
Ask Dr. Rozier for career advice. She is very knowledgeable and is +always willing to help.
+ Project Charter + + → +
OpenUAS Holes don'e align -> Tail/Carbon Fiber
Screws don't match given instructions
Tail friction -> takes off structure
Propellor touches the ground
Tubes glued together -> crushed in (harder to get wires in and through the wing)
Excess adhesive found
Multiple locations without proper drilled holes through the carbon fiber
Largest control surface does not lay flat against the rest of the wing like others
Dimensions wrong
No wiring diagram
Servo wires don't reach areas needed
Not enough parts (or wrong parts given)
Screws don't fit
Propellor assembly incorrect
Series battery failure
ESC?
OpenUAS Better get working on this soon
Acronym
LVC - Low Voltage Cutoff - A component/circuit that cuts power to a component to stop it from overdrawing a battery that is low on power.
BEC - Battery Eliminator Circuit - Takes out the need for another battery when powering multiple circuits, delivers electrical power to other circuits. Some work as linear voltage regulators (5 volts for example) for parts that require lower voltages (like servos for example). Typically paired with motors to allow control and the motor to be powered by the same battery instead of needing two batteries. Additionally, BECs can include a LVC circuit to help stop a motor from overdrawing a battery during flight. This allows a pilot to fly "dead-stick," or with the control surfaces only, instead of losing total power. A BEC with a LVC is usually a part of an ESC.
ESC - Electronics Speed Controller - Used to regulate the input given from the controller to the motor. It also has several cutoff safety features, including a low battery cutoff, so that the control surfaces of the plane can still be used for an emergency landing.
All things battery: We use multiple Lithium Polymer batteries for the Open UAS (Unmanned Aerial System) to power the system. The standard for our smaller craft is a 3 cell battery. The bigger batteries are a 6 cell battery. Each cell contributes to an optimal 3.7 volts and a max of 4.2 volts. The batteries have various amps associated with them (see battery documents).
Item List +BECs - Servo BEC and Pixhawk/Power Module BEC +ESC +Power Module +Telemetry +Receiver +Flight Computer - Pixhawk
Servos - They controls the Elevators, Rudders, and Alierons. Consist of a servo horn, a connection, and the control surface. Require mounts or something to keep them set in place (not velco).
Motors - We currently have three, with the smallest being no bigger than your thumb, and the largest nearly the size of a fist. The largest is attached to the Albatross, while the smaller two will be desired for the smaller Open UAS models.
Batteries
GPS
R2U2 - The eventual health management system that will be added to the Open UAS (Professor Rozier's research). A little larger than a credit card, this unit is known for producing a large amount of heat.
Electronics Tools +Multimeter +Wire Cutter - Cut wires, also can be used to strip a wire. Do not cut live wires.
Wire Stripper - Strip the outer insulation (jacket) off the wire, incredibly convenient, adjustable, fast.
Battery Charger - Blue, charges one battery at a time. Contains several preset options for batteries in the lab. Requires multiple connectors due to different battery brands. See manual next to the charger for in-depth instructions, or the battery documents for shortcuts on battery charging and discharging.
Soldering
Splicing
Twist Cap - Used to combine all of the power and ground (separately) wires into one bundle and use a single output wire to connect the main circuit. To properly use, combine all of the wires and twist in, as the thread in the cap will help hold the wires in place. May require a few attempts to get the wire twisted correctly and secured within the cap.
Plug and Play - Goal of the electronics system for the Open UAS. The easier it is to configure (and re-configure when changing/updating parts), the better it will be for future teams and individuals who use it (open source).
OpenUAS These are all the solidworks parts for the telemetry assembly
OpenUAS Solidworks Files for the X8R transceiver
OpenUAS Solidworks models for the components of the Iron Bird V2
OpenUAS power(1) -> power(2)
power(5) -> power(6), spi(7), usb(4), telem1(6), telem2(6), spkt/dsm(2), buzzer(2), serial4/5(6), gps(6), can(4), i2c(4), adc6.6(3), adc3.3(5), i2c(1) [weak connection]
adc3.3(3) -> adc3.3(5)
OpenUAS | Part Name | Weight (Pounds / Ounces) |
|---|---|
| Battery | 1 / 7.1 |
| Pixhawk | 0 / 1.4 |
| PDB | 0 / 0.7 |
| BEC (backup) | 0 / 0.3 |
| ESC (Servo) | 0 / 1.0 |
| ESC (3s motor) | 0 / 3.0 |
| ESC (8s motor) | |
| Motor | 0 / 3.8 |
| Airspeed Sensor | 0 / 0.2 |
| GPS Module | 0 / 1.0 |
| Long-Range UAV Telemetry | 0 / 1.8 |
| Thin Metal Wing Servo | 0 / 0.5 |
| Flite Test Servo | 0 / 0.2 |
| X8R Telemetry Module | 0 / 0.8 |
| Servo Rail Connector | 0 / 1.9 |
| Total (for 8s system) |
|---|
| Total (for 3s system) |
|---|
| 2 / 8.4 |
OpenUAS 
+A more in depth explanation about wiring the pixhawk 4 can be found on the pixhawk website, here (opens new window).
OpenUAS 
Powering the Pixhawk (opens new window)
This image has the basic wiring set up for the pixhawk. There are a couple differences between this version and what the Open UAS uses.
OpenUAS TODO:
Starting with our CFD data, we can use a Thrust equals drag approximation to estimate the thrust requried at a given Velocity. The equation used is:
Where:
We can also use this curve to find our max endurance and max range cruise velocities. Max endurance happens at the minimum power draw. This can be found by multiplying the thrust required curve by velocity again, and finding the minimum of the curve. Max range occurs at the of the thrust requried curve +Plotting this for a range of velocities and using our aircraft CD0 value generated from CFD, we get this curve:
Using our Max lift coeficient CLmax, we can find our stall velocitie as well. The stall velocity is higher than both cruise velocities, so an arbitray velocity was picked by the pilot that was a comfortable distance above stall velocity. This is 45 mph.
note, current is in units +of amps, and efficiency is in percent effeciency. The current is the current draw from the battery and the efficiency is the total efficiency (i.e) eta_prop*eta_motor
Current draw at Cruise for Badass 560 12x10: 5.1
+Current draw at Cruise for Badass 560, 13x10: 5
+Current draw at Cruise for Badass 560, 14x10: 4.7
+Current draw at Cruise for Badass 560, 14x12: 4.5
+
+Efficiency at Cruise for Badass 560, 12x10: 53.6
+Efficiency at Cruise for Badass 560, 13x10: 53
+Efficiency at Cruise for Badass 560, 14x10: 51.6
+Efficiency at Cruise for Badass 560, 14x12: 55.5
+Lowest current draw: 14x12 @ 4.5
Highest Efficiency: 14x12 @55.5
Current draw at Cruise for badass 650, 12x10: 5.1
+Current draw at Cruise for badass 650, 13x10: 4.7
+Current draw at Cruise for badass 650, 14x10: 4.4
+Current draw at Cruise for badass 650, 14x12: 4.9
+
+Efficiency at Cruise for badass 650, 12x10: 54.2
+Efficiency at Cruise for badass 650, 13x10: 53.6
+Efficiency at Cruise for badass 650, 14x10: 51.5
+Efficiency at Cruise for badass 650, 14x12: 57
+Lowest current draw: 14x10 @4.4
Highest Efficiency: 14x12 @57
Current draw at Cruise for Badass 710kv, 12x10: 4.8
+Current draw at Cruise for Badass 710kv, 13x10: 4.8
+Current draw at Cruise for 14x10, 14x10: 4.9
+Current draw at Cruise for Badass 710kv, 14x12: 4.5
+
+Efficiency at Cruise for Badass 710kv, 12x10: 56
+Efficiency at Cruise for Badass 710kv, 13x10: 55.8
+Efficiency at Cruise for 14x10, 14x10: 55.4
+Efficiency at Cruise for Badass 710kv, 14x12: 57.3
+Lowest current draw: 12x10&13x10 @ 4.8
+Highest Efficiency: 14x12 @ 57.3
Current draw at Cruise for Hacker 900kv, 12x10: 5.2
+Current draw at Cruise for Hacker 900kv, 13x10: 4.8
+Current draw at Cruise for Hacker 900kv, 14x10: 5.2
+Current draw at Cruise for Hacker 900kv, 14x12: 5.2
+Current draw at Cruise for Hacker 900kv, 15x8: 4
+
+Efficiency at Cruise for Hacker 900kv, 12x10: 54.2
+Efficiency at Cruise for Hacker 900kv, 13x10: 53.3
+Efficiency at Cruise for Hacker 900kv, 14x10: 53.5
+Efficiency at Cruise for Hacker 900kv, 14x12: 55.9
+Efficiency at Cruise for Hacker 900kv, 15x8: 37.9
+Lowest current draw 15x8 @ 4
Highest Efficiency 14x12 @ 55.9
Current draw at Cruise for badass 790, 12x10: 5.1
+Current draw at Cruise for badass 790, 13x10: 5.2
+Current draw at Cruise for badass 790, 14x12: 5.8
+Current draw at Cruise for badass 790, 15x8: 4.5
+
+Efficiency at Cruise for badass 790, 12x10: 51.2
+Efficiency at Cruise for badass 790, 13x10: 51.1
+Efficiency at Cruise for badass 790, 14x12: 55.1
+Efficiency at Cruise for badass 790, 15x8: 34.3
+Lowest current draw: 15x8 @4.5
Highest Efficiency: 14x12 @55.1
Current draw at Cruise for badass 970, 12x10: 5.4
+Current draw at Cruise for badass 970, 13x10: 5.5
+Current draw at Cruise for badass 970, 14x10: 5.3
+Current draw at Cruise for badass 970, 14x12: 5.5
+Current draw at Cruise for badass 970, 15x8: 5.2
+
+Efficiency at Cruise for badass 970, 12x10: 48.4
+Efficiency at Cruise for badass 970, 13x10: 48.5
+Efficiency at Cruise for badass 970, 14x10: 47.4
+Efficiency at Cruise for badass 970, 14x12: 50.8
+Efficiency at Cruise for badass 970, 15x8: 34.2
+Lowest current draw: 15x8: 5.2
Highest Efficiency: 14x12 @ 50.8
TODO:
OpenUAS Provides power to the system.
Specs:
https://web.mit.edu/evt/summary_battery_specifications.pdf
Common Issues / Solutions:
Used to control the motor. Powered from the 12 V line. Accepts input as PWM from the pixhawk in order to control the speed the motor runs at. Will want an ESC that also has a BEC so that it can power the servo rail.
Specs:
https://oscarliang.com/choose-esc-racing-drones/
Common Issues / Solutions:
Used to drop voltage, in this case from 12 V to 5 V. Power goes in from the 12 V and out to power the servos / PDB / anything else that would need 5 V. These external BECs are used for LiPo Batteries of about 3S or less.
Specs:
https://www.dimensionengineering.com/info/bec
Common Issues / Solutions:
Used to send power to different parts of the circuit and stand as a safety net. Contains a fuse that would burn out the chip before damaging the rest of the system. Powered from the 5 V line from the BEC. Has the 12 V line run through it to monitor the power. Sends power to the Pixhawk.
The main purpose of our PDB seems to be to convert the power so we can power the pixhawk. I would jut suggest choosing the one that would come along with the pixhawk.
Specs:
Common Issues / Solutions:
Provides the thrust for the UAS.
Specs:
Common Issues / Solutions:
Contibutes to the thrust of the UAS
Specs:
Common Issues / Solutions:
List:
OpenUAS To open the assembly, download everything in this folder. Following the download, you will see two platforms with various color coded shapes. Parts of similar color must stay near each other, with the mild exception to the ESC and Motor along with the 6 cell battery and the 10 gage capable Wago. They can be on different levels as long as the cords reach both the motor and feed back into the circuit. Additionally the 6-cell battery and the 2 3-cell batteries are a "one or the other" option. This allows for multiple electronics configurations (larger or smaller motors, higher complexity systems, etc) down the line. The battery type not used will then be replaced with an FPGA board.
The largest motor and ESC was used in the template, so if the open UAS ESC is put in, it will also need the Switch file, with the switch placed very close to the Open UAS ESC. The height of the bottom layer can be adjusted, but keep in mind any wires that you will need to feed down from the top to the bottom, and any spacing issues that could occur from that.
The color cordination is as follows:
Blue - Pixhawk, Power Module, BEC for Power Module/Pixhawk, and the GPS
Orange - 6 cell battery (or FPGA depending on power configuration) and 10 gage capable Wagos (splicers that routes all power and ground between the parts)
Light Orange - 3 cell battery(ies)
Green - Motor and ESC
Yellow - Communications (telemetry, receiver, etc) (at the point that this document was made, only the long range telemetry was taken into consideration)
Red - BEC for Servos and 12 gage capable Wagos (2)
OpenUAS
+A more in depth explanation about wiring the pixhawk 4 can be found on the pixhawk website, here (opens new window).
OpenUAS Controls
The controls system shall utilize both an open and closed feedback loop.
The controls system shall react quickly in response to internal commands.
The controls system shall react quickly to external forces such as wind.
The controls system shall use the wings and ailerons as primary control.
The controls system shall be stable in cruise flight.
The controls system shall operate reliably in max speed flight.
The controls system shall included the needed cooling devices to stay below critical heat levels.
The controls system shall be activated using electronics and airflow only.
The controls system shall have restricted range of motion.
The controls system shall be light enough to be easily controlled with servos.
The controls system shall operate without harming other components of the UAS.
Electronics
The electronics subsystem shall include sufficient sensors to inform flight decisions.
The electronics subsystem shall provide an interface to receive ground commands.
The electronics subsystem shall provide an interface to send data to the ground.
The battery shall be replaceable.
The sensors shall be replaceable.
The wires shall be replaceable.
The battery shall be able to be reasonably moved within the aircraft.
The flight computer shall be able to be reasonably moved within the aircraft.
Electrical components shall be placed such that there is sufficient space for heat to dissipate.
Facilities for cooling vital electrical components shall be provided.
The electronics subsystem shall provide additional sensors to ensure redundancy.
The flight computer shall be separated such that no components, beyond sensors and controls, may be connected.
The flight computer shall be sufficiently fast to process incoming sensor data.
The battery shall provide a minimum of one hour of operational flight time.
The users shall provide documentation of usage of the battery for both safety and lifespan purposes.
Auxiliary electronic units used shall have the ability to be limited with regards to range of motion.
Auxiliary electronic units used shall turn off with user command during operation.
The onboard receiver shall be capable of receiving messages up to a distance of at least 1 mile from the ground station.
The onboard transmitter shall be capable of sending messages at a distance of at least 1 mile to the ground station.
Ground Equipment
The launch system shall launch the UAS into flight.
The launch system shall be controlled by hand or foot.
The launch system shall use a bungee cord.
The launch system shall launch the weight of the UAS plus payload.
The launch system shall have consistent launch characteristics.
The launch system shall be easily reset for multiple launches.
The launch system shall have adjustable angle of launch and direction.
The launch system shall be stable on different terrains.
The launch system shall be completely documented in Solidworks.
The launch system shall be painted all one color to match the UAS.
The transmitter shall be capable of communicating with the UAS for a distance of at least 1 mile.
The receiver shall be capable of communicating with the UAS for a distance of at least 1 mile.
Propulsion
The propulsion system shall provide a maximum acceleration of (Max Acceleration).
The propulsion system shall provide a minimum acceleration of (Min Acceleration).
The propulsion system shall use an electric motor only.
The propulsion system shall provide a maximum velocity of (Max Velocity).
The propulsion system shall provide a minimum velocity of (Min Velocity).
The propulsion system shall include the needed cooling devices to stay below critical heat levels.
Structure
The wings shall be able to withstand drafts of up to 50 knots.
The wings shall be constructed of EPP foam.
The wingspan shall be 5 feet.
The wing planform area shall be 2 square feet.
The maximum coefficient of lift shall be upwards of 2.
The wing loading factor shall not exceed 3.5 pounds per square foot.
The wings shall be removable.
The wings shall contain a rod through the center to add weight.
The wings shall have control surfaces.
The wings shall have multiple paths inside to allow wires for control surfaces.
The wings shall have carbon fiber wing spars.
The fuselage shall house the required electronics.
The inside of the fuselage shall cushion and protect components.
The fuselage shall contain custom 3D printed storage containers for the components.
The inside of the fuselage shall be accessible.
The 3D printed components shall be produced by the LulzBot Taz 6 3D printer.
The 3D printed structural components shall use ABS filament.
The non-structural 3D printed components shall use PLA filament.
All components shall be placed such that the center of gravity is stable.
The weight of the total structural frame without electrical components shall not exceed 2.5 lbs.
The entire frame shall be waterproof and protect housed electrical components from water.
Software
WHEN THE flight software generates a command, THE flight software SHALL execute this command eventually. +WHEN THE user generates a command, THE flight software SHALL execute this command eventually. +WHEN THE flight software generates a command, THE command SHALL be placed in the command queue. +WHEN THE user generates a command, THE command SHALL be placed in the command queue. +WHEN a command is next in the command queue, THE flight software SHALL execute it within [COMMAND_IN_QUEUE_CYCLES] cycles +Only THE user SHALL generate a safety-critical command. +THE non-safety-critical software SHALL NOT generate a safety-critical command +THE non-safety-critical software SHALL NOT write to the safety-critical data +WHEN THE user generates a command, THE flight software SHALL execute the user's command before any internally generated commands +The flight software shall use sensor values to make controls decisions. +Each routine containing safety-critical commands SHALL be executed every clock cycle. +THE sensor data SHALL be read-only +THE user SHALL be able to read the command queue +ALL sensor buffers SHALL not overflow +THE flight software SHALL update sensor values BEFORE executing each command. +THE flight software SHALL execute only one command at a time. +The flight software shall detect gyroscope values that do not match environmental assumptions. +The flight software shall detect gyroscope values that do not match environmental assumptions. +The ground station shall be able to inspect all sensor values during flight. +The flight software shall not make autopilot decisions using data older than [SENSOR_OLD_TIME] milliseconds. +The flight software shall abstract control details, such that only an architectural file shall be changed in the event that the aircraft is reconfigured (i.e. “bank left” is “bank left” even if motors are swapped or new parts are added) +The flight software shall detect the absence of sensor values. +The flight software shall detect a change in the center of gravity. +The flight software shall measure rotation. +The flight software shall measure acceleration. +The flight software shall measure wind speed. +The flight software shall measure altitude. +The flight software shall detect failure of the motors. +The flight software shall monitor power consumption of each aircraft component +The flight software shall direct the aircraft to land at predetermined coordinates in the event of a loss of connection to the ground station. +The flight software shall immediately return all control to the operator in the event of a software failure. +The flight software shall not starve any process. +The flight software shall only use data values within the same timespan (consistent across sensors). +The flight software shall continuously report a set of pertinent values to the ground station.
OpenUAS holder
OpenUAS Upload any images to include in the OpenUAS tracking document to this folder.
OpenUAS Licensed under either of
at your option.
OpenUAS The following are the settings that we found successful when printing various parts in PLA and ABS.
3D printers have a variety of applications that can be useful for several reasons. This document will cover some basic and helpful settings for +ensuring a quality print for different needs. Please note that the settings gone over in this section are not related to print mature and or material type, and these settings should be checked before any other troubleshooting is done. Please refer to the 3D printing settings sections under the Manufacturing documentation if you want this information.
One of the most important part of ensuring a qutily print from a 3D printer is to ensure the bed adhesion settings are set to match the needs of the part being printed. +There are 3 differnet settings that can be selected for the bed adhesion that are helpful for different part types.
Bed Adhesion types
The skirt setting in Cura Lulzbot Edition is simple to use and what it does is create a line around the part before printing the part. This is useful in some cases if +the printer has poor material flow issues. It is not commonly used for many parts unless the part is larger and is printed to a higher/fine quality to ensure the material flows smoothly.
More commonly used than the skirt setting, the brim setting is reserved for odd-shaped or larger prints. The brim is a layer of filament that creates a larger adhesive surface that is better for holding onto the part. In other words, the part has less of a chance of being pulled off the build plate midpoint. For more of the odd-shaped prints, this helps ensure the print layers are smoother at the start of the print and will match the quality of the final layers.
+It does use a decent amount of filament during printing and is more of a waste of material for smaller prints, so using a brim in those cases would not be the best option unless all other options for diagnosing the problem have been addressed.
A raft is infrequently used for parts. This setting works best for smaller parts that do not have a "good" amount of adhesive surface connected to the build plate. This leads to the part being pulled off the build plate early in print and, in some cases, can cause damage to the nozzle from clogging.
This setting is more used for prints where you would use a skirt; however, you are not having problems with the flow of the filament; therefore, using a skirt is unnecessary. In many cases, this is the best option to limit filament waste. This is also an acceptable bed adhesion setting if the print quality is lower, as it does not assist or take away from the print quality.
* In some cases, using a light layer of glue on the print bed can eliminate the need for adjustments in the bed adhesion settings. Please note that this method does require the user to clean the bed before and after the print takes place to help ensure the print bed is smooth for printing.
The bed adhesion can be affected by several external factors and the g code settings set by the slicer. These external factors result from the environment in which the printer is stationed to print. In the case of the lab, we know that a draft affects the quality of the prints we get regardless of the settings we use in Cura Lulzbot Edition. The draft creates an issue with the layers being smooth when the print is completed due to inconsistent cooling time. A newer setting released by Cura Lulzbot Edition is the experimental setting referred to as Enable Draft Shield Which then brings up a range of different settings, including the distance from the print it is along with the height of the shield.
This setting can be useful in spaces like the lab where a small draft affects the print, even with a printer shield. It does use a lot of material to create the shield, so if used, try to limit the excess nature of the setting. This can include shorting the default height or bringing the shield closer to the print. Another solution to this issue is to run a few tester prints with different fan speeds to determine if the fan adds to the problem. This method is more time-consuming, but if the problem is consistent across different prints, this may be a better long-term solution to prevent warping and the part from coming off the printing bed.
It is not uncommon for a part to need support material to turn out correctly and to a high standard. Cura is great at automatically generating support material for imported files. However, there are some cases where the settings will need to be adjusted to meet the needs of the part.
The Support Tab is one of the main Tabs in the right-hand menu. All of the settings under this tab can be found through the search bar after typing Generate Support. Most settings relate to which head is used to create the support. A general rule for this is if you are using the same material for the support, then you only need the Hot End 1; if you a using a different material for support, then Hot End 2 should be selected.
The support placement is one of the more useful setting that will change the most. It has two options that include
The Touching Build Plate setting is useful in two big ways. One, it reduces the amount of filament used for the supports. Two, it helps to keep the support filament in areas the part needs instead of every gap. At the end of the print, this is helpful for removing the support material from the print without damaging the part or causing harm to anyone trying to remove the part.
The Everywhere setting is one you need to be careful with, as it is the default setting and is meant for less complex parts that need some support. If you are using dissolvable filament, this setting is less of an issue, but for most cases in the lab, we use the same material, making it dufficult to remove the part.
+ ← + + Manufacturing + + Cura Setup + + → +
OpenUAS Summary table for quick refernce :
| Part | How often it should be cleaned | How to clean it |
|---|---|---|
| Rods | Before every print | Wipe with a clean paper towel. DO NOT USE A CHEMICAL CLEANER OF ANY KIND!!!!! |
| Printing bed | Before every print | Wipe with a wet paper towel. Only use soap and water on a towel if glue was previously used on the bed and remains on the surface. |
| Flash Drive | Every Semester (approx 16-20 weeks) | Plug into the USB port on the laptop from here there are two methods. 1. Manually remove the files from the files tab 2. Right click the device in the files tab and select format, then quick format to remove everything on the flashdrive. * For mac please look up instructions |
| Environment | Monthly | Move the printer to a different location and wipe down the counter and dust surrounding the area. Replace printer to location. *Remember to unplug the printer when moving it |
| Calibration of Printer head (simple) | Once to twice a year or as needed if issues arise | First step to go directly to the printer settings, Select advance settings, Select Nozzle offset,(before the next step be sure to record important settings refernce below for how and what to save before cailbrating) Select AutoMeasure. Make sure there isn't anything that would get in the way of the printer head and let it do it's thing. In some case it make take more than one try to correctly calibrate the printer head. |
| Calibration of Printer (Complex) | As needed. Usually when issues such as lopsided holes, non-squared edges and layers appearing skewed. | First step is to print a calibration square and measure the offset from perfect angles/holes. Then going into the gcode in Cura we can adjust the x, y and z axis distance and complete a reprint of the same calibration square. I recommend refering to the documention of the calibration square you choose to you. |
| Adjustment of z-offset | As needed. Is needed When the printer head is too close or too far from the printing bed. (signs include poor bed adhesion, flatened printed filament, consitant clogging of the nozzle, or head running into the bed itself) | This process is itertive in naturate and starts with first going into the printer menu, selecting advance settings, and then selecting z offset. From here it is good to note what the z offset is currenlty at as this will be your starting point. Other notes the z offset should be a negtive number, it is recommend any changes made are done in increments of .01mm which is NOT the default setting and will have to be selected, the more negtive the number the further the head will be set from the bed (in other words closer to zero closer to the bed). Adjust as needed with good judgement and try a new print. Be sure to watch as it gets close to the bed and readjust as needed for the head to ensure the head is where it needs to be. |
Before using the printer, a few things should be cleaned and checked before beginning the print. The biggest and most important part of regular maintenance for the printer is making sure the rods are dust free. A big note for the printer rods is that they are used by the self-lubricating bearing that connects the printer head and bed to the rest of the printer. This is important because if you add a cleaner that is unsafe for the bearing, you will cut the printer's lifespan significantly.
With this in mind, the first maintenance step before each print is to take a clean paper towel and wipe the rods as is. DO NOT add cleaner (Including soap and water) or use a disinfectant wipe; this will cause damage to the bearings and, therefore, the printer. In many cases, black/ gray dirt may come off the rods. That's okay; that is why we are wiping them down; if we do not remove the dirt, it will build up and create a squeaking noise (otherwise described as cat screeching). If it does get to this point, it will take a few times to wipe off the rods before the noise stops.
For the printing bed, the prep is a little different. Depending on what material you are printing with, it will depend on how you prep it, but the most common way is to wipe the bed down with a wet paper towel to remove any dirt on the bed. If the last print you did needs to be glued onto the bed, it is recommended to wipe the bed down with a soapy paper towel until the glue is completely removed, then dry the bed afterward. Depending on the material you are printing with, it might change, but currently, for the materials in the lab, you then wipe the bed down with a 93% alcohol solution that can be applied with a paper towel (not the one you cleaned it with).
Every so often there is the possiblity of the cailbration being a bit off on the printer espically if the printer is being fequently in a short time span. There are a few different ways to go about this depending on the needs of the printer. If it is just a small issue the printer has it own cailbration setting under the menu tab in advance settings. Before Cailbrating you should record a few different settings as they can be reset during the cailbration process and will need to be manually reinputed to the printer. These Include the z offset (has its own tab in advance settings), E steps, X steps, Y steps, and Z steps (E, X, Y, Z steps are all under the Steps/mm tab in advance settings).
Once you have the information on the settings written down we can then go back to the advance settings tab and then select the Nozzle offset tab.Then select automatically measure. This will start the cailbration process and you need to make sure nothing is blocking the path of the printer head and wait for the printer to stop. Repeat the process as needed and then check the z offset, E steps, X steps, Y steps, and Z steps and reinput them if needed.
The z offset on the printer is important to know and adjust as needed. This setting is respondable for how far/close the head is to the bed to the printing bed. There are a few different ways of going about determining the needed offset however, the one described in the above summary table is the most straightforward and least complex method. Please remeber to start slow and not make large jumps in the z offset as it can result in damage to the printing bed.
Over time the z offset will shift due to a varity of different reasons and is something to watch out for. If there is a big and sudden shift in the z offset I recommend doing a printer cailbration first and then adjusting the z offset. This should help you get closer to the desired z offset in a shorter time period. In most cases it will also fix other issues that are occuring during printing such as lop sided holes or skewd edges.
+ ← + + Cura Setup + + Poster Board Arrangement + + → +
OpenUAS Our 3D printer is a Lulzbot Taz Pro for the Lab, and we use the Cura Lulzbot Edition as our Slicer.
Cura is a free-to-use slicer that requires no special operating system or hardware. From any search engine, you should be able to look up Cura Lulzbot +Edition and download the respective software for the operating system on your device (laptop/desktop). It should not take an extended period to download the +software after following the instructions provided and installing it on the Cura website (https://lulzbot.com/support/cura).
Once Cura Has been installed and opened, you should see an opening screen asking you to set up the printer. For the case of the Lab, our setup is the Lulzbot Taz +Pro with dual head extruders. After setting up the printer on your device, the next important step before printing is ensuring that you have the correct material +selected with the corresponding settings.
In order to select the material, you need to view the right-hand menu, which has various options for the settings in Cura. We want to look +at the second option from the top of the menu bar. There should be a drop-down menu with a preset list of materials that can be chosen from. In the Lab, we have a few different +materials we use for printing, but our most common is the Polylite PLA which Polymaker produces. For more information on the generic settings for PLA please refer to the OpenUAS Website section 3D printer settings tab under the manufacturing section.
* Will show up as PolyLite PLA (Polymaker) in the material section
Suppose the material you are using is not listed. In that case, you can use the information from the material data sheet +that gives recommended setting provided by the manufacturer and create a custom material under the custom +tab in the drop-down menu. More instructions on how to do that will be located later in the documentation.
I recommend taking a few minutes to review the settings, particularly the temperature settings, to ensure they match the recommended +levels from the manufacturer. There are general temperatures for the materials; however, the manufacturer's recommendations +tend to work the best to insure the quailty of parts. You can do this by scrolling through the print setup settings, selecting the custom tab, and using the search bar to look up keywords for the desired setting.
* For example, type printing temperature to see the printing temperature-related settings.
This is the standard setup of the Cura Lulzbot edition. From this point, you should be able to open an STL file of a model and print. There are more specialized settings for different types of parts that can be used but are more in depth and will be revised in another document.
+ ← + + 3D Printer Settings + + Printer maintance + + → +
OpenUAS Poster boards can be used to manufacture some parts of the fuselage and wing. It's important to find the best arrangement of these parts to reduce material waste. This problem is generally referred to as the bin packing problem. Several algorithms have been developed to solve this problem before with JS, MATLAB, and C++. Based on our research, the libnest2d library is the easiest, most effective algorithm for finding the best arrangement to cut parts on the poster board. To ease the process, PrusaSlicer 2.5.0 can be downloaded since the libnest2d library is already integrated within this open-source 3D printing software.
References:
Bin Packing Problem (opens new window)
Libnest2d Library (opens new window)
PrusaSlicer Download (opens new window)
First, to use the PursaSlicer, you will need to create STL files of your parts using CAD software such as Fusion360 or SolidWorks. If you are using Fusion360, you can export the parts as STL files by right-clicking on the body and selecting 'Save as Mesh'. Even if your parts are designed in other units, you must choose the mm units from the 'Save as Mesh' options. If you are using SolidWorks, you can go to File -> Save As and select the document type as STL. Then, click on the 'Options' button and convert the units to mm. PrusaSlicer software doesn't have the option to change the global units. If STL files are exported with inch units, you can scale the parts by 2540%. It's important to note that the thickness of your parts must be the same as the thickness of the material that will be used.
After opening the PrusaSlicer, set the bed dimensions to the same size as your material board in mm units from Printer Settings -> Bed Shape -> Settings -> Size. Then head back to the Plater page, and you can import as many parts as possible
+from File -> Import or using the Ctrl + I shortcut.
The imported parts can be in different orientations. Rotate each part until they are all parallel to the bed. Select the required spacing between parts and check to enable the rotations option by right-clicking on the arrange option at the toolbox bar on the upper side of the window. Then you can check for different alignment options with shortcut A. If you are cutting the parts with CNC for better machining, make sure the spacing is at least the same as the tolerance of your machine. If you are cutting the parts with a knife, we recommend setting the spacing to 1 mm.
If your machine works with G-code, you can easily export the G-code with Ctrl + G shortcut. If STEP, DWG, or DXF formats are needed, we recommend exporting the plate as an STL file and then post-processing it in Fusion360 or SolidWorks with relevant manufacturing settings.
1. via Fusion360
After exporting the plate as an STL file, open it via Fusion360. Go to
+Design Workspace -> Mesh -> Modify -> Convert Mesh and select all the meshes to convert them to bodies. Now, you can see the coordinates of your parts on the bottom right of the window by clicking on the corner points of the parts. If the origin is not the same as the bed origin in PrusaSlicer, go to Manufacture Workspace -> Fabrication -> Setup. Set operation type as cutting and orientation as select X & Y axes. Select the X and Y axis from the corner of the reference region manually (Red: x-axis / Green: y-axis) and then set the origin setting to the selected point.
2. via SolidWorks
Go to File -> Open and select the STL file. Then, click on the 'Options' button and select the surface body from the 'import as' option. You can see the coordinates of your parts on the bottom right of the window by clicking on the corner points of the parts.
You can mark these locations on the posterboard and connect the dots to create the part drawings to cut them with a utility knife. We recommend holding a metal straight edge flush with the edge you are cutting and running the knife along the metal.
Here is the poster board arrangement (22x28-in) we created following the procedures above.
| # | x-axis | y-axis | # | x-axis | y-axis | # | x-axis | y-axis | # | x-axis | y-axis |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 323.848 | 0.254 | 12 | 4.561 | 194.502 | 23 | 415.121 | 361.505 | 34 | 320.514 | 415.991 |
| 2 | 574.673 | 0.254 | 13 | 2.497 | 195.357 | 24 | 457.624 | 404.008 | 35 | 25.747 | 463.784 |
| 3 | 617.176 | 42.757 | 14 | 637.497 | 241.077 | 25 | 322.022 | 342.299 | 36 | 25.747 | 415.991 |
| 4 | 323.848 | 42.757 | 15 | 637.497 | 251.237 | 26 | 499.314 | 424.971 | 37 | 25.747 | 314.709 |
| 5 | 4.651 | 24.167 | 16 | 2.497 | 296.957 | 27 | 499.314 | 494.046 | 38 | 320.514 | 366.69 |
| 6 | 4.651 | 151.167 | 17 | 86.038 | 291.945 | 28 | 322.022 | 494.046 | 39 | 320.514 | 414.483 |
| 7 | 639.561 | 66.5 | 18 | 86.038 | 324.05 | 29 | 558.75 | 495.3 | 40 | 156.961 | 152.169 |
| 8 | 639.561 | 108.833 | 19 | 568.638 | 257.197 | 30 | 558.75 | 557.213 | 41 | 25.747 | 414.483 |
| 9 | 639.561 | 109.835 | 20 | 568.638 | 358.798 | 31 | 321.768 | 557.213 | 42 | 487.161 | 108.833 |
| 10 | 639.561 | 236.835 | 21 | 708.449 | 361.505 | 32 | 321.768 | 495.3 | 43 | ||
| 11 | 4.561 | 152.169 | 22 | 708.449 | 404.008 | 33 | 320.514 | 515.764 | 44 |
X and Y coordinates are in mm units.
+ ← + + Printer maintance +
OpenUAS Our 3D printer is a Lulzbot Taz Pro for the Lab, and we use the Cura Lulzbot Edition as our Slicer. Most up to date version of Cura Lulzbot Edition 3.6.37
Cura is a free-to-use slicer that requires no special operating system or hardware. From any search engine, you should be able to look up Cura Lulzbot +Edition and download the respective software for the operating system on your device (laptop/desktop). It should not take an extended period to download the +software after following the instructions provided and installing it on the Cura website.
Once Cura Has been installed and opened, you should see an opening screen asking you to set up the printer. For the case of the Lab, our setup is the Lulzbot Taz +Pro with dual head extruders. After setting up the printer on your device, the next important step before printing is ensuring that you have the correct material +selected with the corresponding settings.
In order to select the material, you need to view the right-hand menu, which has various options for the settings in Cura. We want to look +at the second option from the top of the menu bar. There should be a drop-down menu with a preset list of materials that can be chosen from. In the Lab, we have a few different +materials we use for printing, but our most common is the Polylite PLA which Polymaker produces.
* Will show up as PolyLite PLA (Polymaker) in the material section
Suppose the material you are using is not listed. In that case, you can use the information from the material data sheet +and the recommended setting provided by the manufacturer and create a custom material under the custom +tab in the drop-down menu. More instructions on how to do that will be located later in the documentation.
I recommend taking a few minutes to review the settings, particularly the temperature settings, to ensure they match the recommended +levels from the manufacturer. There are general temperatures for the materials; however, the manufacturer's recommendations +tend to work the best to insure the quailty of parts. You can do this by scrolling through the print setup settings, selecting the custom tab, and using the search bar to look up keywords for the desired setting.
* For example, type printing temperature to see the printing temperature-related settings.
This is the standard setup of the Cura Lulzbot edition. From this point, you should be able to open an STL file of a model and print. There are more specialized settings for different types of parts that can be used but are more in depth and will be revised at another document.
OpenUAS The OpenUAS 3.0 is designed to be an easy build for those with minimum manufacturing experience and resources. This page serves as a quick reference that includes the time commitment, manufacturing tool requirements, and price expectations.
| Task | Time Expectation |
|---|---|
| Fabrication Time by Hand | 3 hours |
| Fabrication Time by Laser Cutter | 1 hour |
| 3D Print Time | 30 hours |
| Assembly Time with 4 people | 5-10 hours |
+ 3D Printer Settings + + → +
OpenUAS Here you will find documentation about the documentation
This documentation uses VuePress to render basic mark down files as a static webpage.
In the past the team has used Latex to write documentation. While Latex is good for writing final documents, VuePress gives a more streamlined workflow that is easier for new members to jump into reading documentation and especially editing documentation.
The easiest way is to click the "Edit this page" button at the bottom of the page you'd like to contribute to. The VuePress site is pre-configured with the OpenUAS git repository to automatically rebuild and deploy when a change to the Documentation folder is pushed to the main branch. The build status can be viewed on the Github actions page (opens new window)
You can also make modifications to the docs folder from any text editor, then push to the main branch and your changes will be built and published. To test your changes before publishing them, you'll need to setup a development environment:
To build the docs you will need a few things:
git clone git@github.com:Open-UAS/Open-UAS.github.io.git
+cd Open-UAS.github.io/
+npm install
+npm run dev from the root folder to start the server.Once everything looks good on your machine, you should be able to push your changes to main to publish.
To create a new page, simply create a markdown file (.md) in the appropriate folder. To add your new page to the sidebar, the SUMMARY.md file must be modified. This file exists in the base folder for each section (ie, Design, Electrical, Software) and is used by a script at compile time to generate the side bar information. Any relative or external link can be added to the side bar, but it is good practice to follow the actual folder structure where the files are stored.
Below is an example of the SUMMARY.md file with the following folder structure.
Docs
+|-- Intro
+| |-- SUMMARY.md
+| |-- README.md
+| |-- ProjectCharter.md
+| |-- Example_Folder
+| | |-- README.md
+| | |-- example_file.md
+| | |-- Example_Sub_Folder
+| | | |-- README.md
+| | | |-- example_sub_file.md
+# Summary
+
+* [New Member Orientation](README.md)
+* [Project Charter](ProjectCharter.md)
+* [Example Folder](Example_Folder/README.md)
+ * [Example file](Example_Folder/example_file.md)
+ * [Example Sub Folder](Example_Folder/Example_Sub_Folder/README.md)
+ * [Example Sub File](Example_Folder/Example_Sub_Folder/example_sub_file.md)
+The headings of each page are automatically detected and displayed by vuepress and cannot be easily changed.
To see more details on the side bar see .vuepress/config.js (opens new window) and .vuepress/sidebar_provider.js (opens new window)
pandoc -s example.tex -o example.mdThere are many configuration settings that Vuepress supports. Most of them are found in the docs/.vuepress/config.js file or at the top of the markdown file as front matter. More information on configuration settings can be found at the official Vuepress documentation (opens new window) Front matter details (opens new window)
As of this writing (April 2022) Vuepress 1.0 is nearing its end of support and Vuepress 2.0 (opens new window) will soon be released. Currently these docs are written in Vuepress 1.0 but will need to be converted to Vuepress 2.0 eventually. A guide on the required steps should be available in the official Vuepress 2.0 docs (opens new window)
OpenUAS PX4 autopilot is the main software stack that controls the UAS. It has been forked to the OpenUAS repo (opens new window) to allow our own custom modifications. The upstream repo can be viewed at, github.com/PX4/PX4-Autopilot (opens new window)
PX4 allows for many out of the box capabilities such as flight stabilization, automatic flight paths, and automatic take off. Further details about PX4's features can be found in the PX4 documentation (opens new window)
This setup can get fairly complicated with all the dependencies that PX4 requires. A new method that alleviates some of this is using a docker container to compile PX4. This pre-packages the dependencies required to build PX4
Windows with WSL 2
wsl --install --distribution Ubuntu-20.04Linux
Windows with WSL 2
wsl --install --distribution Ubuntu-20.04Ubuntu 18.04/20.04 Native/Virtual Machine
Note from the PX4 User Guide:
The supported OS versions for PX4 development are Ubuntu Linux LTS 18.04 (Bionic Beaver) and 20.04 (Focal Fossa).
git clone --branch stable https://github.com/LTL-AERO/PX4-Autopilot.gitcd PX4-Autopilotgit submodule update --init --recursive to clone all submodules within the repository, to your machine
+git submodule update --init --recursive <submodule folder> can be used if you know the specific submodule neededgit submodule update --recursive can be run in the future to update all submodulesbash ./Tools/setup/ubuntu.shNative Windows
WARNING
This configuration will not be able to run the gazebo simulation. +Gazebo is a Linux only software so it must be run through WSL or natively on Linux.
See Dev Environment Setup for setup details.
sudo service docker start or sudo systemctl start docker depending on if your distro uses SysVinit or Systemd../Tools/docker_run.sh make px4_fmu-v5_default. This will start a new docker container and compile the firmware for Pixhawk 4.
+./Tools/docker_run.sh make clean to put the build process in a clean state./Tools/docker_run.sh {command to execute} ./Tools/docker_run.sh bash can be run to look around in the docker container file systembuild folder as px4_fmu-v5_default.px4 among other files.make px4_fmu-v5_default.
+make clean to put the build process in a clean statebuild folder as px4_fmu-v5_default.px4 among other files.
PX4_fmu-v5_default.px4 file and click ok to start flashing.Within PX4 there are definitions called airframes (opens new window). These definitions control things like, number of control surfaces, propeller configurations, and vehicle parameters among other settings. PX4 comes pre-loaded (opens new window) with many airframes, but we can add our own custom airframes to support configuration and modification efforts.
The PX4 docs have a great step by step guide for adding a new airframe here (opens new window).
In this documentation we will cover what has been added to stock PX4 to get the new airframes setup.
This airframe is intended for the current OpenUAS vehicle and should be adapted and modified as the physical design changes.
See Using The OpenUAS Airframe for details and enabling the new airframe in QGC.
This airframe is intended to run on the Apprentice aircraft that we utilize for other development tasks. This airframe was not utilized as much as the other so may not be up to date.
A similar approach was taken to add this custom airframe as previous.
Mixers (opens new window) are used to take commands (roll, pitch, yaw, throttle) from the PX4 system and map those commands to actuator outputs, including servo mapping, min and max values, and direction. This is preferable to mapping the outputs with the RC controller because the autopilot will utilize the mixer and not the RC controller mappings. Meaning the trims, and servo mappings can be applied system wide.
The mixer for the custom airframes are defined in the ROMFS/px4fmu_common/mixers folder eg open_uas_apprentice.main.mix (opens new window) . The mixer files can get somewhat confusing to understand, details on writing mixers can be found on the PX4 docs (opens new window). The general idea is that you have n number of actuator outputs, each of those n actuators are defined to be driven by 1 or more outputs from PX4. The mixer file is defined sequentially, starting with actuator 1, then 2, 3 ... to n actuators. These actuator numbers correspond to the pwm port number on the Pixhawk wiring (opens new window).
The default mixer file can be overridden at runtime by placing the mix file with the same name (eg open_uas_apprentice.main.mix) onto the Pixhawk SD card under /etc/mixers/ This mix file will be loaded instead of the default one defined at compile time.
PX4 allows the user to control the behavior of the autopilot through hundreds of parameters. This is the main way that we customize the OpenUAS and control its behavior.
The current parameters of the connected vehicle set can always be viewed in QGroundControl under vehicle setup > parameters.
+
Some parameters are initialized by the airframe definition file, ex: PX4-Autopilot/ROMFS/px4fmu_common/init.d/airframes/2150_open_uas (opens new window) and some parameters are modified later by the user. Because of this, all modified parameters are reset when switching to a new airframe, but parameters are saved if the vehicle is simply powered off.
PX4 includes hundreds of parameters to modify, a full list of all available parameters can be found in the PX4 docs (opens new window). Below are some parameters of note that we have modified in the past.
Specifies the capacity of the battery in mAh. Needed for accurate battery percentage readings.
Specifies the number of cells our battery has (we normally use 3S batteries). Needed for an accurate voltage measurement of the battery.
Specifies the charged voltage of one cell of the battery. Needed for accurate battery percentage readings. This value is typically around 4.2V (12.6V total battery voltage when fully charged)
Specifies the voltage to classify a battery cell as empty. Needed for accurate battery percentage readings. A safe value would be around 3.5V (giving total battery voltage of 10.5 when empty). Can use more of the battery by setting this value to around 3V (9v total battery voltage when empty). DO NOT set this value lower than 2.8V.
Specifies the internal resistance of the battery in ohms. Optionally needed to improve the battery percentage readings and current draw readings. This value can be measured using the battery charger we have in the lab. A typical value is around 0.006 ohms.
Allows for PX4 to be armed without a GPS signal. This is required to arm the OpenUAS in the basement of Howe where no GPS signal can be acquired.
Specifies the amount of time after landing to automatically disarm the vehicle. If set to 0s, does not disarm on landing. This parameter is intended more for quad-copters than fixed wing planes. We typically set this value to 0 to not disarm on landing.
Specifies the amount of time after arming which if not taken off, will automatically disarm the vehicle. If set to 0s, does not disarm. We typically set this value to 0 to not disarm when trying to takeoff.
Specifies a scale factor for the flaps. If set to 100% the flaps will move the ailerons to the their max travel when flaps are deployed, 50% will move them half of their travel.
When true, sets the flaps position during the final loiter loop of the automatic landing sequence instead of on the final approach. Typically set to true.
Specifies the min and max pitch angles the controller will command the vehicle to achieve. This is only in effect in autonomous modes, including altitude and position control flight mode.
Specifies the max roll angle the controller will command the vehicle to achieve. This is only in effect in autonomous modes, including altitude and position control flight mode.
Turns on launch detection to launch the vehicle with a catapult launch or with a hand launch
Specifies the acceleration threshold to detect a launch event.
Specifies the required time an acceleration must be held for to detect a launch event.
Specifies the acceptance radius of hitting a waypoint in autonomous flight.
Trims the center point of the servo number at the end of the parameter name. Needed to center each servo before flight.
Reverses the direction of the server number at the end of the parameter name.
Specifies we are taking off on a runway with landing gear. Used for automatic takeoff.
Sets what LightWare sensor is in use for the serial port, normally set to SF11/c.
Sets what serial port the LightWare distance sensor is plugged into. Normally set to TELEM2.
+ QGroundControl + + → +
OpenUAS QGroundControl (opens new window) (QGC) is the software that we use to monitor telemetry sent from the UAS. Typically, no direct control happens through QGC.
The custom OpenUAS airframe only shows up properly in QGroundControl if the connected vehicle's firmware has been flashed from the computer connecting to it. This is because, during the flashing process, QGC will update it's list of known airframes with those included in the firmware. See Building and Flashing Custom Firmware for details.
If QGC is not aware of the currently running airframe, it will show as experimental.
+ ← + + PX4 + + Simulation + + → +
OpenUAS We are experimenting with using simulation models to test software changes and potentially train pilots. This area still needs further development to be fleshed out more.
TODO
This section assumes you already have setup dev tools for PX4.
Gazebo is a linux only application so we will be running it either through WSL 2 or natively on linux:
WARNING
If you plan to use Docker to run the simulation, there are only docker containers for Gazebo 9 and Gazebo 11. Local and Docker versions of gazebo must match to work correctly. The docker script will attempt to find the verison on you machine, otherwise it will default to Gazebo 9. You can check your local gazebo version by running gazebo --version
Depending what version of windows you are using, some additional setup may be needed
Windows 11
sudo apt updatesudo apt install gazebo9sudo apt install libgazebo9-devgazebo GUI support for WSL 2 should be included in Windows 11.Windows 10
Xlaunch application from windows.
+multiple windows, nextStart no client, nextnative opengl and check Disable access control, nextsudo apt updatesudo apt install gazebo9sudo apt install libgazebo9-dev~/.bashrc using your favorite text editor (nano is easy if you have no preference)export GAZEBO_IP=127.0.0.1
+export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0
+export LIBGL_ALWAYS_INDIRECT=0
+source ~/.bashrcgazeboTIP
You must go through the configuration for Xlauch every time you reboot windows. +You can save the configuration file on the last step in Xlaunch and run that instead to speed things up.
Ubuntu 18.04/20.04 Native/Virtual Machine
make px4_sitl gazebo_open_uas to build and launch the OpenUAS gazebo simulationWARNING
There are only docker containers for Gazebo 9 and Gazebo 11. Local and Docker versions of gazebo must match to work correctly. The docker script will attempt to find the verison on you machine, otherwise it will default to Gazebo 9. You can check your local gazebo version by running gazebo --version
Linux
./Tools/docker_run.sh make px4_sitl gazebo_open_uas to build and launch the OpenUAS gazebo simulation server in docker
+./Tools/docker_run.sh make clean px4_sitl to put the build process in a clean stateexport GAZEBO_MASTER_IP=172.17.0.2 
docker inspect --format '{{ .NetworkSettings.IPAddress }}' container_name_or_id
export GAZEBO_MASTER_URI=$GAZEBO_MASTER_IP:11345export GAZEBO_MODEL_PATH=~/git/PX4-Autopilot/Tools/sitl_gazebo/models/ gzclient --verbose to launch the gazebo GUI client, and connect to the docker serverWindows with WSL2
WARNING
Performance is currently an issue with Gazebo GUI running on WSL 2. Still investigating.
The issue comes from WSL 2 not using hardware acceleration when rendering GUI graphics. This could be better on Windows 11 but have not tested yet.
Gazebo working under docker installed directly in WSL2 from docker linux installation instructions (opens new window). Had to run the docker container under the 'host' network to allow access to all the ports for gazebo to operate. Running under bridge with only port 11345 published did not work.
Current issue with configuration is performance, gazebo client running from WSL with docker gazebo server, sits at about 10 fps circling the iowa aeromodelers field when running maximized on my 21:9 monitor (smaller client resolution helps a lot). The performance drop from running gazebo server in docker compared to running gazebo client and server in wsl is minimal (1 to 2 FPS). However, running the same scenario on linux on bare metal with Nvidia drivers gives 62 fps. Additioanlly, running the docker container for the gazebo server on linux bare metal, does not significantly impact fps, so this is likely an issue with wsl.
The Windows with WSL2 instructions are largely the same as the Linux instructions, except for running VcXsrv and steps 2 and 3.
DOCKER_OPTIONS="--network host" ./Tools/docker_run.sh make px4_sitl gazebo_open_uas+ ← + + QGroundControl +
OpenUAS The software solution utilized can be broken up into a few major sections.