-
Notifications
You must be signed in to change notification settings - Fork 1
Blog 2017 05 26 Spring
We had our test launch this last weekend and it went great. Our telemetry was more accurate than the TeleMega. The team was able to find both the booster and the sustain-er in about 45 minutes compared to the hours or days they would usually spend out there.
We plan on taking out any additional filters that were in the code for the firmware. Taking this into account, we hope to get the hiccup fixed with the GPS and the timers that the packets were being sent in. The GPS sends packets when it has a connection, when it is below a certain height, and going below a certain speed. Once this is rewritten, I believe our project will be done.
We had a hiccup with the sustain-er GPS (this was on the ECE team's side). While we were out there we created a plan for refactoring it with the ECE team.
If you were to redo the project from Fall term, what would you tell yourself? If I was to redo the project, I would definitely work more closely with the ECE team. They had to write a considerable amount of code that they were not expecting. It would have helped a lot if we had known that from the beginning.
What's the biggest skill you've learned? The biggest skill I learned was how to work in a large team of around 30 people. The amount of communication that has to happen is considerable.
What skills do you see yourself using in the future? The skills I would use were working in a large team, as well as a small sub team. The technical writing skills will definitely follow me. Everything that I have learned about rockets since the beginning of this project, especially when it comes to the visualization of its data.
What did you like about the project, and what did you not? I did not like having to rely on another sub team to make sure we could communicate with the rocket. The telemetry protocol kept changing. I enjoyed watching the rocket launches and seeing the visualization update in real-time.
What did you learn from your teammates? I learned quite a bit about node.js, telemetry, and rockets.
If you were the client for this project, would you be satisfied with the work done? I think I would be satisfied. This is the first year that the electronics and communication with the rocket has worked.
If your project were to be continued next year, what do you think needs to be working on? For next year, I think that if they could have a live version of this website application with some serious security for launch codes, it would be great. Also, they could add a user interface for uploading height maps for areas that they will be launching from as well as satellite imagery. Uploading information about each sub team and possibly resume information would be good for competitions.
We had out launch this past weekend and we were able to fine the booster with the data that was collected from the gps.
Due to some issues with the GPS having to correct itself in mid-flight after apogee and some other issues. We are working with the EE Team to help with their GPS and some of their other code to make sure it is working properly before competition.
Right before the flight the Sustainer went through all the stages and put itself into low power mode which stop sending us a signal, because of that we didn't get any data back from it.
Make sure all the software and/or coding is what the client and sub-teams is what is wanted and need. Also check with all sub-teams to see if there is any coding that they are going to be doing later on to see what their overall goal or plan is for it. We maybe able to help with the planing for it.
The biggest skill I learned was to work with other types of engineers outside of computer science and learning from them. Being in a multidisciplinary project goes a long way especially for me. Learning the mechanical and the electrical components of rocketry no matter how large or small will go a long way in my career, working in Aerospace.
Honestly the skill I see myself using more in the future is adaptability. The reason why I do not put a technical skill here is because of the fact technical skills depend on what you are doing. One day it may be C or node or openGL but if you are adaptable you can be able to adjust and use these technical components to your liking.
I loved that we were doing software for a rocket. Space and flight is my passion and I did not care what it was as long as I had a part in it. What I honestly did not like was how it felt like it was the Mechanical Engineers and the rest. I felt like even if we were not there they would not even care.
I learned it takes a whole team to get a project this size done. For example Al and I are not artistic at all and if it was not for Natasha our software would of looked like a table and a graph. It probably would not have looked as beautiful as it did. Also both of them taught me a lot about myself personally how to grow up. I can act like a child sometimes but I learned when to be more professional and when I can be a child.
I would be more than satisfied with this project. We not only are able to fine both stages of the rocket but we allow all the sub-teams to hook up to WiFi so that they do not have to have one computer to see what is going during flight. This has been a problem in the past. We tested this at the test launch and 10 plus devices can hook up but we know more can do it. We will stress test before the competition for 30 plus.
If the EE can get the electronics working for full control of the rocket which includes separation of the stages, re-ignition, and launching of the parachutes. With this happening we can upgrade the 2D graph so that it let mark when these events happen. Also with the 3D Map we can show the separation of the stages as well.
This week I helped Scott create a unit testing framework for the Avionics firmware. Hopefully this will make the ECE team's code much more stable.
I will continue to work with the ECE team for as long as I can to ensure that their code is as good as it can be.
Writing unit tests for embedded code is hard. You can't just call printf when something goes wrong and check the output. We have developed a system where we run the avionics firmware on a slightly different device that has a serial connection so we can view some results over the serial terminal.
We needed to work with the ECE team much earlier than we did. First there, were some miscommunications about what parts of the code would be the responsibility of the software team (us) and which would be the responsibility of the ECE team. This misunderstanding resulting in a lot of code being written at the last minute, and I'm still not happy about the quality of this code. Second, even for the code that is not our responsibility, the ECEs could utilize us much more effectively. Software engineers are trained to design and test large software systems, and although the ECEs are fine programmers, they are not software engineers. I think we should have reined in our requirements in order to spend time lending our skills to the ECE team.
After the aforementioned issues with the ECE team, I believe that the biggest skill I've learned is how to effectively work in a large, multidisciplinary team. I found that a lot of the electrical, computer, and mechanical engineers don't know what we do or what we can bring to the table, so it's important to make sure that our skills are known.
I will definitely use my experience working with interdisciplinary teams in the future. At my future job at Garmin, I'll be working on a product that is designed and built entirely on-site, from the hardware, to the operating system, to the application. Being able to work effectively with different types of engineers will be invaluable. Also, I got a lot of really great practice using Git.
The best part of working on the rocket is that it is something that I am personally invested in. The rocket is not some corporate project that I'm working on for free, it's the product of months of hard work of my fellow students. However, because the project is almost entirely run and managed by students, there have been some problems with some inexperienced leadership. Although, in general, the leadership has done a great job, a lot of plans and dates were made or changed at the last minute. Additionally, the software team seemed to be at the end of the proverbial grapevine with it came to receiving information about anything.
My teammates taught me the most valuable lesson of all... The lesson of friendship. Also, Natasha taught me how to do some simple tasks in Blender.
Yes. I already know that our client, Dr. Nancy Squires, is very excited to see how the software and avionics work out, because it will allow the rocketry team to track the rocket at much farther distances than was previously possible.
There is some code that we wrote at the last minute because no one told us they were expecting us to write it. This code controls the physical part of the groundstation. The code lights up lights, sends arming and launch signals, and writes GPS data to the screen. This component of the software is not nearly as well thought out and tested as the rest of the code, and I believe that a team picking up our code next year should take a good hard look at it.
OSU High-Altitude Rocket Team