Finally!
Today we delivered our reports, finishing the subject in which we worked with Edge of Space 2. Fear not, however, the project is not dead. As you may have noticed, the web pages have got very little attention, and we would like to blame the report writing for that – at least to some extent. I hope we can manage to get the wiki and home page up to date about the progress. The report we just delivered contains lots of details about our design process and the choices we have made along the way, and we hope to get these details on the web as well.
The team members are likely to focus on preparing for exams in the following period, but all are prepared on finishing Edge of Space within the year. Stay tuned for updates!
onsdag 2. mai 2012
søndag 25. mars 2012
Professional PSU-boards and finished motherboard
A lot is going on with the electronics these days. Power supply boards from China was received a few weeks ago, and the motherboard was milled this week. The firmware for the power supply board is finished, and the motherboard firmware is under work. Currently the motherboard parses the GPS, the IMU, controls RC-servos and sends some test telemetry packets - everything is done with a feature rich PIC24FJ256GA106 microcontroller. Lets see some pictures!
 | |
| Picture 1: Professionally produced power supply |
 | ||
| Picture 2: Professionally produced power supply |
 |
| Picture 3: The EOSEFF motherboard stacked on the PSU |
fredag 2. mars 2012
Software development
Not a single word has been published about the software – a critical component in the project. It is about time we give an update about what has been done so far and what plans we have for the finished program.
The server software was left in a not-far-from finished state weeks ago, awaiting a useful client and finished hardware to test against before being finalised. The server is developed in GNU/Linux and is planned to run on a GNU/Linux system at the launch day, so little effort has been put into making the server software cross-platform compatible (as opposed to the client software). The choice of language is Perl. Perl was chosen solely because I wanted to practise the language, not necessarily because it was the best tool for the job.
The server connects to a rotctl TCP/IP dæmon either running on the same machine or another host and a radio on RS232. The server reads data packets from the radio, calculates checksums and stores the packets in a buffer. Numerous clients can connect to the server on TCP/IP using a ascii-based communication protocol and they have simultaneous read access to the packet buffer. Access is restricted on control of the aircraft and of the rotor (if not automatically controlled by the server itself based on position data from the aircraft), so that only one client is in control at a time. Clients can be kicked in order to get the access privileges, and clients will automatically be kicked if they cease to send alive packets.
The idea was to possibly make more than one client application, one mainly for monitoring telemetry and one for aircraft control. We may just stick with one application as the protocol allows the user to choose whether to control the aircraft or not, and the various views in the client program can be hidden if not needed. So far, the only two finished modules in the client program are the raw packet data view and the attitude indicator / artificial horizon. We wish to thank Thomas Ingebretsen for providing the source code for his attitude indicator widget, upon which our widget is based.
The server software was left in a not-far-from finished state weeks ago, awaiting a useful client and finished hardware to test against before being finalised. The server is developed in GNU/Linux and is planned to run on a GNU/Linux system at the launch day, so little effort has been put into making the server software cross-platform compatible (as opposed to the client software). The choice of language is Perl. Perl was chosen solely because I wanted to practise the language, not necessarily because it was the best tool for the job.
The server connects to a rotctl TCP/IP dæmon either running on the same machine or another host and a radio on RS232. The server reads data packets from the radio, calculates checksums and stores the packets in a buffer. Numerous clients can connect to the server on TCP/IP using a ascii-based communication protocol and they have simultaneous read access to the packet buffer. Access is restricted on control of the aircraft and of the rotor (if not automatically controlled by the server itself based on position data from the aircraft), so that only one client is in control at a time. Clients can be kicked in order to get the access privileges, and clients will automatically be kicked if they cease to send alive packets.
The idea was to possibly make more than one client application, one mainly for monitoring telemetry and one for aircraft control. We may just stick with one application as the protocol allows the user to choose whether to control the aircraft or not, and the various views in the client program can be hidden if not needed. So far, the only two finished modules in the client program are the raw packet data view and the attitude indicator / artificial horizon. We wish to thank Thomas Ingebretsen for providing the source code for his attitude indicator widget, upon which our widget is based.
Raw data packet view (data shown is obviously just unrealistic testing data)
Artificial horizon widget (based on the work of Thomas Ingebretsen)
The client software is constantly worked on and it gets major upgrades every week. At this very moment the preferences/settings widget is being finished, and the next plans are (not necessarily according to priority):
- Update status view
- Implement a widget containing the most important measured data, possible shown in graphical dials
- Update network protocol
- Implement controls (read from joystick and throttle controls) and sending data packets to server/aircraft
- Finish server
- Add (user-defined) alarms e.g. when battery voltage drops below a certain limit
- Add plotting
- Finish attitude indicator
- … many more!
søndag 26. februar 2012
Board to board communication and power supply
Three weeks ago a prototype of the power supply board was milled at NTNU, and the last few days it has been tested thoroughly.
The microcontroller software is pretty much finished, and board-to-board communication has been successfully tested with another microcontroller running as an I2C-master, as can bee seen in the picture below. More specifically, the power supply will send information about voltage levels and current draw to the main board, which in turn will be sent down to the ground station and displayed on a monitor.
It all seems to work well, although it needs some serious testing over long durations before it is considered stable. The heat dissapation has been tested under maximum loads, and the temperature seems to be within an acceptable range.
Professional PCBs are being made in China right now, so the prototype seen in the pictures above will be replaced in near future. The final PCB layout can be seen below:
Stay tuned!
 |
| Picture 1: Power supply prototype |
 |
| Picture 2: Successful test of communication between PSU prototype and I2C-master on breadboard |
Professional PCBs are being made in China right now, so the prototype seen in the pictures above will be replaced in near future. The final PCB layout can be seen below:
 |
| Picture 3: Final PCB layout |
onsdag 22. februar 2012
Some calculations
In NX we have now modelled all the induvidual components. This provides an effective way to let us tweak the design to get the optimal use of space, and optimal weight distribution.
Calculations for insulation demand is also a crucial part for this spacecraft. On the journey the craft will be affected by temperatures down to -60 degrees celsius. We must make shure our materials can keep their mechanical properties. And we must ensure that the electrical components is sufficiently insulated. The body will be made of plastic-foam with good insulation properties. The electrical components generate heat, about 15-20 Watt for our craft. This means that the insulation should not be too large either, since the electrical components need some cooling aswell.
Calculation for the wing-profile is hand calculated, and supplemented with aid from X-foil and Foil-sim. The wing will be made in plastic-foam, reinforced with carbon tubes, and coated with fiberglass.
Calculations for insulation demand is also a crucial part for this spacecraft. On the journey the craft will be affected by temperatures down to -60 degrees celsius. We must make shure our materials can keep their mechanical properties. And we must ensure that the electrical components is sufficiently insulated. The body will be made of plastic-foam with good insulation properties. The electrical components generate heat, about 15-20 Watt for our craft. This means that the insulation should not be too large either, since the electrical components need some cooling aswell.
Calculation for the wing-profile is hand calculated, and supplemented with aid from X-foil and Foil-sim. The wing will be made in plastic-foam, reinforced with carbon tubes, and coated with fiberglass.
søndag 5. februar 2012
EOS2 Sensor board
The first revision of the sensor board is completed, and is ready to be milled and tested. This board contains on-board temperature, humidity, absolute pressure and differential pressure sensors. In addition there is a connector for external temperature and humidity sensors. The differential pressure sensor is used to measure air speed with a Pitot tube.
The sensor board will interface with the other EOS2 boards via the EOSEFF header, which contains power and an I2C bus connection. More information on the sensor board can be found at the wiki.
https://wiki.edgeofspace2.com/wiki/sensorBoard
The sensor board will interface with the other EOS2 boards via the EOSEFF header, which contains power and an I2C bus connection. More information on the sensor board can be found at the wiki.
https://wiki.edgeofspace2.com/wiki/sensorBoard
onsdag 1. februar 2012
Airplane Design
 |
| Hand sketches of the airplane design. |
The main focus of the design is to get an airplane that is stable, and can manouver in low density air. The solution is a glider plane with a pusher propeller. With a pusher design, we will ensure the field of view of the camera is not blocked by the propeller.
 |
| 3D model of the airplane design. |
We want to use some of the aspects from gilders, such as self-stabilizing dihedral wings and large lift. The wing span will be approximately 2 meters and that should give us enough lift to support the payload. Most of the design has been based around the payload box and what we want to put inside the airplane. The circuit boards are stacked on one plate so that we have a modular design that will support all the circuit boards that's required.
 |
| Stacked circuit boards within the airplane body. |
We also have room for two cameras, a parachute, radio transceiver and the pusher propeller. The motor for the pusher propeller will be partly inside the body to account for the low temperatures in the upper stratosphere.
 |
| Pusher propeller motor inside the airplane body. |
We have decided to use styrofoam for the body because of the good insulation properties. We are also working on a heat model to make sure that all the components inside the body will be working in their operating temperature range. It will be posted soon.
Abonner på:
Innlegg (Atom)