Home

CanSat Ground Station

1. 5 3 Fixed Priority Scheduling BA Verification seare pata AA Wired Communication with Remote User Client 6 1 Overview e ee eee 6 2 Ethernet Controller 6 3 Integrating the uIP TCP IP Protocol Stack 6 4 Maximum Throughput and Verification RF Communication with CanSat 7 1 Basic Setup o 7 2 Link Budget visas Sore ee ere Ae A 7 3 Software for RF Communication CAs NET Cation x 2 was oe des a Raabe ae ata edd Modelling of Pan amp Tilt Platform 8 1 Model Overview 024 8 2 Combining the Model 00 Contents 13 ose ty eth Sd a 13 po date Sh eect ty a 17 wow Suet ele aon de 19 10 11 8 3 BEICHION ae ta PPh ee A es Dil A A A A 56 8 4 Non linearity in Elevation Model o oo o 97 8 5 Parameter Determination and Model Verification 58 8 6 Final Expression eer cda a ho oe eo Se ee aE ee 63 Feedback Control of Pan amp Tilt Platform 65 9 1 Interpretation of the Requirement 2004 65 9 2 Controller Design 2 2 ee ee 66 9 3 Implementation 0 0 0 0 cee ee 75 9 4 Verification of Controllers 20 2 000 0000 eee ee 86 Remote User Client 91 10 1 Overview and design 2 2 a 91 10 2 User Interface and Functionalities 2 0 0 0 0 02 0 0008 93 103s ir A A oh oe kA ate ie Gk Ee ae Os 100 10 4 Receive and Send Methods
2. 0 2 000000 0085 101 10 5 Verification 23 huso be a as A eee a ee Pe Les Tas Be 103 10 6 Further Development 0 0 0 00000 eee eee 103 Scheduling of Ground Station Software 105 11 1 Software modules 2 es 105 11 2 Scheduling s oc isda E de eae So ee ae we Soe we Re Ge 106 Part III Assessment amp Conclusion 12 Acceptance Test 117 POT A eis Ek A ee aria a ae a oe Ge he AO ee 117 13 Conclusion 121 14 Perspectives 123 14 1 Improvements td aa aa 123 14 2 Usage in CanSat Competitions e e e 124 References 125 Appendices 128 Ay Word Dister 4 ty a Yie aora a A a o a a ds 130 B WARP Protocol Specification o o 131 C RUC Protocol Specification e e 135 D ulP Example Mainloop with ARP_ o 137 E ARTOS Function Prototypes oea o yke ei e e e 139 F CanSat Test Stand in ee a 145 G Schematic Part list and Physical Construction 146 Test amp Measurement Journals 148 1 Range Test of RF Communication o 150 2 Test of RUC CSV File Saving o e en 153 3 Model Parameter Determination e 155 4 Controller Verification e 160 5 Measurement of Worst Case Execution Times 163 6 Acceptance Test l M sus sa e henaa a a a a aA 166 7 Acceptance Test 2 uo ma da GE Sw e ee ee ee es 167 vii CHAPTER Introduction In August 2010 four student
3. Elevation cog wheel diameter Motor shaft diameter Elevation motor Tower diameter Azimuth Foot outer diameter motor Azimuth cogwheel diameter Figure 3 1 The platform being tested 3 3 Equipment list The following equipment has been used Instrument AAU No Make and type PC Linux OS Voltage supply 61398 Hameg triple power supply HM7042 5 Scale 08432 Mettler PJ Ruler Table 3 1 Equipment used to test the ground station antenna platform 155 Journal 3 Model Parameter Determination The following software has been used for data collection and processing e The RUC software e Matlab e OpenOffice Calc 3 4 List of Tests The following tests have been performed 1 Determination of gear ratios and moments of inertia 2 Sampling system performance Azimuth 3 Sampling system performance Elevation 3 5 Test 1 Determination of Gear Ratios amp Moments of Inertia In this test a set of measurements are made on the dimensions of cog wheels and moving parts The weight of the moving parts is also measured making it possible to determine the moments of inertia Testing Procedure 1 Using the ruler the diameter of each cog wheel is measured The measurements are noted 2 The antenna platform is split into the following parts The foot the tower and the antenna 3 The diameter of the foot and the width of the tower is measured and noted 4 The length of the antenna is m
4. l datasheets arm7tdmi technical reference pdf 2 datasheets mini max arm technical manual pdf 3 datasheets lpc2138 datasheet pdf 4 datasheets 1pc2138 user manual pdf 5 datasheets rfml2b pdf 6 datasheets rf12b pdf 7 datasheets arm_architecture_reference_manual pdf 125 References 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 FreeRtos Stack usage and stack overflow checking Downloaded 13 12 2010 Online Available http www freertos org Stacks and stack overflow checking html H Schigler Introduction to realtime systems Downloaded 01 12 2010 Online Available http www control auc dk henrik undervisning sandtid kursus note mm1 html A S Tannenbaum and A S Woodhull Operating Systems Design and Implemen tation 3rd ed Prentice Hall 2006 H Schigler Realtime systems job scheduling Downloaded 01 12 2010 Online Available http www control auc dk henrik undervisning sandtid kursus note3 pdf Rquirements for Internet Hosts Communication Layers Internet Engineering Task Force Std RFC1122 Oct 1989 A Dunkels uip tcp ip stack homepage Online Available http www sics se adam uip Microchip ENC28J60 datasheet 2008 O A S Tannenbaum Computer Networks 4th ed Prentice Hall 2002 A Standard for the Transmission of IP Datagrams over Ethernet Networks Internet Engineering Task Force Std RF
5. It can be seen that the mechanical time constant is much higher than the electrical meaning that the frequency response at the lower frequencies of operation is dominated by the mechanical elements It is therefore safe to ignore the effect of La and remove it from the equations 8 13 is thus reduced to Vi s In s Ra K wm s 8 16 55 Chapter 8 Modelling of Pan amp Tilt Platform By Laplace transforming eq 8 12 and inserting in 8 14 we have SImWm S KIa s wm s S Jm Bum s 8 17 Where N is the product of internal and external gear ratios By combining eq 8 16 and 8 17 we get Wm s Nk 8 18 Vils RadmN RaJi s RaBN2 K2N Which is a transfer function of angular velocity over input voltage Since the goal is an expression that gives the position of the antenna the velocity must be integrated and divided by the gear ratio SAS a dl de lt x RaJmN R J s Rg BN2 K2N 8 19 NK a 8 20 RaJmN RaJi s RaBN K N s And the desired transfer function has thus been found Before it can be used though all the necessary parameters must be determined Also the effects of non linear elements that affect the system must be taken into account 8 3 Friction The total friction ry in the rotating system can be decomposed into static friction stic tion Ts dry friction coloumb friction Te and viscous friction wm B The dif
6. uip_len encReceivePacket uip_buf UIP_BUFSIZE network_device_read if uip_len gt 0 if BUF gt type htons UIP_ETHTYPE_IP uip_arp_ipin uip_input If the above function invocation resulted in data that should be sent out on the network the global variable uip_len is set to a value gt 0 x if uip_len gt 0 uip_arp_out encTransmitPacket uip_buf uip_len network_device_send else if BUF gt type htons UIP_ETHTYPE_ARP uip_arp_arpin If the above function invocation resulted in data that should be sent out on the network the global variable uip_len is set to a value gt 0 x if uip_len gt 0 encTransmitPacket uip_buf uip_len network_device_send else if timer_expired amp periodic_timer timer_reset amp periodic_timer for i 0 i lt UIP_CONNS i uip_periodic i If the above function invocation resulted in data that should be sent out on the network the global variable uip_len is set to a value gt 0 if uip_len gt 0 uip_arp_out 137 Appendix D uIP Example Mainloop with ARP encTransmitPacket uip_buf uip_len network_device_send Call the ARP timer function every 10 seconds if timer_expired amp arp_timer timer_reset amp Sarp_timer uip_arp_timer return 0 138 Appendix E ARTOS Function Prototypes Appendix E ARTOS Function Prototypes 139 Appendix E AR
7. The group considers the project a success as most features and requirements are fulfilled The concept of tracking a CanSat by means of wirelessly transmitted GPS coordinates has not been tested directly but a simulation of a launch shows that the antenna control system has no issues with tracking a CanSat 122 CHAPTER Perspectives This chapter deals with ideas for improvement and further development of the designed system intended for a possible continuation of the project This includes examples of hardware components that could have been chosen differently and how different methods could have been used to implement certain features It is also described how the system could be used in CanSat competitions and which additional features could be useful in this regard 14 1 Improvements As noted in the previous chapter it hasn t been possible to satisfy all the stated require ments Most notably is the inability to retrieve radio packets from a CanSat module beyond very short distances As the exact cause of this problem is unknown a solution is also uncertain A possible way to solve this problem is further debugging of the current setup Another would be to choose different radio transceiver modules possibly with higher transmission power Different modules would hopefully interact better with the system while higher transmission power would increase the transmission range and thus meet the requirement Beyond this
8. 47 30urnals wcet_determination arduino 48 journals accept_test2 test diff 167 Journal 7 Acceptance Test 2 7 6 Measurement Uncertainties The worst case system load might be higher than indicated as stress testing can be difficult However it is assessed that measurement uncertainties in this test can be neglected 168
9. which is activated by the receiving PC when the TCP segment size is approaching the max imum segment size The delayed ACK algorithm implemented by most TCP receivers means 24 1 ACK must be generated within 500 ms of the arrival of the first unacknowledged packet 2 ACK should be generated for at least every second full sized segment 3 Since receiver and transmitter might not agree on the size of a full sized segment it is recommended that an ACK is generated for every second segment in order to avoid stretched ACKs The delayed ACK algorithm enables the receiving application to update the receive window and send an immediate reply without generating multiple TCP segments 19 Since uIP can have only one outstanding Ethernet frame at a time the ground station will wait for up to 500 ms plus the round trip time before sending a new TCP segment when the delayed ACK algorithm is activated Obviously a packet rate of 2 Hz and an Ethernet frame size of maximum 1500 B will cause a poor throughput rate The theoretical maximum throughput for uIP is r 6 1 brut ta where r is the maximum throughput 2 S is the segment size B tri is the round trip time of the network link s ta is the delay before an ACK is generated by the receiver s There are two solutions to the delayed ACK problem applicable to uIP The first solution is to split maximum sized segments into two segments and wait for the acknowledgement This soluti
10. 4 3 Ground Station Subtasks To support the design of the ground station Hard Real Time Hierarchical Object Ori ented Design HRT HOOD is used The method is used as described by Burns and Wellings 13 HRT HOOD is a structured software design method for hard real time systems The ground station contains both software and hardware parts but the design of the ground station is done by considering it solely as a software system This is done because the interface between the different parts of the system lie in software HRT HOOD is hierarchical and uses a top down approach It is object oriented not in the C Java understanding of object orientation but in the way that all tasks modules are described as objects that provide interfaces for other objects to use The objects express pieces of code to execute and not data structures HRT HOOD doesn t concern itself with the data structures of the software system at all The design method is based on decomposing the complete system into a number of objects These objects can then again be analyzed and decomposed into smaller objects This hierarchical decomposition continue until a sufficient amount of subdivision is achieved The concept of breaking down a system into smaller more manageable subsystems is a common base for almost all system design methods What is special about HRT HOOD and the reason for choosing it is that it provides a framework for graphically representing the objec
11. e Requirement 3 No more than 200ms may pass from a package is received on the ground station s wireless link until the processed package containing this informa tion is sent to the RUC if this is connected through a direct Ethernet cable Requirement 7 The connection between ground station and CanSat must be able to transmit 60 byte packages at a distance of 1 5km with a maximum package loss of 10 This is assuming that the CanSat and ground station are placed in line of sight the CanSat is within the antennas half power beamwidth and the package transmission rate is 5 Hz In this chapter a radio transceiver and antenna for this will be chosen The available range in this setup will be calculated to see if it is sufficiently large Hereafter the software for the RF communication is designed 7 1 Basic Setup It has been chosen to use the RFM12B 11 based on the RF12B chip 12 RF transceiver from Hope RF as the basic building block for the wireless link between the ground station and the CanSat These modules are very cheap which makes it affordable for the upper secondary schools that have to build their own CanSats They are based on Frequency Shift Keying FSK and are available for 3 frequency bands 433 MHz 868 MHz and 915 MHz In Denmark the 868 MHz frequency band can be used without a license 25 so the 868 MHz version is used Within this band there are several frequencies which the RFM12B can use By selecting a d
12. e k 29 57 elk 1 9 60 The expression in equation 9 60 can now easily be incorporated into an algorithm that can be programmed As it is seen In figure 9 20 on the following page a simulation of 85 Chapter 9 Feedback Control of Pan amp Tilt Platform the continuous and discrete controller coincide well There are though a slightly higher overshoot on the discrete controller This can be solved by raising the phase margin in the lead design It is assessed that the overshoot doesn t pose a significant problem for the system The simulink simulation of the continuous and discrete controllers can be found on the CD 0 1 4 T T T T T T T Discrete Continuous 1 27 0 8 0 6 a ONON e vaa 4 0 4 0 2 0 i i li li j li li j i 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 Figure 9 20 Simulation of the continuous controller compared to the discrete controller The type of controller that should be utilized is selected on the RUC The controller algorithm then needs to incorporate the selected controller In the beginning of the algorithm the selected controller calculates the output Afterwards the algorithm is the same as for the azimuth controller The calculations of output are as follows Proportional Controller The calculation of output is the same as for the azimuth controller Proportional Controller With Non linearity Correction The calculation of output is almos
13. implemented in the ground station Clicking these buttons will send the correct packages although no corresponding action will be performed by the ground station Ground Station CanSat Packetloss 0 Get Saved Data Figure 10 15 Ground Station CanSat panel The Button Get Saved Data is used to send the ground station command 3 The status label Packet loss informs the user about the packet loss rate on type 0 packages The label Packet loss seen on figure 10 15 informs the user of the packet loss This packet loss is calculated from the package number set by the CanSat on all type 0 packages The CanSat increments this number by 1 each time a new package is send If the RUC receives packages skipping some numbers this will indicate the packet loss Command number 0 1 and 4 are used to specify whether the ground station should track manually automatically or calibrate the antenna respectably These are imple mented in the Antenna Control panel with the buttons Manual Automatic and Calibrate seen on picture 10 13 on the preceding page 99 Chapter 10 Remote User Client When using conformance class 1 the user will only be able to use the manual antenna control and the calibrate button If the RUC is in conformance class 2 the user can enable automatic antenna tracking by specifying the ground station location Until then the Automatic command is grayed out This is done because the automatic CanSat tracking
14. the link has a theoretical gain margin of 20 6dB with the used antennas In practice a transmission range of up to 400m has been achieved It has been suggested that the link could be improved by looking into impedance and polarity mismatch of the antennas and increasing the transmission power The downlink performance is poor even at very short distances which most likely is an error in the setup It is thereby concluded that the low level radio modules are not straight forward to configure and interface to Modelling of the pan amp tilt platform has been performed in order to design an efficient controller A linear second order transfer function has been derived for each of the two axes The transfer function maps an input voltage to an output angle In order to allow the platform to be modelled as linear systems compensation for non linear phenomena has been introduced Both axes are affected by dry friction which is easily outweighed by applying a constant offset voltage to the motors More difficulty has been caused by the disturbance torque applied to the elevation because of the center of gravity is moved when the antenna is rotating A non linear correction has reduced the impact of this problem The model is considered accurate enough to design an efficient controller A feedback controller has been designed for each of the two axes of rotation The controllers have been designed using time domain specifications and frequency domain de
15. 20 instantly The 20 are chosen because it gives a more realistic situation of how a input step under a CanSat launch will be A to large step will also saturate the output of the motor driver and the controller will no longer be linear In test 5 the same step will be performed for the azimuth controller In test 6 the best elevation controller is selected as specified in section 9 4 on page 86 and the CanSat launch is simulated with respect to acceptance test 6 seen in section 3 3 on page 19 4 4 Test 1 Elevation P Controller Without Non linearity Correction In this test the elevation position is set to 20 initially This is done to test what the effect of running the controller with the non linearity correction disabled The elevation position is then changed to 40 instantly The test results can be found here 927 A plot of the test can be seen in section 9 4 on page 86 4 5 Test 2 Elevation Lead Controller Without Non linearity Correction In this test the elevation position is set to 20 initially for the same reason as in test 1 The elevation position is then changed to 40 instantly The test results can be found here 0928 A plot of the test can be seen in section 9 4 on page 86 27 5ournals controller measurements stepelevPRegInfo csv 28 journals controller measurements stepelevLeadRegInfo csv 160 Journal 4 Controller Verification 4 6 Test 3 Elevation P Controller With Non linearity Cor
16. 60630 603074 m 9 49 The ground station position is now subtracted from the satellites x 603074 603291 217 m 9 50 y 6334898 6334497 401 m 9 51 z 400 0 400m 9 52 The values for azimuth and elevation can now be found using eq 9 39 and 9 40 401 az arccos 28 4 9 53 2177 4012 4 el arcsin a 41 3 9 54 217 4012 400 9 3 4 Motor Driver In order for the system to be able to control the pan and tilt platform a motor driver has been constructed The motor drivers function is to provide the motors with the correct voltage level 12 V and make it possible for the motors to consume the needed amount of current 1 03 A nominal In other words the motor driver takes care of the electrical link between the ground stations ARM board and the platform An outline of how the motor driver motors and ARM board are linked together can be seen in figure 9 16 on the next page To control the speed of the motors it has been chosen to use PWM signals from the ARM board as mentioned earlier For direction control it has been chosen to use an output pin for clockwise CW and one for counterclockwise CCW rotation of each motor A schematic of the constructed motor driver can be seen in figure 9 17 on the following page 81 Chapter 9 Feedback Control of Pan 4 Tilt Platform gt M lt 5 Encoder Motor Driver m eee lt Figure 9 16 This figure illustrat
17. 7 Elevation motor Azimuth motor ARM board Motor driver E Figure G 1 The physical contruction of the ground station 16 physical_contruction construction pdf 17 schematics arm_total lt sch pdf gt 146 Appendix G Schematic Part list and Physical Construction R3 seriel output for debugging RFM12B X26 O 3 X2 99 MISOT REMIZB_CS X2 89 REMI28_19 SCK1 x2 79 MOSIT X2 69 X2 53 GND X2 49 X2 39 RXD1 13Antenna X2 25 XD A X2 12 PE lt ARM Board al E a S El 3 a g CEECEEREENI aR ie m F EU IEIITTTT a te Se DD e z pe oto 1 P122 REMT2B_CS 990 5 aje ez Je pro STOW B 6 1319 S J6 EN AN B T 1519 She 10 9 3 5l E TOW_CW 8 1719 She 8 7 2 pray ON 9 1919 Soo 6 5 1 prie HANE lo 02 ANT CCW 10 4 3 LCD Connector JTAG 2 1 31 GND 5 van ye 5 8 i g Pm gt e 8 o PWMZ E l 3 12V TOW_CW 2 oL A 3 ca m 7408N E 100n a a ay Ici 12V py BR iman ak 2 vec vs gt lo Motor 4 al a 0 2 Q A tai ENABLEA SENA fig R2 Mma M13 TOW_CM ENABLE_B SEN_B 0 2 ES x 7408N 5 input oum a 2 INPUT2 OUT2 vi 1 INPUT3 ours H3
18. 7 3 Approach The RUC establishes a connection to the ground station and a specific CanSat ID is entered The CanSat stand in is then set to transmit packages with the previously mentioned ID On the ground station a timer is started each time a CanSat package is received and stopped when the package is transmitted to the RUC This time is then saved This is repeated for 1000 packages If the value in the timer exceeds the value stored the saved value is overwritten with the new value In this manner the saved time will represent the worst case package processing time for the ground station The test will be done with light and heavy system load in test 1 and 2 respectively 7 4 Test 1 In this test the ground station is only receiving CanSat telemetry packages and trans mitting these to the RUC This simulates a light system load After 1000 packages the worst case processing time is found to be 7 ms 7 5 Test 2 In this test the ground station is receiving both CanSat telemetry packages from the CanSat Stand in and ManuelAntennaCrtl packages from the RUC while still transmit ting the CanSat telemetry packages to the RUC By using the arrow key controls inside the RUC a stream of ManuelAntennaCrtl packages are send at a high rate Based on these packages the ground station must constantly adjust the antenna accordingly which simulates a heavy system load After 1000 packages the worst case processing time is found to be 54 ms
19. CSV file 9 4 All packages in this CSV file have been received correctly The counter on the ground station was able to count 4514 packages received from the CanSat stand in with the matching ID This corresponds to an estimated package rate of 6 3 Hz As seen in the previously mentioned CSV file 4514 packages was received on the RUC It is observed that these two numbers are matching one another 6 5 Measurement Uncertainties No obvious measurement errors was found during this test 45 3ournals accept_testl arduino 46 5ournals accept_testl measurement csv 166 Journal 7 Acceptance Test 2 Journal 7 Acceptance Test 2 7 1 Purpose The purpose of this test is to determine if the system meets requirement 3 in the re quirement specification seen in section 3 2 on page 17 This test will be performed with respect to acceptance test 2 seen in section 3 3 on page 19 7 2 Test Object The test object is the fully implemented system described in chapter 4 on page 23 Used Equipment Instrument AAU No Make and type CanSat stand in Arduino Mini Pro w RFM12B and 8 63cm wire whip antenna Table 7 1 Equipment used in the test The software running on the CanSat stand in is based on the kernel and RFM12B driver code developed by group 502 It can be found here 4 The CanSat stand in is described further in appendix F on page 145 The software running on the ground station is patched with the patch found at 48
20. PC establishes a TCP connection to the ground station through Telnet and the traffic on the Ethernet link is captured by the network analysis tool Wireshark Data is captured for 200s The capture file can be found on the cd 63 Figure 6 5 shows the throughput during the test and the ACK delay from the PC receives a TCP packet until an ACK is generated Only bytes in the TCP data section is counted as throughput Each packet sent contained 473 TCP data bytes The figure 70 T T T T T T 200 a Q o o v D E E 40 rl IS gt ARA i Mey oa it Wer tw bel Wy MES iY be 100 3 A a pA OE LE ity eee Puw Y x 1 l 1 4 O 5 450 r TCP Throughput E ACK delay i 1 1 1 L E i i L 0 20 40 60 80 100 120 140 160 180 200 Figure 6 5 Throughput and ACK delay for the communication between ground station and a PC shows an ACK delay of less than 200 us which won t be the bottleneck of the connection A throughput of 65 sB is achieved which is sufficient to fulfill the requirement of 7 1 sB derived in the beginning of this chapter Summary A functional lightweight TCP IP stack has been designed and implemented using the uIP TCP IP library and the ENC28J60 Ethernet controller This provides the link internet and transport layers on which the RUC application layer protocol is implemented The execution of uIP has been structured into three tasks The maximum throughput has been tested under g
21. RUC packages are byte stuffed as defined in the RUC application layer protocol and put together into a single TCP data section before returning control to uIP The buffers that contained the RUC packages will be freed as soon as the TCP segment has been acknowledged Receiving RUC Packages The buffer system is not used for receiving packages from the remote user client Since TCP provides a byte stream to the application layer a single RUC package sent from the remote user client may be split into several TCP segments When the ground station is receiving the TCP data it will remove the stuffing bytes and assemble the data into a single RUC package within the appca11 When a whole application layer RUC package has been received a call will be made to the function ethPkgHandler which interprets the content of the package and calls the other software modules passing on the settings from the package This is illustrated in figure 6 4 on the preceding page by the arrows leaving the Ethernet software module 42 Section 6 4 Maximum Throughput and Verification 6 4 Maximum Throughput and Verification The design of the Ethernet communication module has now been discussed A verifica tion test will determine if it fulfills the requirements specified Initial tests have shown that TCP throughput decreases significantly when using large TCP segment sizes This is due to the delayed acknowledgement ACK algorithm described in RFC1122 19
22. Rate of 0 1 is required 12 This means that the input power to the RFM12B should be at least 102dBm if said BER is to be achieved Therefore it can be seen that there is 81 4dBm 102dBm 20 6dB more power available at the receiver than what is theoretically required This value is referred to as the link margin The above calculation assumes the following e Perfect polarization matching in orientation of antennas Both the transmitting and receiving antennas are mostly linearly polarized The way the antenna on the ground station is mounted makes it horizontally polarized The orientation of the antenna on the CanSat will vary during flight If the two antennas orientation have their polarization orthogonal to each other then no power will be transferred while having them parallel to each other will give the result described above e Perfect impedance matching between RF transceiver and antenna on the ground station The antenna used has an impedance of 50 26 while the transceiver has an impedance of 8 7 j66 Q This will result in some power lost due to the signal reflections in this connection e Perfect impedance matching between RF transceiver and antenna on the CanSat Again unmatched impedance will cause lower power transmission due to reflec tions at the connection between the RF transceiver and antenna e No reflections of radio waves possibly creating destructive interference which can reduce the receive
23. TCP implementation is available in the standard library Using this the Ethernet connection is presented as a socket that operates on separate 101 Chapter 10 Remote User Client bytestreams One stream for each direction This offers an easy to use interface where individual bytes are written and received in an output stream and an input stream The socket is first created by simply passing the IP and port number to the Socket constructor 10 4 1 Send Method When packages are to be sent they need to be assembled in accordance with the RUC protocol specified in appendix C on page 135 In most cases packages are sent when the user clicks various buttons inside the GUI This will call a method which in turn forms the package and writes it to the output stream The method of operation is as follows 1 A switch statement decides what to do based on the package type 2 Bytes are retreived from elsewhere such as text fields and arguments and input validation is performed 3 These bytes and more info such as length and package type are added to a Java ByteBuffer in accordance with specifications 4 The ByteBuffer is added to a final ByteBuffer where start byte and escape characters are added where needed 5 The final ByteBuf fer is written to the output stream Using the above method packages can be sent from anywhere within the program by doing a simple function call However this has to be done with respect to threa
24. an open source kit for constructing CanSats This kit is supposed to make it easy for students in upper sec ondary schools to participate in CanSat competitions Due to technical interests it has been chosen to build a ground station that can track these CanSats It can be argued that it is not realistic that competition participants build a replica of the ground sta tion themselves as the construction of a CanSat is a large enough challenge in itself The ground station may be considered by organisers of CanSat competitions as an extra service to the participants Approach The developed system consists of an embedded system that receives data from a CanSat and controls a pan amp tilt platform with an attached Yagi Uda type antenna to point in the direction of the CanSat A PC based remote user client RUC is connected to the ground station through an Ethernet connection Received telemetry data is forwarded to the RUC and saved there The requirements for the platform have been found through analysis of former CanSat competitions In contrast to tracking real satellites the CanSat tracking system must respond more quickly to be able to receive telemetry data during the rocket propelled launch Furthermore position data must be updated frequently It has thus been speci fied by this project that the CanSats must send GPS position data with an update rate of 5 Hz if automatic antenna control is used To support the design of the groun
25. and only provides schematics guides and software that can be used as the basis for constructing the CanSats It is up to the competition participants to build the CanSats on their own The ground station is made to be used with these CanSats but it is unreasonable to ask students to build the ground stations on their own Mass production is not likely as only few ground stations are required and the price would not be acceptable compared to the value added to the CanSat competitions Therefore it could be considered that the organizations arranging the competitions could be interested in building a few ground stations and then providing these to the participants It is also possible that on ground station could be set up by the arranging organization to retrieve telemetry data from all CanSats that are in the air at the same time This would require modifying the ground station system to be able to receive data from multiple CanSats at the same time Another direction of development could be to retrofit the ground station to serve different purposes For instance instead of only CanSats it could be reconfigured to track any moving source This could even include real satellites in orbit 124 References Danish National IT and Telecom Agency 2010 Legal scripture regarding radio transmissions in denmark Downloaded 16 09 2010 Online Available https www retsinformation dk Forms R0710 aspx id 29212 B3 Forsknings og innovatio
26. around this problem is to add compen sation for the non linear component based on the current angle of elevation This can be done by calculating the torque from eq 8 29 on page 58 and applying a voltage that 2The position has been converted to radians and the time is specified relative to the first sample 3 journals parameter_determination simulink lt gt 60 Section 8 5 Parameter Determination and Model Verification 3 5 T T T T position rad 0 57 J Measured Simulated 0 1 1 1 1 0 2000 4000 6000 8000 10000 time ms Figure 8 9 A plot showing the sampled and simulated curves with the adjusted inertia value cancels it out Assuming steady state the voltage is given by Ra V a a 8 43 0 190 3 65 Te l AA sin a 133 1033 si sin 9 0 812 8 45 By doing this the system should in theory behave like a linear system in steady state and allow the friction parameters to be determined To be able to do this however the non linear compensation needs to be accurate which must also be verified An attempt to do this has been carried out by testing the system performance at constant voltages with the non linear compensation first enabled and then disabled In both cases the antenna starts out pointing as far down as possible and moves up when the voltage is applied Figure 8 10 on the following page shows the resulting position curves In a linea
27. based on off the shelf components The kit will consist of e An onboard CanSat controller A radio communication link on a license free band e A sensor sub platform possibility to extend with custom sensors e A ground station for communication with CanSat during flight In the fall semester 2010 at the time of writing four groups of students at the department of Electronic Systems at Aalborg University are doing semester projects regarding the development of this kit Three groups put their focus on the CanSat itself and one group focus on the ground station The groups have cooperating shared experiences and a common radio communication protocol has been developed in order to ensure compatibility between CanSats and ground stations This report is the documentation of the work done by group 10gr503 The starting point of this particular project is the development of the ground station with an automatic Chapter 1 Introduction satellite tracking antenna Acquisition and saving of the CanSat telemetry data is a crucial part of the CanSat project Since the rocket propelled launch is a one time opportunity the main mission of the ground station is to gather and save as much information about the flight as possible To accomplish this task precise tracking of the CanSat is necessary in order to minimize the amount of lost information Part I Project Specification CHAPTER Preliminary Analysis The purpose of this ch
28. can t function until the ground station is aware of its own location Notice a status label is placed in the Antenna Control panel see figure 10 13 on page 98 to inform the user of the current tracking being used 10 2 7 Event Log In order to keep track of current and past events a log is implemented into a tab in the GUI As the RUC progresses information is printed into the event log This enables the user to easily monitor different information such as when certain packages are received sent and whether errors occured In the case of the latter the focus will be shifted to the event log as to alert the user of errors or other critical information The following is a list of some of the events that can occur during RUC operation e Connection information IP Port connection status and more e Input errors Invalid values in text fields e Package information Received and sent packages After a short time the log will get quite long This can be a problem as the user cannot see all the lines at once and normally only the oldest events are visible Therefore an optional autoscroll feature is implemented that will scroll down to the most recent events A typical example of the eventlog in action can be seen in figure 10 16 r 4 Remote User Client e 7 te l le j File Help Configuration Ground Station Control Event Log Data Log Event Log IV AutoScroll 2010 12 09 10 46 03 Connectin
29. data This information is not included in the WARP package Since the latency from ground station to the RUC may vary a timestamp specifying the arrival time of the telemetry data cannot be done on the RUC The ground station must thus send a timestamp along with each package containing telemetry data specifying the time the data was received from the CanSat The timestamp is only used to calculate the relative time between packages and has been chosen to be the time in milliseconds since any arbitrary reference time likely the time the ground station was started Antenna position information from ground station to RUC and specifi cation of azimuth and elevation when using manual antenna control If the user is trying to control the antenna position over a high latency network the latency will be very noticeable since there will be a time delay from specifying a wanted antenna position until the antenna starts moving towards the specified po sition Furthermore there will be a delay until the new antenna position is shown in the RUC This will give the user a feeling of unresponsiveness but this issue cannot be avoided As with the telemetry data it is desirable to know at which relative times the antenna position data was captured and a timestamp must be sent along in this case as well Configuration setting commands from RUC to ground station This includes specifying CanSat ID setting ground station GPS location asking ground s
30. decrease the voltage output of the controller Design The design of the controller follows the description outlined in section 9 2 on page 66 A transfer function for the elevation plant can be seen in equation 8 50 on page 63 and a block diagram of the control loop can be seen in figure 9 7 on the next page Time Domain Design Tf the controller D s is chosen like the azimuth controller to be a proportional controller and the feedback H s is 1 then the closed loop expression is given by K 13 99 9 20 s 14 96 s 13 99 Kp T s 71 Chapter 9 Feedback Control of Pan amp Tilt Platform 0 8565 0 06118 s 0 9153 S Figure 9 7 This figure illustrates the block diagram of the elevation control loop As in the case of the azimuth system T s is a second order expression of the general form Therefore the same design rules are applied From equation 9 20 on the preceding page wn and can be defined Wn y 13 99 Kp rad s 9 21 E 14 96 Jo 9 22 13 99 Kp The expressions for wn and can be put into the expressions for Mp and t and solved since the maximum value of Mp and the minimum value of t are known tr lt 0 1 gt lt 0 1 gt K gt 23 2 9 23 1 8 JBI K 14 96 o Se Sis 9 24 2 1 14 96 2 13 99 K The equations above clarifies that the requirements for the elevation controller can t be met with a proportional controller In order to compensa
31. define CMD_MANUAL_CONTROL 4 define CMD_USE_P_CTRL 5 define CMD_USE_PI_CTRL 6 define CMD_USE_LEAD_CTRL a define CMD_ENABLE_LINEAR_CORRECTION 8 define CMD_DISABLE_LINEAR_CORRECTION 9 struct pkgGSCmd uint8_t command Command to ground station as specified in the above defines x struct pkgCanSatCmd uint8_t command Command number to send to the CanSat 136 Appendix D uIP Example Mainloop with ARP Appendix D uIP Example Mainloop with ARP The following C source code is example code for using uIP with ARP The code is from the uIP documentation 20 All the functions and variables prefixed with uIP are already implemented by uIP The rest of the functions must be defined by the user of the library In the example code the function calls to the generic network device has been replaced by equivalent functions of the device driver for the ENC28J60 Ethernet controller include uip h include uip_arp h include chips enc28360 h include network device h x include httpd h include timer h define BUF struct uip_eth_hdr amp uip_buf 0 int main void int i uip_ipaddr_t ipaddr struct timer periodic_timer arp_timer timer_set amp periodic_timer CLOCK_SECOND 2 timer_set amp arp_timer CLOCK_SECOND x 10 encInit network_device_init uip_init uip_ipaddr ipaddr 192 168 0 2 uip_sethostaddr ipaddr httpd_init while 1
32. implemented in the software can be seen in figure 9 18 on page 83 In order for the interrupt routine to work as described the value of B must be read before the dotted line in figure 9 12 on the next page If this is not the case the software will not be able to know when to decrement the encoder value 9 3 2 PWM Signal It has been chosen to control the speed of the motors with a PWM signal but there are some pros and cons when choosing which PWM frequency the system should use 33 e Choosing a too high frequency may interfere with the radio link This is caused by the increased number of rising falling edges on the PWM signal 76 Section 9 3 Implementation AFL LI Lo BHP LI LUI Le Figure 9 12 The figure illustrates the relationship between signal A and B on the encoders e Each switching between on and off of the PWM signal will result in little power loss in the MOSFET s inside the motor driver Therefore the more time spent switching the more power is wasted e The higher the switching frequency the more stable is the current waveform in the motors At high frequencies the inductance of the motor will smooth out the current wave to an average DC current One way to choose a PWM frequency is to look at the motor parameters By choosing a maximum deviation in current from the average current the expression in equation 9 35 can be derived The expression is derived from the worst case where the on and off per
33. locatio gt a he Ground Station Manage packages 7 Send CanSat cmds Adjust controller Get Saved Data Set GS location Use Automatic tracking Use Manual Antenna ctrl Show event log Show data log Figure 10 1 Use case diagram for the RUC The punctured arrows are dependencies The normal arrows shows the flow of events in the RUC The RUC will have a graphical interface As a result the GUI needs to support a number of user inputs as shown on figure 10 1 Additional information about the design of the GUI can be found in section 10 2 on the next page Since the Java language is object oriented in nature the program will be divided into classes To initiate the GUI upon program launch a class called GroundstationApp is created For establishing disconnecting the Ethernet connection receive and send data through the Ethernet connection and to handle the RUC protocol as described in appendix C on page 135 a class named GroundstationConnect ion is created To ex tract data from type O packages interpret these according to the user specified data types and write the CSV files a class named GroundstationData is created For drawing the GUI respond to user inputs and update the GUI a class called GroundstationView is created A class diagram of this can be seen in figure 10 3 on page 94 In order for the GroundstationData class to interpret the received data an inter face named Type is used Th
34. motors also have an internal gear the following terms must be defined to avoid confusion Rotor refers to the internal part of the motor that is forced to rotate by the magnetic field and its angular velocity is denoted by wm ol Chapter 8 Modelling of Pan amp Tilt Platform Elevation Azimuth Figure 8 1 A sketch of the antenna platform showing the rotation in the azimuth and elevation directions Shaft is the part that sticks out of the motor Its velocity is denoted by ws The shaft is connected to the rotor through the internal gear The external gears connect the load to the shaft The velocity at the load is denoted by wz Since azimuth and elevation rotate independently they can also be modeled as so The two models are very similar though and the differences lie solely in the parameters 8 1 1 Assumptions The following assumptions are made about the system being modelled All moving parts including the belts are rigid e The DC motors behave linearly except for dry friction The effect of wind resistance is negligible The platform is in level at all times e The effects of using a PWM signal instead of a constant voltage are negligible 8 1 2 DC motors Figure 8 2 on the facing page shows an equivalent electrical diagram of a generic DC motor and figure 8 3 on the next page shows the moments of force that apply to the rotor From the electrical diagram the following equation can be written AA
35. on page 19 The purpose of this test is to investigate if the designed system meets the requirement specification written in section 3 2 on page 17 At the end of the chapter the results of the tests will be summarized These results can be seen in table 12 1 on page 119 12 1 Tests The tests performed on the designed system in this section originates from the acceptance test specification found in section 3 3 on page 19 The procedure for each test can be seen in the respective test journals 12 1 1 Test 1 Covers Requirement 1 and 2 e Must implement and adhere to the WARP protocol e Must implement and adhere to TCP IP and Ethernet protocols This test is performed in test journal 6 on page 166 In this journal it is observed that the ground station and RUC had received the same number of packages with matching CanSat ID s after approximately 12 minutes It is seen that the data in the CSV file are stored correctly The number of CanSat packages sent to the ground station from the CanSat in this test exceeds the number of received packages on the RUC as all the CanSat packages with a different CanSat ID are filtered out From these results it can be seen that all packages were processed and relayed over the Ethernet connection correctly It can be concluded that the system has passed test 1 and therefore requirement 1 and 2 are satisfied 12 1 2 Test 2 Covers Requirement 3 e No more than 200 ms may pass from a package is
36. receive telemetry data from the CanSat Under normal operation the received CanSat data will be transferred to the remote user client and saved as a file upon arrival there The network link may break however and other unforeseen events e g a computer crash could lead to loss of incoming data Therefore it is desired to save telemetry data to persistent memory on the ground station as well This is referred to as the telemetry data backup In case of link breakage or crash the data on the ground station would be available for later retrieval It is worth considering keeping a similar backup aboard the CanSat which could then be read after retrieving the CanSat after a flight if the radio link is unreliable or completely lost during the flight The construction of the CanSat is not part of this project though Due to time constrains the telemetry data backup has not been implemented in the system e Event Log It is desirable for the user to be able to analyze what happened during flight Therefore the remote user client maintains a log of recorded system and user ac tivity This includes user interaction with the GUI and information about received packets This is called the event log Implementation of this is described in the chapter descibing the RUC chapter 10 on page 91 Section 2 3 WARP AAU Radio Protocol 2 3 WARP AAU Radio Protocol In order to make it possible to use the ground station constructed in this project with the Can
37. received on the ground station s wireless link until the processed package containing this information is sent to the RUC if this is connected through a direct Ethernet cable 117 Chapter 12 Acceptance Test This test is performed in test journal 7 on page 167 In test 1 the system is experienc ing a light system load and in test 2 a heavy system load causing a package processing time of 7ms and 54 ms respectively As a stress test can be difficult to simulate the worst case processing time might be higher than the indicated 54ms However this re sult is significantly lower than the 200 ms specified by the requirement which leaves a fairly large margin for errors in the result Therefore this test is considered to be passed and thus requirement 3 is satisfied by the system 12 1 3 Test 3 Covers Requirement 4 and 5 e The RUC must save all received data as a comma separated values file CSV e If the RUC crashes any data that already has been received must not be lost The RUC is tested against an Ethernet server adhering the RUC protocol as done in test journal 2 on page 153 The test was conducted according to the acceptance test specifications and will thus not be repeated Instead the results from the part test in section 10 5 on page 103 is re used These results show that the designed system satisfies requirement 4 and 5 12 1 4 Test 4 Covers Requirement 6 e The ground station must keep a backup of the lat
38. that interrupts may be missed if too much time is spend inside critical regions Therefore more sophisticated inter task communication techniques are needed In ARTOS there are two primitives for inter task communication which have already been mentioned Semaphores and queues Semaphores provides a more elegant solution to mutual exclusion than the disabling reenabling of interrupts though the overhead of semaphores is a bit higher A semaphore used for mutual exclusion will be initialized with the value 1 A task will down the semaphore before entering a critical region setting the semaphore to 0 When any other task tries to down the semaphore it will be blocked and be added to the semaphore s blockedToDownList until the running task leaves the critical region by upping the semaphore value Another use of semaphores is synchronization between tasks For example an interrupt service routine could up a semaphore to signal a task that an I O device has become ready Queues have a bit more overhead than semaphores so although they could be used for the same purposes as semaphores they are especially designed for message passing The queues in ARTOS are using the FIFO first in first out scheme All the inter task communication primitives are used in the design of the Ethernet communication module which will be discussed in chapter 6 on page 37 5 3 Fixed Priority Scheduling The operating system topics discussed until now are applicable
39. the ground station will be able to track the CanSat if the latest elevation angle fed as reference position to the controller never deviates more than 10 from the real value At an angular velocity of 0 4rad s a rotation of 10 takes 436 ms If the GPS sample rate is set to 5 Hz the sample period is 200 ms This leaves 236 ms for the GPS data to be transmitted and fed into the controller It is assumed that from the time the CanSat has completed transmitting a package with the GPS data until the ground station has passed it to the controller no more than 36 ms will pass Therefore it is a requirement to the CanSat that no more than 200 ms may pass from the time a GPS sample is taken until the package with the data has been transmitted However it is clear from the above that packet loss in the CanSat to ground station communication during the launch can be fatal for the automatic antenna tracking sys tem Thus a panic action should be considered in case of a lost link For example the current CanSat position could be extrapolated based on previously obtained GPS data 2 3 2 Protocol Design Decisions Before designing the protocol it is worth considering what the protocol s job is which features it should contain and so forth This can be used as the basis of how the protocol should be designed The protocol is to be used on top of a wireless radio data link This link is a byte stream i e a channel where bytes are put into one end and
40. the orientation where the antennas are polarization matched These issues with reception on the ground station can not be explained at this time It has been tried to use a wire whip antenna similar to the one used on the CanSat but the reception quality is approximately the same Another group group 502 5 semester EE at AAU autumn 2010 who uses the same radio transceivers also with wire whip antennas doesn t have these issues with reception It has been shown that the uplink connection is working fairly well so it should be possible to achieve a similar link quality for downlink transmission Summary In this chapter the RF communication has been designed The theoretical link range is high enough to satisfy the requirement of 1500m There are however situations where the link range is not sufficient due to polarization mismatch and other assumptions in the calculation In practice for downlink it has not been possible to get close to the theoretical link range but this is assumed to be caused by some error in the setup For uplink the measured range is also not as long as required and it can thus be concluded that the RF communication link has to improved before it is used for an actual CanSat launch 49 CHAPTER Modelling of Pan z Tilt Platform This chapter describes the process of setting up a model that accurately describes the behavior of the physical components of the system The goal is to derive a transfer
41. the processed package containing this informa tion is sent to the RUC if this is connected through a direct Ethernet cable First an overview of the used hardware and software is introduced This is followed by a discussion of the implementation of the TCP IP stack software In the end of the chapter the maximum data throughput of the network link is tested 6 1 Overview An additional requirement to the module is the minimum TCP data byte stream through put which is estimated from the following worst case scenario e The longest RUC package that can occur is of the type pkgSatData which contains telemetry data from the CanSat The maximum package size is 158 bytes In this scenario this package is sent at a rate of 10 Hz and is byte stuffed to 310 bytes e The controller info RUC package pkgControlInfo is sent at a rate of 125 Hz contains 16 bytes but is byte stuffed to 32 The total required throughput is thus 7100 2 The TCP IP protocol stack is shown in figure 6 1 on the following page with the layer names used in RFC1122 19 from the Internet Engineering Task Force IETF The application layer protocol is the RUC protocol specified in appendix C on page 135 The hardware used by this module is the LPC2138 microcontroller communicating with the Ethernet controller Microchip ENC28J60 through the SPI Serial Peripheral Interface bus The Ethernet controller provides the physical layer and some parts of the link layer The
42. these functions are located in os h in the ground station source code found on the CDO See appendix E on page 139 for more details of the prototypes and their arguments The implementation of the OS is found in os c and some low level routines are written in assembly and can be found in os S Reference documentation for the ground station software is generated with the Doxygen documentation tool and can be found on the CD In order to describe how system calls are processed we need to look into the different execution or processor modes of the hardware platform The ARM architecture supports seven different processor modes as shown in table 5 2 on the next page All modes except user and system mode are exception modes which means they are entered on 1 groundstation 2 groundstation doc 31 Chapter 5 Real Time Operating System Number Syscall name May block osTaskCreate osTaskTerminate osWaitForDivisibleTick Yes osEnterCritical osLeaveCritical osSemInit osSemDown Yes osSemUp osSemUpFromisr osQueuelnit osQueueRead Yes osQueueWrite Yes osQueueReadFromisr osQueueWriteFromIsr gt 0 0NR O a oi oo Nt Table 5 1 Syscalls provided by ARTOS A system call is issued by loading the number into R12 and generate a software interrupt Some system calls does not require a transition to supervisor mode and have therefore no syscall number Processor mode Description
43. time between interrupts i d 360 degree 138 33 roun round 60 A 11 1 sec 3 de p interrupt This is thus the interarrival time for the interrupts As can be seen in figure 9 12 on page 77 the deadline for the interrupts are of the time between the interrupts Thus the deadline are 15 ps rfmIrqHandler The task must handle the reception and transmission of bytes on the RF connection to the CanSat This connection is run at a rate of 19200 bit sec The time between each byte is thus x 1 19200 Bit Tmin 417 us 11 2 byte This is both the interarrival time and the deadline for the rfmIrqHandler 110 Section 11 2 Scheduling encIrqHandler This ISR performs one job an osSemUpFromIsr on a semaphore which the encIrqHandlerTask has osSemDown ed It thus has the same interarrival time as the encIrqHandlerTask The deadline has been set to 1 ms controllerTask The controller task is run every 8 ms see section 9 3 5 on page 82 which means that this is the interarrival time for this task A strict deadline of 2 ms has been set to ensure that the time between controller updates is as constant as possible rfmPkgHandlerTask To determine the interarrival time for this task the rate at which packages are received on the wireless link must be known It is assumed that one CanSat is connected and it is sending packages at a rate of 10 Hz This gives an interarrival time of 100ms There are two requirem
44. to control the antenna so that an object following the launch graph on figure 2 3 on page 11 can be tracked The target must be within the half power beamwidth of the antenna at all times 118 Section 12 1 Tests The test performed in section 9 4 2 on page 89 was done according to the acceptance test specification for test 6 As so this test isn t repeated In section 9 4 2 it was found that the controllers for the antenna are capable of adjusting the antenna so that a CanSat can be tracked during launch Since this was done without the CanSat ever leaving the half power beamwidth of the antenna acceptance test 6 is passed and thus requirement 8 is satisfied by the system Summary In this chapter it was found that the system satisfies requirement 1 2 3 4 5 and 8 but not requirement 6 and 7 specified in the requirements specification in section 3 2 on page 17 This was done by performing the tests specified in the acceptance test specification in section 3 3 on page 19 An overview of the results can be seen in table 12 1 System Requirement Acceptance test Passed 1 1 Y 2 1 Y 3 2 Y 4 3 Y 5 3 Y 6 4 x 7 5 x 8 6 Y Table 12 1 This table shows the system requirements the test performed to investigate if the require ments are passed or not and finally the results of these tests 119 CHAPTER Conclusion The starting point for this project has been the development of
45. user Normal scenario 1 User Queries the system for the current antenna position 2 System Receives the query and shows the current position Exceptions e Current position cannot be determined No antenna direction is shown 3 Show Sensor Data Goal description Data from the user specified sensors on board the CanSat is shown to the user Normal scenario 1 User Queries the system for CanSat sensor data 2 System Receives the query and shows sensor data 4 Enable Manual Antenna Direction Control Goal description The user can adjust the system s antenna Normal scenario 1 User Changes the antenna position configura tion 2 System Receives new configuration and adjusts the antenna Exceptions e The user specifies an invalid configuration The system ignores the new configuration and warns the user 5 Enable Automatic Antenna Direction Control Goal description The system will take control of adjusting the antenna direction 15 Chapter 3 Requirements Specification Normal scenario Exceptions 1 User Queries the system to enable automatic an tenna direction control 2 System Receives the query and takes control of the antenna e The system is set to conformance class 1 or no ground station location is set The system ignores the user request 6 Specify CanSat ID Goal description Normal scenario Exceptions The system will st
46. using eq 8 24 Voffset 0 0104 5 2 86 V 8 42 It can be seen that the curves coincide very well By inspecting the plots closely though it s apparent that the simulation curve settles faster than the measured curve This indi cates that the inertia parameter has been set too low By gradually adjusting the value and observing the result a new value of 0 0555 kg m has been determined Figure 8 8 plots the transfer function with the new inertia value Figure 8 9 on the facing page plots the measured and simulated values at various voltages It can be seen that the curves coincide nicely at higher voltages but diverge at lower ones The exact cause of this discrepancy is uncertain but it s likely to be friction phenomena not addressed by the model used Since friction beyond what can be described as coulomb and viscous is very difficult to address effectively no further attempt has been made at this The model describing the azimuth rotation is considered good enough to be used in designing a robust controller 8 5 3 Elevation Parameters Because of the non linear torque component that s caused by the shifting center of mass determining the friction parameters for the elevation is more complicated than for az imuth For instance it is not possible to maintain a constant angular velocity at a constant voltage and the method used for determining the parameters for azimuth is therefore not directly applicable A way to work
47. with these commands An acknowledgement system is used to ensure that each type 1 package is successfully received even if lost in transit Also it is guaranteed that the command in the package is only executed once It is noted that ground stations should take measures to ensure that type 1 packages will only be sent to CanSats that support type 1 packages Otherwise the ground station will never receive an acknowledgement and will thus continue to retransmit the packages forever Figure B 3 shows the layout of a type 1 package PKGtype CTS TO Package ACK foxBe i d ome crce 8b lb 3b 4b 16b 8b 8b 3b Figure B 3 Layout of a type 1 package The CMD field contains a number from 0 255 identifying the command to be executed For packages sent from the ground station to the CanSat the Package ACK field contains a package number that is incremented by one for each new command sent This 133 Appendix B WARP Protocol Specification package number is independent of the package numbers in type O packages When the CanSat successfully receives a type 1 package it should transmit a type 1 package back to the ground station where the Package ACK field contains the package number of the package just received successfully In these packages the CMD field is optional it s contents is to be ignored The ground station must only send one type 1 package at a time the next command cannot be sent until the current one has be
48. 1 Ethernet connection established Send button and text field enabled Status Awaiting Acknowledge CanSat Commands 1 Send Figure 10 12 Ethernet connection established but awaiting acknowledge Send button and text field grayed out Since the commands are limited to values between 0 and 255 input validation is performed when the user clicks the send button If the CanSat command is invalid the package will be dropped and the user will be redirected to the event log The send button status label and text field are placed in the communication out panel 10 2 5 Antenna Control In order to control the antenna when tracking is set to manual the GUI interface seen on figure 10 13 is implemented in the RUC Antenna Control Status Manual Adjustment Manua Current Azimuth 1 Wanted Azimuth 241 Automatic Current Elevation 1 Wanted Elevation 241 Calibrate Manual Azimuth deg 10 0 Arrow Key Control Manual Elevation deg 10 0 Apply Figure 10 13 The Antenna Control panel found in the RUC GUI For incoming information about the antenna package type 1 in the RUC protocol is received For outgoing package type 128 is used Note that the status label as well as the Manual Calibrate and Automatic buttons seen in figure 10 13 are described in section 10 2 6 on the next page The Current Azimuth and Current Elevation labels seen in figure 10 13 informs the user about the current position of the antenna on th
49. 2 3 196 4 and the velocity is maintained during the rest of the launch phase Umax is the highest expected rocket velocity In comparison the maximum velocity for the rocket used in the ESA 2010 CanSat competition was 544 6 The value of a comes from the maximum acceleration a CanSat should be able to withstand 5 Chapter 2 Preliminary Analysis e The inaccuracy of the GPS data can be neglected because it is small compared to the horizontal distance r to the rocket Figure 2 2 Illustration of CanSat tracking during launch From these assumptions the movement of the rocket can be divided into the two phases constant acceleration and constant velocity The angle between the ground plane and a straight line from the ground station to the rocket is the desired elevation angle 0 arctan The altitude of the rocket h during the acceleration phase can be written as h gt a t where t is the time from the beginning of the launch The angular velocity of the elevation angle is the derivative of 0 with respect to time The angular velocity during the acceleration phase w is given by d9 darctan 22 wi t E 5 2 1 art 2 2 r2 La t 2 2 A similar expression is found for the constant velocity phase darctan 21t max t w t Ti 2 3 Umax A 2 4 where w1 is the angular velocity of the elevation during the constant acceleration s phase w2 is the angular velocity o
50. 388 kg Table 3 2 Values measured on the antenna platform By using the formulas from section 3 5 on the preceding page the gear ratios and moments of inertia have been calculated The values are shown in table 3 3 Property Value Unit Tower inertia 0 52 1073 kg m Foot inertia 6 7 107 kg m Antenna inertia 11 3 107 kg m Azimuth gear ratio 8 6 1 Elevation gear ratio 4 6 1 Table 3 3 Parameters calculated from the measured values 3 6 Test 2 Sampling System Performance Azimuth The goal of this test is to determine the parameters for dry and viscous friction for rotation on the azimuth axis Testing Procedure 1 In the ground station software the PWM duty cycle is set to 100 And a rotation limit of 180 where the power will be cut off is specified The software is then loaded onto the ARM board 157 Journal 3 Model Parameter Determination 2 With power output disabled the voltage supply is set to supply the motors with 3 5 V 3 On the PC the RUC is connected to the ground station A unique filename is chosen for the collected data 4 The antenna is manually adjusted to level The angle sensors are then reset using the Calibrate button on the RUC 5 Power output is enabled and the rotation starts 6 When the rotation stops due to the 180 limit the RUC is disconnected and the power output is disabled 7 The procedure is repeated from step 2 for voltage with voltage values of 4 5 6
51. 40urnals rf_comm downlink arduino 22 groundstation 23 journals rf_comm downlink test dif 152 Journal 2 Test of RUC CSV File Saving Journal 2 Test of RUC CSV File Saving 2 1 Purpose The purpose of this test journal is to test requirement 4 and 5 specified in section 3 2 on page 17 for the RUC This test is performed with respect to the acceptance test specification in test 3 on page 19 The RUC is explained in further detail in chapter 10 on page 91 The ability to save the ControlInfo CSV file is tested as well 2 2 Test Object The test object is the RUC Used Equipment Instrument AAU No Make and type OS Microsoft Windows XP IDE Eclipse SDK Version 3 4 2 IDE NetBeans IDE 6 9 1 Table 2 1 Equipment used to test the RUC The code for the server used in test 1 can be found on the CD 092 for both SatData and RegData 2 3 Approach The RUC will be connected to a server running inside the Eclipse IDE adhering to the RUC protocol This server will be sending packages to the RUC Depending on which packages are sent either the data CSV file or the ControlInfo CSV file is being written to To test if the data is saved correctly the saved data is compared with the received data Afterwards the RUC will be terminated by the OS and the CSV files will be checked for data loss 2 4 Test 1 The RUC is connected to a server that is sending 10 000 SatData packages where the timestamp field is incremented by on
52. 6 Final Expression By inserting all the values the final transfer functions are as follows 1 657 fh 8 49 5 0577552 3 5068 oe 0 8565 Ha s 8 50 00611852 0 91535 When the voltages to compensate for dry friction were applied to the motors it was found that the motors started to move This is caused by too high offset voltages To alleviate this effect new values for the dry friction offset voltages have been determined by gradually reducing these until the motors did not start to move The values deter mined this way are the ones used when designing the controller The offset values are as follows with the ones previously determined in parenthesis Vofiset_az 2 4 V 2 86 V 8 51 Voftset_el 2 2 V 2 39 V 8 52 To compensate for gravity on the elevation axis the following voltage offset is calculated dynamically and is subtracted from all elevation motor input to counter the effect of gravity Vetev g sin 0 0 812 8 53 Summary In this chapter a complete model of the system has been built This model combines the mathematical description of a DC motor with the dynamic motion of the moving parts ie the tower and the antenna The result is transfer functions for both azimuth and elevation that produce the angular position from an input voltage All necessary parameters have been determined either by data sheets or through testing In the process of determining parameters the model has
53. 8 and 10 V Results CSV files containing the collected data can be found on the CD The data set consists of the angular position in degrees multiplied by a factor 10 and a timestamp measured in milliseconds The dataset has been trimmed by removing all data points up until the point where voltage is applied 3 7 Test 3 Sampling System Performance Elevation The goal of this test is to determine the parameters for dry and viscous friction for rotation on the elevation axis Testing Procedure 1 In the ground station software the PWM duty cycle is set to match an output voltage of 4 V Non linearity correction is enabled and a rotation limit of 90 where the power will be cut off is specified The software is then loaded onto the ARM board 2 With power output disabled the voltage supply is set to supply the motors with 12 V 3 On the PC the RUC is connected to the ground station A unique filename is chosen for the collected data 4 The antenna is manually adjusted to level The angle sensors are then reset using the Calibrate button on the RUC 5 Power output is enabled and the rotation starts 6 When the rotation stops due to the 90 limit the RUC is disconnected and the power output is disabled 7 The procedure is repeated with a voltage value of 6 and 8 V 8 The non linearity correction is disabled in the software 9 The same procedure is repeated again 25 journals parameter_determina
54. 8 bootloader high_fuses 0xDA aau_pro328 bootloader extended_fuses 0x05 aau_pro328 bootloader path atmega aau_pro328 bootloader file ATmegaBOOT_168_atmega328_pro_8MHz hex aau_pro328 bootloader unlock_bits 0x3F aau_pro328 bootloader lock_bits 0x0F aau_pro328 build mcu atmega328p aau_pro328 build f_cpu 8000000L aau_pro328 build core media cd cansat_standin core The last line has to be the relative path from the folder with the boards txt file to the core folder provided Now open the pde files provided as test code in arduino and it will use the Arduino Pro or Pro Mini 3 3V 8 MHz w ATmega328 and AAUduino board core just added 15 cansat_standin core 145 Appendix G Schematic Part list and Physical Construction Appendix G Schematic Part list and Physical Construction The following is a complete list of all the hardware that makes up the developed ground station e The Mini Max ARM E development board from BiPOM Electronics 8 which con sists of the following items LPC2138 9 Microcontroller ARM7TDMI 7 CPU core ENC28J60 21 Ethernet Controller e RFM12B 11 Wireless module e Motor driver L298 IC 35 Dual full bridge driver Amax 26 29 Motor ENC MR 128imp 225771 32 Encoder The physical contruction can be seen on figure G 1 and on the cd 16 A schematic of the designed system can be seen on figure G 2 on the next page This can also be found on the cd 9
55. 9 Te 8 39 By solving the two equations the values of Te and B are found B 15 4 107 8 40 Te 0 0104 8 41 59 Chapter 8 Modelling of Pan amp Tilt Platform 4 4 EB ew oe 23 me no g g 6 21 52 5 E O o a 1 L Q 1 i 6V Measured 6V Measured 6V Simulated 6V Simulated 0 0 i 0 2000 4000 6000 8000 0 2000 4000 6000 8000 time ms time ms Figure 8 7 A plot showing the sampled position Figure 8 8 Same as before but with an adjusted data at 6 V as well as simulated values A voltage moment of inertia offset of 2 86 V has been used 8 5 2 Graphical Adjustments of Azimuth Parameters The initial calculation of the moment of inertia has been based on simple measurements and assumptions and thus the value found cannot be considered entirely accurate The value can be refined by observing how the system performs in tests and comparing this to the output of the model By using Simulink to simulate the output of the transfer function using the same input as in the actual tests the two results can be compared directly The simulation files can be found on the cd 3 Figure 8 7 shows a plot of the sampled system performance with a constant input of 6 V along with a simulation using the model expression The dry friction has been simulated by adding a voltage offset to the model input This has been calculated
56. ARP AAU Radio Protocol WARP is the protocol used for radio communications between ground stations and CanSats Remote User Client see list of terms Ground Station see list of terms ARM Real Time Operating System the operating system developed as part of this project Also known as grammar school or senior high school The danish name for this school is gymnasium The embedded system performing the antenna con trol CanSat radio communication and network com munication to the remote user client The PC executing the java based GUI program which are interfacing with the ground station Sensor data transmitted from the CanSat to the ground station A log on the remote user client containing a full list of all activities performed A data storage on the ground station capable of stor ing 5 minutes of CanSat telemetry data Used together with azimuth to specify the direction the antenna is pointing Specifies the angle between a horizontal plane and the antenna Used together with elevation to specify the direction the antenna is pointing Specifies the angle between north and the direction the antenna is pointing in the horizontal plane Appendix B WARP Protocol Specification Appendix B WARP Protocol Specification WARP short for WARP AAU Radio Protocol is a package oriented data transmission protocol It is designed for transmitting packages over a highly unreliable wireless link that is work
57. C protocol described in appendix C on page 135 Consequently the RUC must adhere to this protocol The code designed in this chapter is located here O The following demands from the requirement specification described in section 3 2 on page 17 are crucial for the RUC to ensure the wanted product behavior e Requirement 2 Must implement and adhere to TCP IP and Ethernet protocols e Requirement 4 The RUC must save all received data as a comma separated values file CSV e Requirement 5 If the RUC crashes any data that already has been received must not be lost Note that the requirements are numbered according to the requirement specification These requirements are tested for this module at the end of this chapter 10 1 Overview and design In this section the basic structure of the RUC will be explained In order to gain a better understanding of the RUC a use case diagram of its functionalities is made This use case diagram is based on such features as the ability to send receive packages establish an Ethernet connection save information in CSV files interpret received telemetry data display information and interact with the user through a GUI The use case diagram of the RUC can be seen in figure 10 1 on the next page l rue 91 Chapter 10 Remote User Client Disconnect Connection lost Set CanSat ID N bn Set Conformance class Ys y X w TS Handle Ethernet connectioi Q Set Data storage
58. C894 Apr 1984 TCP Congestion Control Internet Engineering Task Force Std RFC5681 Sep 2009 Danish National IT and Telecom Agency 2010 Specific rules and guide lines regarding chosen frequency Downloaded 22 09 2010 Online Avail able http www itst dk frekvenser og udstyr udstyr og apparater diverse filer radiogrenseflader 032 20INTERFACE SRD pdf Low Power Radio Solutions 6 element yagi antenna 868 914 mhz Low Power Radio Solutions 868 914 mhz yagi antenna data sheet 1 C A Balanis Antenna Theory analysis and design 3rd ed John Wiley amp Sons Inc 2005 Maxon A mazx 26 026mm Graphite Brushes 6 Watt May 2010 1 Maxon Planetary Gearhead GP 26 B May 2010 0 G F Franklin J D Powell and A Emami Naeini Feedback Control of Dynamic Systems 6th ed PEARSON 2010 Maxon Maxon sensor encoder mr 5 2010 13 Online Available http shop maxonmotor com ishop download article 225771 xml P Hills Speed controllers Downloaded 03 12 2010 Online Available http homepages which net paul hills SpeedControl SpeedControllers html 8 datasheets enc28460 pdf 9 datasheets antenna_propa pdf 10 datasheets antenna_mek pdf 11 datasheets a max 26 110949 motor pdf 12 datasheets motor_Gear pdf 13 datasheets ENC MR 128imp 225771_10_EN_262 pdf 126 References 34 About com Geography downloaded 03 12 2010 Online Available h
59. CanSat Ground Station ELECTRONICS amp IT P5 STUDENT PROJECT AUTUMN SEMESTER 2010 GROUP 10GR503 DEPARTMENT OF ELECTRONIC SYSTEMS AALBORG UNIVERSITY Title CanSat Ground Station Subject Distributed embedded systems in cooperation with physical systems Project period P5 autumn semester 2010 Project group 10gr503 Participants Kent Basselbjerg Thomas L Hansen Peter B Jorgensen Niels G Myrtue Rasmus Pedersen Bo Povey Supervisor Jens Dalsgaard Nielsen Number of copies 8 Number of pages 176 last page is p 168 Attachments 1 cd Appendices 7 Ended the 20 12 2010 Department of Electronic Systems Electronics amp IT Fredrik Bajers Vej 7 B 9220 Aalborg Phone 9940 8600 http es aau dk Abstract Background CanSat competetitions are held anually by several space organizations This project regards the development of a ground station that can support students participat ing in these competitions The ground station must be able to track the CanSats and communicate with them wirelessly Other projects have had the goal of designing and constructing such CanSats The WARP radio pro tocol has been developed in coorperation between these projects it allows the constructed ground station and CanSats to work togther Results The system consists of a ground station and a remote user client The ground station can communicate wire lessl
60. CanSat and thus does not receive new GPS coordiantes anymore The design and implementation of the antenna control is described in chapter 9 on page 65 e Radio Communication The radio link from the CanSat to the ground station must be working on some license free frequency band because it is undesirable to require the schools using the CanSat kit to acquire a license for the radio link Pre built radio transceivers are used for the transmission Since the project group would like to work with data protocols it has been chosen that these radio transceivers should provide Chapter 2 Preliminary Analysis nothing but a possibly unreliable byte or bit stream transmission The design construction and implementation of the radio communication system is described in chapter 7 on page 45 e Network Based Connection As illustrated on figure 2 1 on page 6 a network is used to connect the remote user client to the ground station It has been chosen to use the TCP IP network protocol suite on top of an Ethernet network This way the network can be an Ethernet cable an existing LAN network or the internet This gives the user great flexibility in choosing how to connect the ground station and the remote user client The actual implementation of these protocols is described in chapter 6 on page 37 e Remote User Client The users that are going to utilize the CanSat kit and thus also the ground sta tion and remote user client developed in this proje
61. E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 9994 8888 E 211 33 2222N 0 44 2222 65 65 65 9995 8888 E 211 33 2222N 0 44 2222 65 65 65 9996 8888 E 211 33 2222N 0 44 2222 65 65 65 9997 8888E 211 33 2222N 0 44 2222 65 65 65 9998 8888 E 211 33 2222N 0 44 2222 65 65 65 9999 8888E 21 33 2222N 0 44 2222 65 65 65 Figure 2 2 The contents of the CS Vfile from test 1 after 10 000 packages mmmmmmmmmmmmmm m 2c000o0o0o0o0ooooooo SRA RARRARRARAAARAA RARRARRRRAR RARRRARARKRRARAR _ Figure 2 3 The crashed CSV used in test 1 Journal 3 Model Parameter Determination Journal 3 Model Parameter Determination This journal describes how the uncertain parameters for both the azimuth and eleva tion model have been determined through tests The journal includes a list of all the equipment used testing procedures and the results of each test 3 1 Purpose The purpose of these tests is to derive the model parameters that are unknown or un certain namely moments of inertia of the moving parts in the system friction and gear ratios All of these parameters are physical properties of the system and they must therefore be determined experimentally or through direct measurements 3 2 Test Object Figure 3 1 shows the test object and dimensions to be measured
62. Handler into transmit mode by adding a call to rfmSend to the main task The time used by the rfmIrqHandler in transmit mode is also read out on the oscilloscope 4 encIrqHandler The IO toggling is added to the interrupt service routine for the ENC28J60 Ethernet chip The RUC connects to the ground station and the time spent in the ISR is read out on the oscilloscope SY encoderAzimuthIRQ The IO toggling is added to the interrupt service routine for the azimuth rotary encoder The platform is rotated in the azimuth axis by hand and the time spent inside the ISR is read out on the oscilloscope 43 encoderElevationFIQ The IO toggling is added to the interrupt service routine for the elevation rotary encoder The platform is rotated in the elevation axis by hand and the time spent inside the ISR is read out on the oscilloscope 44 34 journals wcet_determination ethsendertask diff 35 journals wcet_determination uipperiodictask diff 36 journals wcet_determination encirghandlertask diff 37 ournals wcet_determination controllerhandler diff 38 journals wcet_determination arduino 39 journals wcet_determination rfmpkghandler diff 40 3ournals wcet_determination rfmirghandler diff 41 journals wcet_determination rfmirghandlertransmit diff 42 40urnals wcet_determination encirghandler diff 43 40urnals wcet_determination encoderAzimuthIRQ diff 447 45 0urnals wcet_determination encoderElevationFIQ diff 164 Journal 5 Measurem
63. K the caller will be blocked until another task writes to the queue and then the data will be written to dataDest If this argument is NOBLOCK the call will return immediately and the caller must determine from the return value if the read was successful Returns O if read was successful and a value has been written to dataDest nonzero if the queue was empty and no read operation has been performed uint32_t osQueueReadFromlsr struct queue queue void dataDest Read one value from a queue in a FIFO manner May be used from an ISR Parameters queue A pointer to the queue to read from dataDest A pointer to the destination where the read out value will be written to Returns 0 if action was performed successfully no rescheduling is required 1 if rescheduling is required i e a task with higher priority than currentTask was unblocked 2 if action could not be performed since queue was empty Definition at line 368 of file os c uint32_t osQueueWrite struct queue queue void dataSource enum allowBlockArg allowBlock Writes one value to a queue in a FIFO manner Parameters queue A pointer to the queue to write to dataSource A pointer to the memory where the value to be written is read from allowBlock If the queue is full and this argument is BLOCK the caller will be blocked until another task reads from the queue and then the data will be written to the queue If this argument is NOBLOCK the call wi
64. PWM5 8 4 INPUT4 OUTA GND ANT CW n 8 eno UN 7408N 1298 gt z V1 4 GND A o S 12 amp Bx Elevation Bx Motor ANTCTW gt 13 ES E T me 3 2 ram g 7408N y g 5 ENCODER3 5 EIN u 6 1 ENC_AZ SH E 8 3 5V ENC_AZ B 12 71 GND GND 10 5 Azimuth GND ENCODER4 6 ENC ELA H H 8 3 5V ENC_ELB Se E 10 5 Elevation GND Discribtion ID Vcc Gnd AND gates IC2A IC3B PIN 14 PIN7 Figure G 2 Schematic of the designed system Note that many labels refer to labels within the ARM Board schematic 8 147 Test amp Measurement Journals 149 Journal 1 Range Test of RF Communication Journal 1 Range Test of RF Communication 1 1 Purpose The purpose of the test is to examine the radio communication used between the ground station and the CanSat The maximum range where a communication link can be es tablished is to be determined Both uplink ground station to CanSat and downlink CanSat to ground station communication is examined 1 2 Test Object The test object is the ARM development board with the RFM12B RF transceiver con nected The Yagi antenna is used A device transmitting respectively receiving the signal to from the ground station is needed during the tests As this device acting as the CanSat an arduino mini pro is used This is connected to another RFM12B transceiver with a quarter wavelength 8 63 cm wire connected as it s antenna The software running on this arduino is based on the
65. S ay EnA a 8 1 RD nH K tn t 8 2 1This assumption is valid because the duty cycle frequency of the signal has been chosen high enough that the current is smoothed out by the motor coil More details on this can be found in section 9 3 2 on page 76 52 Section 8 1 Model Overview e r Un i Y i f C em F ll T Figure 8 2 Electrical equivalent diagram of a DC Figure 8 3 Illustration of the torque that affects motor the motor rotor where V is the applied input voltage at the motor terminals V La is the current running through the motor coil A Ra is the terminal resistance of the motor 9 La is the terminal inductance of the motor H Vomp is the backwards electromotive force V wm is the angular velocity of the rotor rad sec From figure 8 3 we have the following Note that the non linear dry friction Te is ignored at this time Ja tlt Tm TL T 8 3 K 1 t 1 B w t 8 4 where Jm is the inertia of the rotor kg m Tm is the amount of torque delivered by the rotor Nm TL is the amount of torque applied to the rotor by an external load Nm Tf is the amount of torque applied to the rotor by friction Nm K isthe torque constant Defines how current is converted into torque Sa in the motor B is the viscous friction coefficient for the entire system jes All of the aforementioned parameters must be known in order to make a precise
66. Sats being designed by other project groups a common protocol for the transfer of data over the wireless link is to be defined In this section protocol requirements originating from this project are analysed Then the protocol design choices are discussed The protocol specification has been developed in cooperation with the remaining groups working on CanSat kits at AAU in the autumn semester 2010 The final protocol specification can be found in appendix B It precisely outlines the technical aspects of the protocol Anyone should be able to implement the protocol by reading this specification but will not necessarily understand why the protocol is designed the way it is It has been chosen to name this protocol WARP which is a recursive acronym for WARP AAU Radio Protocol 2 3 1 Protocol Requirements Set by This Project Since the ground station needs GPS data from the CanSat in order to track it it must be able point the antenna towards the CanSat at all times including during the launch phase This also enables collection of telemetry data during launch The satellite will be accelerated to it s maximum speed very quickly which requires the antenna control to be very responsive As the position changes rapidly the ground station has to re ceive the position frequently Should the ground station completely loose track of the CanSat during launch further tracking will be impossible as no updated GPS data will be received These
67. TOS Function Prototypes Function Documentation uint32_t osGetTime void Returns the time since system startup in ms calculated from systickCnt and the timer used to increment this Do NOT use in an ISR Definition at line 182 of file os c uint32_t osGetTimeFromlsr void Returns the time since system startup in ms calculated from systickCnt and the timer used to increment this To be used in an ISR Definition at line 190 of file os c void osQueuelnit struct queue queue uint32_t length uint32_t elementSize void buffer Initializes a queue struct Must be called before any operation is performed on the queue Parameters queue A pointer to the queue struct to be initialized length Length of the queue in bytes elementSize Size of each element in the queue buffer Pointer to free memory of at least length bytes to contain the values of the queue Note osQueuelnit does not allocate any memory for the queue Memory for the queue and buffer must be allocated by the user Definition at line 264 of file os c uint32_t osQueueRead struct queue queue void dataDest enum allowBlockArg allowBlock Reads one valu from a queue in a FIFO manner Appendix E ARTOS Function Prototypes Parameters queue A pointer to the queue to read from dataDest A pointer to the destination where the read out value will be written to allowBlock If the queue is empty and this argument is BLOC
68. The RUC to ground station connection requires all the reliability provided by TCP if for example two commands to set the CanSat ID are sent quickly after each other the order they arrive at the ground station determines which one will ultimately be effective If UDP was used basically all the reliability that TCP provides had to be reimplemented in the RUC protocol therefore TCP has been chosen 4 2 3 Effect of Large Latencies It must be considered how the system reacts to large latency times on the network The network connection may go through the Internet which is a very likely source of considerable latencies These may for example be caused by large physical distances between hosts congestion in the network large data loss rates which results in many retransmissions and more This will obviously only be the case when connecting to the ground station remotely The effect of large latencies on the different types of data on the RUC to ground station connection is e Telemetry data from ground station to RUC Latency here will result in the user experiencing that the data shown to him her is not the most current data This is an acceptable effect since the data will 25 Chapter 4 Modularization 26 ultimately arrive and the data most often will be saved for later analysis It is useful for the user to know at which time the telemetry data was received from the CanSat eg to perform calculations of speed based on GPS position
69. These are seen in the eventlog in figure 10 16 on page 100 The default packages are as follows e SetSatID package 129 with ID 13 e GSCmds package 131 Operation 4 Manual Antenna Control e GSCmds package 131 Operation 5 Use P Controller e GSCmds package 131 Operation 9 Disable non linearity correction By sending these initial packages the ground station will know what settings to use The above settings specifies that the CanSat ID should be 13 the antenna should be controlled manually from the GUI and a P Controller should be used to control the antenna with the non linearity correction disabled If the user disconnects the CSV files will be closed properly and the connection will be closed Similarly closing the RUC will perform the same action before exiting the program 10 2 2 User Selected Data In the RUC protocol specification in appendix C on page 135 it can be seen that the CanSat package inside package type 0 contains a custom part called the payload In order for the RUC to interpret this data correctly it is necessary for the user to specify which data should be expected The panel in which this is implemented can be seen on figure 10 5 Package settings Add Remove Type Label Temperature Atmospheric pressure Wind speed Figure 10 5 Package settings panel in the GUI Expected data is set to the following Signed Byte labelled Temperature Unsigned Short labelled Atmospher
70. User Normal program execution mode Supervisor Protected mode for the operating system FIQ Fast Interrupt Request IRQ General purpose interrupt request Abort Implements memory protection Undefined Supports software emulation of hardware coprocesssor System Runs privileged operating system tasks Table 5 2 ARM architecture processor modes 14 exceptions All the exception modes have some banked registers which means that some of the user system mode registers are replaced with registers that are only accessible in the specific exception mode User mode is the only unprivileged mode which means some instructions are not available When the user mode program issues a system call the R12 register is loaded with the corresponding system call number and then a software interrupt is generated This puts the processor into supervisor mode where interrupts are disabled The operating systems performs the system call and may enter system mode to access all the user mode registers Some system calls doesn t require a transition from user to supervisor mode They are implemented as regular functions and therefore have no syscall number Many system calls are implemented in assembly for performance reasons It is important to spend as little time as possible in supervisor mode in order to not miss any interrupt requests Notice that there are no system calls for dynamic allocation of memory It is preferred to statically allocate buffers in the grou
71. a delay consisting of The deadline of rfmPkgHandlerTask plus two times the interarrival time of the ethSenderTask plus the deadline of the ethSenderTask This gives a total delay of 36 2 56 36 184 ms which is sufficient to fulfill the requirement of maximum 200 ms from requirement 3 in the requirements specification 11 2 3 Schedulability Analysis As mentioned previously the scheduling is based on a fixed priority scheduler For the assignment of priorities deadline monotonic assignment is used except for the Ethernet tasks which are given the priorities mentioned above This gives the prioritization of tasks that is shown in table 11 2 on the facing page The utilization of the CPU i e the percentage of time where the CPU is busy can be calculated using this formula N U i l Ci Tmin 11 4 111 Chapter 11 Scheduling of Ground Station Software where N is the number of tasks Ci is the computation time of task 7 s Tmin is the interarrival time of task i s Calculating this for the tasks given in table 11 2 on page 110 gives an utilization of 65 This does not state that all deadline will be met only that there is in upper bound on the amount of work queued for the CPU to do Interrupt Service Routines The tasks marked as FIQ or IRQ denote interrupt service routines These are not regular tasks as they are not prioritized in the same way and have very short computation times The FIQ task have hi
72. aining tasks It can be seen in figure 11 2 that no matter which order the Ethernet tasks are executed in they will all meet their deadline It can thus be concluded that the scheduling is feasible also when taking the mutual exclusion into account Summary A scheduling analysis has been performed on the ground station system software and the conclusion is that the fixed priority scheduling chosen is feasible The ISR of the azimuth rotary encoder may not meet its deadline though due to problems implementing it as an FIQ on the hardware platform The total worst case CPU utilization is 65 113 Chapter 11 Scheduling of Ground Station Software The tasks related to the Ethernet module has been analyzed as hard real time tasks in a worst case high load scenario If the Ethernet module is given more CPU time smaller TCP segments will be sent and the Ethernet module will consume a slightly larger amount of CPU time In order to make the analysis some assumptions about the network connection has been made It is noted however that the network traffic is highly nondeterministic and the network tasks have therefore been given the lowest priorities In that way the rest of the ground station system is independent of the Ethernet module s behaviour 114 Part III Assessment amp Conclusion CHAPTER Acceptance Test In this chapter the system will be tested according to the acceptance test specification found in section 3 3
73. an be considered This can for example be solved by adding a counterweight to the antenna in such a way that the center of gravity is moved to the axis of rotation Other possible features could include e Built in GPS module to determine the ground station position e Built in compass for automatic calibration of the antenna e Communication with more than one CanSat at a time e Programming of the ARM board via the network link 14 2 Usage in CanSat Competitions Since the product has been made with the CanSat competition in mind it would be natural to look further into accommodating this purpose To do so the system should be placed in a casing capable of protecting it from the weather since the ground station is meant to be placed outside Also the user interface of the system should be reviewed to make it more intuitive to users with no or minor technical background Testing with actual CanSats would have to be done under various conditions to ensure protocol compliance Perhaps most importantly the user safety of the system would have to be ensured and verified extensively Additional measures to prevent the system from damaging itself should also be incorporated The idea behind CanSat competitions are for the students to build the CanSat systems on their own For this other groups have designed CanSat kits which try to lower the level of technical skills required to construct these CanSats These kits are open source
74. another area of improvement could be impedance matching and choice of antenna As an airborne CanSat descending by parachute will naturally wobble back and forth so will its antenna This causes the polarization of the EM field to vary and thus decreases the amount of power received by the antenna Using a circularly polarized antenna would remedy this problem somewhat although the antenna gain would generally be lower Another requirement not satisfied is the ability to log and save CanSat data on the ground station itself for later retrieval through the RUC This feature has been left out due to time constraints but could be implemented by saving the received data in the flash memory already present on the Mini Max board In this case the maximum number of write cycles that exists for flash memory should be considered however as logging requires many writes over a long period of time Beyond the requirements many features could improve the system performance For instance it would be desirable for the ground station to be able to handle the loss of radio signal from the CanSat in a better way This could be done by guessing the satellite position by extrapolating from recent coordinates received If unsuccessful a random tracking pattern could be initiated and carried out until new packets were received 123 Chapter 14 Perspectives To enhance the controller a different approach to the problem of non linearity caused by gravity c
75. apter is to clarify the background and requirements for this project First the CanSat competition will be described in order to get an overview of what the ground station system is going to be used for Then a system overview identifies the different components a ground station system consists of and the technical aspects in de signing and realising these units are discussed A discussion of the design of the common radio protocol between ground stations and CanSats follows The final outcome of the chapter is the foundation of the requirements specification 2 1 CanSat Competition The CanSat concept was introduced in the late 1990s by the American professor Robert Twiges 6 Since then several CanSat competitions have been held in the USA Japan and Europe with slightly different rules and requirements The CanSat competition this project evolves around is held by the European Space Agency ESA The competition is aimed at students in the upper secondary school It was first held in 2010 where students from 11 different countries participated In august 2010 the students launched their CanSats from the Andgya Rocket Range an independent branch of the Norwegian Space Center Information about the CanSat competition in 2011 has not yet been published There fore this project is based on information for the 2010 competition 5 Participating teams must consist of 3 10 high school students They must build CanSats that measure air tempera
76. as telemetry data like temperature and pressure 3 1 2 Description of Use Cases The following lists the use cases and describes the goals normalscenarios and in some cases exceptions of the use cases The goal description of each use case explains the 13 Chapter 3 Requirements Specification Connect To Ground Station Specify CanSat ID Se Antenna Direction Se a Sensor a Show Sensor lt lt ne Ce User CanSat Sere i Automatic Antenna Direction Sere i IT Control IT Direction Get Ground Station Telemetry Data Backup Send Command To CanSat Figure 3 1 This figure illustrates the products use case diagram desired result from the action performed The normalscenario describes the dialogue between user and system The exceptions describes how the system should act if an error occurs 1 Connect to Ground Station Goal description The user establishes a connection to the ground station Normal scenario 1 User Sends a connection request to the ground station 2 System Receives the request and establishes a connection 3 System Acknowledges that the connection has been established Exceptions e No connection can be established The user is informed that the connection could not be established and is given the opportunity to try again 2 Show Antenna Direction Info 14 Section 3 1 Use Cases Goal description The current position of the antenna is shown to the
77. ates are triggered by different events as shown in only one single linked list at a time There is a ready list for each priority in the system Linked lists of blocked tasks occur in the semaphore and queue structs as well as the divisibleTickList which consists of tasks waiting for a divisible tick Furthermore the global variable currentTask points to the currently running task Table 5 3 shows the different lists of task descriptors An alternative to the decentralised linked list approach List name Task state Note current Task Running Only one task readyLists OS_NUM_PRIORITIES Ready Number of lists depends on num ber of priorities in OS divisibleTickList Blocked Waiting for divisible tick struct queue blockedTasks Blocked Blocked to read or write struct semaphore blockedToDown Blocked Blocked to down a semaphore with value 0 Table 5 3 In ARTOS the task descriptors always occur in linked lists Each queue and semaphore contains a linked list of blocked task descriptors could be to have a central fixed size process table within the OS This solution makes good sense on hardware platforms with protected memory capabilities so that user mode programs can t change the task descriptors As protected memory is not available on the used hardware platform the decentralised solution wins on its flexibility The operating system creates two tasks on startup The priority 0 task is the idle routine which is run when no othe
78. ation tests As these measurements are uncertain due to the non linearity the values of 7 and B vary quite a bit depending on the V wz data sets used Therefore the values have been calculated by linear regression of the three data sets using the MATLAB script found on the cd 4 This yields the following values B 12 107 8 46 Te 0 0087 8 47 8 5 5 Verification of Elevation Parameters Figure 8 11 on the facing page shows a plot of sampled position data at 4 6 and 8 V along with simulated curves that have been offset by 3 65 V 0 0087 2 39 V 8 48 offset 13 3 10 3 It can be seen that the model curves do not coincide with the measured ones and at low voltages there is a fair amount of deviation Still the model manages to approximate the actual elevation performance to an acceptable degree and it is considered usable for designing the controller Due to the discrepancies between the model and the actual performance it has not been possible to correct the value for moment of inertia The value found by measurements is therefore used Ly journals parameter_determination linear_regression m 62 Section 8 6 Final Expression 25 2h al E LSF 7 lt 2 T 8i 7 0 5F 7 j Measured Simulated 0 1 1 1 L L L L L 0 200 400 600 800 1000 1200 1400 1600 1800 time ms Figure 8 11 A plot comparing measured and simulated results at various input voltages 8
79. be handled The information going from the RUC to the ground station primarily consists of com mands and configuration of what the ground station should do This includes 24 Ask the ground station to calibrate the antenna direction control see section 9 3 5 on page 82 for more details Specify whether to use automatic based on GPS information received from the CanSat or manual control of antenna pointing direction When using manual control specify wanted azimuth and elevation of the antenna Set GPS location of ground station which is used to calculate the direction to point the antenna when using automatic antenna direction control Set ID of the CanSat that should be tracked This corresponds to the SatID in the WARP protocol packets received from the CanSats Section 4 2 Remote User Client Protocol e To illustrate the effect of different types of feedback control it can be specified which type of feedback control should be used See section 9 3 5 on page 82 for more details e Retrieve saved telemetry data from the telemetry data backup Due to time con strains this has not been implemented in the ground station but it is included in the protocol e Ask the ground station to send a command to the CanSat The ground station will also be sending information to the RUC which will primarily consist of data e Telemetry data received from CanSat This must be displayed to the user and it must be possible fo
80. been held up against the actual performance of the system 63 Chapter 8 Modelling of Pan amp Tilt Platform It has been observed that the model describes movement on the azimuth axis with good accuracy The elevation on the other hand is affected by a non linear torque caused by gravity and the linear transfer function therefore doesn t describe the elevation accurately To counter this a non linear voltage offset is added to cancel out the gravitational torque This has improved the accuracy of the model to a point where it is considered feasible for use in designing the elevation control 64 CHAPTER Feedback Control of Pan amp Tilt Platform In this chapter the design and implementation of the controller is described The con trollers function is to make it possible for the system to point the antenna in a wanted position and maintain this position A motor driver has been constructed to make the ARM board able to control the motors with regard to voltage and current levels It is possible to control the antenna in manual mode or in automatic mode In manual mode a user can control the antenna by inputting elevation and azimuth positions of the an tenna In automatic mode the antenna position is adjusted automatically in response to incoming GPS data from a CanSat The controller is designed on the basis of the model described in chapter 8 on page 51 The requirements specification mentions the following which is of relevance f
81. bode plot to be 25 4rad s With known wgw the sample frequency is given as 0 058 rad 3 32 9 33 20 1 2 gt fe gt 81 Hz 9 34 ETE In figure 9 11 the system with and without the designed lead compensation can be seen It is evident that the controller wouldn t be able to meet the requirements without the lead compensation Step Response 1 4 T T T T T T T T With lead Kp 25 Without lead Kp 25 A Without lead Kp 11 44 Amplitude li i 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 Time sec Figure 9 11 This figure illustrates the effect of the lead network Simulated values 9 3 Implementation Both the azimuth and elevation controller are implemented on the ARM board The azimuth controller is only implemented as a proportional controller The elevation con troller is implemented as a proportional controller and as a lead controller For the lead 75 Chapter 9 Feedback Control of Pan amp Tilt Platform controller all values are known so the implementation lies in converting the continuous controller designed to a discrete format that can be implemented on the ARM board The controllers implemented are as follows Azimuth e A proportional controller D s 19 1 Elevation e A proportional controller D s 17 3 e A proportional controller with lead compensation D s a Before implementing the controllers on the ARM boa
82. cheduling will occur and the higher priority task will resume it s execution Parameters sem A pointer to the semaphore to be upped uint32_t osSemUpFromlsr struct semaphore sem 142 Appendix E ARTOS Function Prototypes Increase semaphore value by one This function may be called from an ISR Parameters sem A pointer to the semaphore to be upped Returns non zero if rescheduling is required i e a task with higher priority than the currentTask was unblocked Definition at line 238 of file os c void osTaskCreate struct taskDescriptor td void stackBase unsigned short stackSize unsigned char priority void void func void arg Creates a new tasks and adds it to the readylist with the specified priority The task will run immediately if no higher priority task is currently running Parameters td A pointer to an empty taskDescriptor struct which will contain the reresentation of the task itself stackBase A pointer to the lowest adress of the stack stackSize The size of the stack in bytes priority The priority of the task in the range 1 0S_NUM_PRIORITIES 1 where OS_NUM_PRIORITIES 1 is the highest priority func A pointer to the function that will be run in the task If the task returns the task will be terminated arg A pointer argument that the func will be called with Note The osTaskCreate does not allocate any memory for the stack or the taskDescriptor The required mem
83. circumstances set a requirement to how old the latest received position of the CanSat is allowed to be This requirement is incorporated into the common radio protocol The following calculations gives an estimation of the minimum sample rate and maximum latency of the CanSat GPS data which are required for the ground station to be able to track the CanSat during launch First the maximum angular velocity of the elevation angle is found The timing requirements are then derived from this value Maximum angular velocity of tracking antenna The purpose of the following calculations is to find the maximum angular velocity of the elevation which is required for the ground station antenna to track the CanSat The ground station is placed in a horizontal distance r from the launch site and the altitude of the rocket is denoted h as shown in figure 2 2 on the next page To calculate the maximum angular velocity wmax of the elevation of the ground station antenna the following scenario is assumed e The angular velocity of the elevation reaches it s maximum value during the launch phase until rocket releases its payload e The rocket only moves along the vertical axis This scenario is assumed because the angular velocity required to track lateral movements of the rocket is expected to be much smaller e The distance r 400 m e The maximum velocity of the rocket Umax 600 166 7 is reached with a constant acceleration a 20 g 20 9 8
84. ckage size includes some header fields which can be omitted Requirement 7 The connection between ground station and CanSat must be able to transmit 60 byte packages at a distance of 1 5km with a maximum package loss of 10 This is assuming that the CanSat and ground station are placed in line of sight the CanSat is within the antennas half power beamwidth and the package transmission rate is 5 Hz The 60 byte packages are used to test the wireless connection at an expected normal work load The distance of 1 5km is the estimated distance between the ground station and the CanSat after launch Notice that some package types are acknowledged in the WARP protocol described in appendix B on page 131 As a result the actual package loss will be less than the results of this test Please note that this requirement depends on the CanSat which is constructed by other groups Requirement 8 The ground station must be able to control the antenna so that an object following the launch graph on figure 2 3 on page 11 can be tracked The target must be within the half power beamwidth of the antenna at all times This requirement will ensure that a CanSat can be tracked during launch It is assumed that the CanSat is easily tracked during its descend if it can be tracked during the launch phase The target must always be within the half power beamwidth of the antenna to ensure that the ground station and CanSat antennas can see each other at any gi
85. ct will be students from upper secondary schools It is thus vital that the system can be used by non technical people who haven t worked with electronics before Therefore the remote user client is developed as a GUI application on a PC This GUI must be fairly intuitive and easy to use It has been chosen to use Java as the programming environment for this application since it provides an excellent cross platform environment for developing GUI applications Java also provides great network support and it s easy to create multi threaded applications since this is supported at the language level by Java It should be noted however that since the project group is receiving courses on Java this semester it is the obvious choice The design and development of the remote user client is described in chapter 10 on page 91 e Realtime operating system The ground station must be able to handle the connection to the CanSat handle the connection to the remote user client and perform the antenna pointing direction control This must all be done in parallel and in a timely manner It has been chosen to implement this on an embedded computer system running a real time operating system The design and implementation of this real time operating system is a part of the project because it presents some interesting technical challenges It is further described in chapter 5 on page 31 e Telemetry Data Backup One of the primary tasks of the ground station is to
86. d power significantly e No loss of power in antennas ie 100 antenna efficiency Both the transmitting and receiving antenna has losses which means that some of the power received or to be transmitted will be lost as heat in the antenna All these effects cause the transmission to not always be as good as specified As was seen above a link margin of 20 6dB between required and available transmission power is present thus allowing for some of the mentioned losses to affect the transmission and still achieve a usable link 7 3 Software for RF Communication The RFM12B RF transceiver can be operated in two modes FIFO mode and raw mode In FIFO mode a byte is transferred to from the chip over SPI and the RFM12B takes 47 Chapter 7 RF Communication with CanSat care of transmitting receiving the byte In raw mode every single bit is received sent directly on a GPIO pin It has been chosen to use the tranceiver in FIFO mode It is possible to have the RFM12B look for a synchronization pattern in the received byte stream Filling of the FIFO will be disabled until this pattern has been received The pattern 0x2DD4 is used as this synchronization pattern Before sending anything the RFM12B requires a preamble to be sent This preamble should contain many 0 1 and 1 0 transitions as it s used to tune receiver frequencies 3 preamble bytes with the value OXxAA are sent prior to the synchronization bytes The RFM12B hardware FIFO is o
87. d safety as described in section 10 2 5 on page 98 10 4 2 Receive Method In order to get the data from an incoming package it needs to be disassembled This is to be done in accordance with the RUC protocol Each byte from the input stream is copied into a ByteBuffer and in the end the entire package is available for disassembling The approach chosen is as follows 1 Determine if the byte is escaped or not if so set the escaped flag This is used to remove all escape characters as they are received 2 If an unescaped start byte is found start decoding the package by writing un escaped bytes into a buffer 3 After two bytes the length is saved and can be used to allocate a buffer long enough for the entire package 4 At byte 3 the package type is saved 5 The following bytes are saved in the allocated ByteBuffer When the entire pack age is saved in the buffer a switch statement decides what to do with the package based on the package type For example if it is a package type 0 the ByteBuffer contains a CanSat package and is thus passed to the processSatDataPacket method for disassembling This way relevant information can be stripped from the packages and written to the right places for later use Such information is written to labels and text areas inside the GUI and to CSV files 102 Section 10 5 Verification Within the processSatDataPacket method the type O package is disassembled This i
88. d station software a subset of the Hard Real Time Hierarchical Object Oriented Design HRT HOOD method has been used The method has especially been useful in visualizing both execution path and data flow in an unified clear diagram This has provided the group members with an equal compre hension of the overall software structure in the early design phase thus helping to avoid misunderstandings Technical Results The ARM Real Time Operating System ARTOS has been developed to gain insight into the inner workings of operating systems This operating system is preemptive and provides multiple ways of inter process communication On top of this an Ethernet link has been implemented using a dedicated Ethernet controller and the uIP TCP IP protocol stack The throughput of the link is sufficient to fulfill the requirements of the 121 Chapter 13 Conclusion project but it is noted that the uIP TCP implementation is very prone to delays in the network for example caused by the delayed acknowledgement algorithm used by most network interfaces Higher throughput may be achieved by using UDP instead which is also supported by uIP The reliability features of TCP must then be implemented by the application layer when needed though The wireless link between CanSat and ground station has been implemented using the RFM12B radio model utilizing the license free 868 Mhz frequency band For a bit error rate of 0 1 and a required range of 1500 m
89. d to let the cur rent task run to completion when no higher priority task wants to run without doing unnecessary context switches The number of priorities is set at compile time 5 4 Verification As the operating system provides the base for the rest of the software it is important that the programmer can rely on its functionality The reliability is tested through verification tests During development a lot of ad hoc tests have been performed to test specific features Furthermore four formal tests have been constructed 1 Critical regions by disabling enabling interrupts Two equal priority tasks prints to the serial port in a critical region 2 Mutual exclusion by the use of semaphores Two equal priority tasks prints to the serial port in a critical region as in the last test but this time the critical region is implemented by the use of semaphores 3 The creation of periodic tasks and the use of semaphores for task synchronization One task uses the osWaitForDivisibleTick system call to run periodically When executing it signals another task by the use of a semaphore Both tasks prints to the serial port when executing 4 The use of queues in a producer consumer situation One high priority producer task writes 10 values into a queue with the capacity of only 4 values The consumer task continuously reads values out of the queue in order to make room for all the producer values Each task prints the value
90. dically calls uip periodic every 0 5s and uip_arp timer every 10s This enables uIP to clean up it s ARP table from time to time and decide when to retransmit TCP 40 Section 6 3 Integrating the uIP TCP IP Protocol Stack ENC28J60 receivePacket gt Ethernet frame appcall setElevation Ethernet frame TCP data Elevation angle Ethernet frame transmitPacket Figure 6 3 Example ulP call graph on incoming Ethernet frame illustrated as an UML sequence diagram A Ethernet 8 RUC protocol Ss enclrqHandlerTask ASER ethernetSend __ pke Out 1 ASER_BY_IT start 7 5 ethSendertask l uipPeriodicTask ASER start Pr uipsemaphore P ui i A ay P P encDeviceDriver pkg Out H F SER uip_poll g 7 ENC28J60 HSER upnout O Hen encransmtractet ernemet Controller HSER uip_periodic lt Ethernet connection frame In Ou atus P Appcall P ethPkgHandler OG Ethernet TCP data In frame In Out ES gt HSER Appcall ker tint HSER ethPkgHandler TCP o gt Q data Ou Nox Ctrl options o gt HSER set Antenna controller options ASER Send cmd to CanSat CanSat cmd number Figure 6 4 HRT HOOD logical architecture design of the Ethernet communication software module Three ta
91. direction and thus point the antenna in that direction In order to do so the GPS coordinates must first be converted to a corresponding azimuth and elevation To do this the coordinates are extracted and by using them along with the coordinates of the ground station the wanted azimuth and el evation can be calculated using trigonometry This section describes how this conversion is done Format of GPS Coordinates According to the WARP specification specified in appendix B on page 131 the GPS coordinates consist of 3 elements These are longitude latitude and altitude The coor dinates are spherical and specifies the position of an object on the surface of the Earth with respect to sea level Longitude is specified by degrees 0 180 minutes 0 000 59 9999 and a letter specifying if the object is on the western W or eastern E hemisphere Latitude is specified in the same way by degrees 0 90 minutes 0 000 59 9999 and a letter N or S The altitude is specified in meters above the sea level Coordinate conversion The most accurate and correct approach to handle the coordinates is to first convert them from the spherical to a Cartesian coordinate system and then perform the necessary trigonometry to calculate azimuth and elevation This way the curvature of the Earth is taken into account and the system will be operational on a global scale However this method is computationally intensive to use Since the gro
92. e for every package Before connecting the CSV filename has been set to CSVfile A snapshot of the received data is shown in figure 2 1 on the following page and a snapshot of the saved data is shown in figure 2 2 on the next page It is seen that the saved data matches the received data The test is now repeated only this time the RUC is terminated by the OS after 5055 packages are received A snapshot of the contents of the CSV file can be seen in figure 2 3 on the following page It is seen that the CSV file contains 5055 valid packages A similar test was done for the ControlInfo data with similar results 2 5 Measurement Uncertainties One uncertainty is the platform as a RUC crash might be treated differently depending on the OS It is assessed that no other measurement uncertainties played any significant role 24 5ournals ruc_csv 153 Journal 2 Test of RUC CSV File Saving 154 y Z EJ Remote User Client No w m p 6 6 6 00 12222 6 6 6 po 00 as 12222 6 65 65 Figure 2 1 The contents of the data log from test 1 after 10 000 packages F Su Al a E E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65 E 33 N 0 44 65 65 65
93. e Automatic retransmit on collision and automatic rejection of erroneous packages e Automatic generation of preamble CRC checksum and padding for Ethernet frames e SPI interface with clock speeds up to 20 MHz Runs at maximum speed of LPC2138 7 4 MHz e Programmable receive packet filtering based on Ethernet packet addresses e Configurable 8 kB transmit receive FIFO buffer e One interrupt output pin connected to EINTO of LPC2138 e Two configurable LED outputs for PHY chip status indication The Ethernet controller is configured to discard Ethernet frames with a different destina tion MAC address than the one assigned to the controller An Ethernet frame is shown in figure 6 2 on the next page The Ethernet controller will automatically generate the preamble and Start Of Frame byte as well as the padding and checksum The address fields length and data must be filled in by the software at higher layers ENC28J60 contains three types of memory e Control Registers e Transmit receive buffer 38 Section 6 3 Integrating the uIP TCP IP Protocol Stack 18 I Destination Source Check Preamble Mides ES Length Data Padding SUA 7B 6B 6B 2B i 0 46B 4B Start Of Frame 0 1500B Figure 6 2 EEE 802 3 standardized Ethernet frame format 22 e PHY registers The PHY registers are accessed through the control registers and are used for configuring the PHY module The transmit receive buffe
94. e between the two antennas m The RFM12B chips can transmit a signal with 4dBm power 11 The whip antenna used on the CanSat is assumed to be isotropic ie G 1dBi The antenna used on the ground station has a max gain of 11 5 dBi 26 but it will not always be pointed directly 46 Section 7 3 Software for RF Communication at the CanSat and the gain will thus be lower It is assumed that the CanSat is always within the half power beamwidth area of the antenna ie G 11 5dBi 3dB 8 5 dBi The half power beamwidth is achieved at angles up to 25 to each side of maximum radiation 26 At launch the ground station is to be placed at least 400m from the CanSat and the CanSat is expected to be launched to a height of approximately 1000 m Given these data and noting that the CanSat is not launched and descending in a direct vertical line the maximum distance is set at 1500 m Given these data calculating the power available at the receiving antenna terminals gives 7 2 P log 1 5 1 368MB2 10 10 81 4dB 08 Je EE E E NES where c is the speed of light 300 10 F In the calculation P is converted from a value in dBm to a value in mW which is then converted back to dBm when calculating P The calculation is valid both for sending from CanSat to ground station and for transmission from ground station to CanSat At 19 2 kbit s the RFM12B module has a sensitivity of 102 dBm when a BER Bit Error
95. e error and so on is calculated 73 Chapter 9 Feedback Control of Pan amp Tilt Platform 1 T T T T T T T T 0 9 J 0 8 F dl 0 7 4 Cc O i 8 0 6F i 4 8 0 5F 4 lt wn o 0 4 4 gt O i 0 3 H 7 0 2 4 0 1L ee 0 0 10 20 30 40 50 60 70 80 90 Phase margin Figure 9 9 This figure illustrates overshoot My as a function of phase margin PM It is calculated on basis of equation 9 7 on page 67 Bode Diagram Gm Inf dB at Inf rad sec Pm 60 deg at 16 rad sec 50 r 7 r T AA a ee ee A E J jo 2 50 J gt 100 i i 90 mr D e eres e ro eds A ash eit ey eg E aces lt 180 Bike ee ne a RO AE MA E A AT 10 10 10 10 Frequency rad sec Figure 9 10 This figure illustrates the phase margin of the open loop system with lead compensation 74 Section 9 3 Implementation The steady state error of the system can be calculated in the same way as for the azimuth controller The elevation controller with lead compensation is also a type 1 system which means that the steady state error of a ramp input is given by Css ramp lt rad 9 30 where Ky lim sD s G s 9 31 In this case Ky lims E ated Ky 07 33 9 32 s gt 0 0 003 s3 0 104 s2 0 915 s Which means ess ramp is given as 1 ss ramp 17 33 In order to find the sample frequency ws the bandwidth wgw of the closed loop can be found from a
96. e ground station The Wanted Azimuth and Wanted Elevation indicates what position the antenna is moving towards This information is useful for both remote controlling of the antenna and for debugging the designed controller for the antenna For debugging reasons both current and wanted azimuth and elevation are saved into a CSV file called RegInfo as further described in section 10 2 2 on page 95 The angles written in these labels are specified with the unit one tenth of a degree Incidentally 47 degrees would be written as 470 This information is retrieved through package type 1 in the RUC protocol The input fields Manual Azimuth and Manual Elevation seen on figure 10 13 are for typing in a specific direction in which the antenna is to point To apply the new setting the user would have to click the apply button which would send a package type 128 to the ground station with the new setting The angle entered here is in the same format 98 Section 10 2 User Interface and Functionalities as the status labels The Azimuth is limited to values between 1800 and 1800 and the Elevation is limited to values between 700 and 400 These Azimuth and Elevation limits are set to prevent the antenna from damaging itself The button called Arrow Key Control in figure 10 13 on the preceding page allows the user to use the keyboard arrow keys for controlling the antenna as long as the Arrow Key Control button is in focus Each time a keypressed
97. e is no stack overflow detection in ARTOS Stack overflow detection in a MMU less system could be implemented by putting a known value at the top of the stack and then do periodic checks to see if the value has been overwritten This technique is used by the real time operating system FreeRTOS 15 A task can be in three different states as shown on figure 5 1 on the following page Only one task can be in running state When a task leaves the running state all the current registers will be saved in the task descriptor s context array When a task reenters the running state the registers will be reloaded from the task descriptor The transition to blocked state can only happen on syscalls e g performing a read request on an empty queue When the resource becomes available the task will go to the ready state and the scheduler will pick the task with the highest priority which will become the running task Notice that there are no state information in the task descriptor struct and there are no process tables in the OS The state of a task in ARTOS depends on which linked list the task is a node of This is what the next Task pointer is used for A task can appear 33 Chapter 5 Real Time Operating System Task is picked by scheduler i duler picks another tasli Task requests unavailable resource Resource becomes available Blocked Figure 5 1 Tasks can be in three different states Transitions between the st
98. e of sight at a distance of 1 5km The RUC is then connected to the ground station and the corresponding SatID is specified The CanSat is fitted with a serial connection which writes the received data to a computer and enables it to send packages on demand At a certain time a stopwatch is started and the CanSat is set to transmit 60 byte packages at a rate of 5Hz After 5 minutes the CanSat stops transmitting and the received packages are inspected Afterwards this is repeated in the opposite direction In order to pass this test no more than 10 package loss is permitted in either direction This is calculated from the expected number of packages relative to the number of valid packages received 19 Chapter 3 Requirements Specification Test 6 Covers Requirement 8 The ground station is set to move the antenna along a predetermined path as described in requirement 8 Using saved information from the controller such as where the antenna is moving towards and where its currently located the maximum deviation is determined To pass this test the maximum deviation must remain within the half power beamwidth of the antenna at any given time 20 Part II Design amp Implementation CHAPTER Modularization After having completed the initial analysis of the system and having specified requirements for it the design of the system can begin In section 2 2 1 on page 6 an outline of the system components is shown It ca
99. e sampled at To calculate the sampling frequency ws the following design rule is used Es p0 9 9 67 Chapter 9 Feedback Control of Pan amp Tilt Platform Ws is the sampling frequency rad s wgw is the closed loop 3 dB bandwidth of the system rad s To ensure that the system is stable in the sense of BIBO stability it is important to choose a sufficient phase margin When doing a stability analysis the open loop L s of the system is plotted in a bode plot In order for the system to be stable the phase at the crossover frequency we isn t allowed to be 180 or below Please note that this stability criterion is not applicable to all systems in general 31 p 337 A rule of thumb is to choose the phase margin to be 45 or more This insures stability in the system With a proportional controller the phase margin is typically increased by decreasing the gain which in turn makes the system react slower to changes The design rules for the time and frequency domain can now be employed when designing the controllers 9 2 2 Azimuth Controller To make the design of the azimuth controller as simple as possible it has been chosen to design a proportional controller This approach is assessed to be sufficient because of the simplicity of the model If the designed proportional controller doesn t live up to the requirements a iteration of the design phase is necessary A block diagram of the azimuth control loop can be se
100. e will be extracted from received type 1 packages in the RUC protocol which can be seen in appendix C on page 135 An example of such a CSV file can be seen in figure 10 8 CurrentAzimuth CurrentElevation WantedAzimuth WantedElevation regtimestamp 1 1 241 241 4279238415 1 1 241 241 4279238415 1 1 241 241 4279238415 1 1 241 241 4279238415 1 1 241 241 4279238415 1 1 241 241 4279238415 1 1 241 241 4279238415 Figure 10 8 Snapshot of a control CSV file example The data types contained within this CSV file are fixed The CSV file illustrated in figure 10 8 will allow the user easy access to controller data about the antenna tracking and thus provide useful information during debugging and testing of the controller This CSV file will always contain the information within the Controllnfo packages 96 Section 10 2 User Interface and Functionalities 10 2 3 Ground Station Location In order to use automatic tracking the ground station must know its own location Because of this the RUC must implement a way for the user to enter this information Such an implementation can be seen on figure 10 9 Communication Out m Altitude EW deg min 1 1000 min Longitude InsertLatestGPS N S deg min 1 1000 min Latitude SetGSLocation Figure 10 9 Communication Out panel in the RUC The text fields and buttons are used to
101. eadOp uint8_t operation uint8_t address 6 3 Integrating the uIP TCP IP Protocol Stack The uIP TCP IP protocol stack software implementation is designed to be compatible with tiny 8 bit microcontrollers without operating systems In this section it is discussed how this library can be integrated into the ground stations operating system As a reference the uIP documentation provides an example main loop which is polling uIP and the device driver continuously See appendix D on page 137 for the example The polling wastes a lot of CPU cycles In this section a more efficient structure is found by utilising several tasks but in order to do this a brief analysis of the uIP implementation is required Because ulP is targeted at small microcontrollers some limitations exists in order to keep the memory footprint small One statically allocated buffer uip_buf is used for all packets which implies that only one Ethernet packet can be outstanding at any time For example uIP can t send a new TCP package until the last one has been acknowledged The size of the buffer determines the maximum TCP segment size supported This size is limited by the maximum size of IP packets sent over Ethernet which is 1500 bytes as 1 groundstation chips enc28460 lt c h gt 39 Chapter 6 Wired Communication with Remote User Client stated in RFC894 23 The ground station will act as a TCP server and in order to keep things simple only one TCP conn
102. easured and noted 5 Using the scale all the elements are weighed The weights are noted Formulas Used For calculating gear ratios the following formula has been used NM 3 1 where N isthe gear ratio Ri Is the radius of the cog wheel where torque is applied directly Ra Is the radius of the cog wheel being driven by the gear B S For calculating moments of inertia three different formulas have been used for the tower the foot and the antenna Antenna inertia To simplify calculations the antenna is assumed to have the same inertia as a rod with a given length and mass With this assumption the moment of inertia is given by 39 1 Ja a5 M P 3 2 156 Journal 3 Model Parameter Determination Tower inertia The tower is assumed to have the same moment of inertia as a hollow cylinder with a radius corresponding to the width of the tower The moment of inertia is then given by 39 J M r 3 3 Foot inertia Since the foot of the platform is also hollow but with thicker walls it s moment of inertia is given by 39 1 Jp 5 Mri 13 3 4 Results The measured values are shown in table 3 2 Property Value Unit Motor shaft diameter 5 1078 m Azimuth cog wheel diameter 44 5 1073 m Elevation cog wheel diameter 23 107 m Tower diameter 25 1073 m Tower mass 1 668 kg Foot outer diameter 65 1073 m Foot inner diameter 50 1073 m Foot mass 2 1073 kg Antenna length 605 1073 m Antenna mass 0
103. easured for one single task at a time by having it toggle a digital I O pin upon start and stop of execution of the task Pin 0 27 is used for this purpose The measurement is described in journal 5 on page 163 Priority Task name Type Tiin c Ta FIQ encoderElevationISR Sporadic 60 us 28us l5pus IRQO encoderAzimuthISR Sporadic 60 us 37ps 15ps IRQ4 rfmIrqHandler Sporadic 417yus 110ys 417ps IRQ5 encIrgHandler Sporadic 100ms 22 1u4s 1ms 5 controllerTask Cyclic 8ms l lms 2ms 4 rfmPkgHandlerTask Sporadic 100ms 712yus 36 ms 3 uipPeriodicTask Cyclic 500ms 4 6ms 50ms 2 encIrgHandlerTask Sporadic 100ms 2 6ms 50ms 1 ethSenderTask Sporadic 56ms 5 5ms 36ms Table 11 2 Timing attributes associated with the different tasks in the ground station system Table 11 2 shows the tasks in the ground station system and the associated timing at tributes The computation times have been measured for different states of the software but only the longest computation times are used For the Ethernet tasks Tmin and Ta have been determined above In the following the timing attributes for the remaining tasks will be discussed encoderElevationISR amp encoderAzimuthISR The encoder interrupt service rou tines are invoked every time a rising edge occurs on the output pin on the motor encoders This happens for every 3 rotation on the motor axis The maximum speed of the used motors 32 are 8300 rpm 138 33 2224 29 which gives the fol lowing minimum
104. ection is supported although uIP can be configures to support multiple connections 6 3 1 Communicating with uIP The communication between uIP and the layers around it mainly goes through the global variables uip_len and uip_buf The variable uip_len contains the number of currently valid bytes in the buffer The device driver will never be called by uIP itself Instead the value of uip_len will be set to a non zero value after the invocations of some uIP functions to indicate that data is ready to be sent to the Ethernet controller On the contrary uIP will call the user defined function appcall when some event is relevant for the application layer When the appcall is invoked uIP has set some global flags which can be checked inside the appca11 in order to find out why the invocation happened e g uip_connected uip_newdata uip acked For clarification the following example goes through what typically happens in the main loop shown in appendix D on page 137 when a new Ethernet frame arrives 1 encReceivePacket copies the frame from the Ethernet controller to uip_buf and uip len is set to the number of bytes read 2 The frame contains an IP packet so uip input is called from the main loop 3 The packet is processed by uip input and identified as a TCP data packet The newdata flag is set by uIP and appcall is invoked 4 The application checks the newdata flag and reads out the data from uip_buf In th
105. ed by preceding it with itself e Any package sent must not be longer than 150 bytes excluding start and stop bytes and escape characters That means the maximum package size after adding start and stop bytes and escape characters will be 302 bytes which is reached when all characters in the package must be escaped B 1 General Package Layout Figure B 1 shows the general package layout shared by all package types joxBe t i ff eres oxEF 8b lb 3b 4b 8b 8b Figure B 1 General package layout shared by all package types The fields in the package are as follows e OxBE and OxEF These are start and stop bytes used to delimit each package e CTS Clear To Send only in packages going from the CanSat to the ground station If this is 1 the ground station is allowed to send a package to the CanSat after receiving the current package 50 ms after the complete receival of a package with CTS set to one the ground station must be done sending it s package 131 Appendix B WARP Protocol Specification e PKGtype The package type which is a number between 0 and 7 thus allowing for 8 package types SatID Satellite ID which is used to distinguish the packages transmitted from and sent to different satellites if multiple satellites are airborne at the same time It is a number between 0 and 15 so up to 16 satellites can be airborne at the same time CRC8 This field contains a CRC8 checksum of the package The check
106. ementing the individual subobjects the objects are further decomposed After this no physical architecture design is performed instead detailed design and coding of the subobjects is done Hereafter measurements of the execution time of the code is used to perform an schedulability analysis to ensure the system will satisfy the timing requirements set to it Before constructing the subobjects an operating system that implements the required multiprogramming facilities must be employed 4 3 2 HRT HOOD Objects An object in HRT HOOD is represented graphically as shown in figure 4 3 on the next page Each object specifies it s name type and the operations that they provide The operations of an object make up the interface it provides to other objects 5 types of objects exists each describing when the code of the object is executed These are as follows A Active The most general type of object it has no restrictions placed on them May control when invocations of their operations are executed Can be decomposed into a number of the remaining object types P Passive When invoking an operation on a passive object it is performed immedi ately This effectively corresponds to a call to a method in fx C which is also the way these object types are implemented Pr Protected Represents code or data that must be accessed under mutual exclusion C Cyclic Periodic activities that execute irrespectively of whether there are any of it s
107. en acknowledged If the packages going from the ground station to the CanSat are lost or contains errors detected by examining the checksum and an acknowledgement package thus is not returned the ground station must re send this package after some timeout period It is noted that if an acknowledge package is lost or erroneous on arrival the ground station will retransmit the original command package after the timeout time The CanSat must thus keep track of which package numbers it already received successfully and the only action to take when a repeated package arrives is to retransmit the acknowledge of it B 5 Remaining Package Types The remaining package types from type 2 7 can be utilised as desired Obviously they must follow the general package layout Devices must ignore all packages of unknown package type that are received 134 Appendix C RUC Protocol Specification Appendix C RUC Protocol Specification The RUC protocol is an application level protocol to be used on top of a TCP IP connection between the remote user client and the ground station These conventions apply e Each package is started by the start byte character 0xBE e Any occurrences of the start byte in the package content must be escaped using byte stuffing with the escape byte character OxEF Occurrences of the escape character itself must also be escaped the same way e The communication is to be performed o
108. en in figure 9 3 1 657 0 2775 s 3 506 S Figure 9 3 This figure illustrates the block diagram of the azimuth control loop Time Domain Design The transfer function of the azimuth plant can be seen in equation 8 49 on page 63 If the controller D s is chosen only to be a proportional controller and the feedback H s is 1 then the closed loop expression is given by Kp 5 971 T s 2 F12634 s 5971 K 9 10 It is a 2 order expression of the general form seen in equation 9 5 on the preceding page and therefore the design rules described in section 9 2 on page 66 can be applied From equation 9 10 wn and can be defined which then leads to equations for tr ts and Mp wn 5 971 Ky rad s 9 11 ia 12 634 4 9 12 5 971 Ky 68 Section 9 2 Controller Design The expressions for w and can be put into the expressions for M and t and then solved since the maximum value of M and the minimum value of t are known 138 tr lt 0 2 gt lt 0 2 gt K gt 13 6 9 13 J51 Kp p 12634 971 K M lt 0 1 gt exp EEE og Ne Bo 9 14 2 1 12 634 2 4 5 971 Kp From the equations above it is clear that if 13 6 lt Kp lt 19 1 then the requirements for M and t are fulfilled The settling time ts if the threshold is set to 1 can be calculated by eq 9 8 on page 67 and becomes 0 729s The value of K has no effect on t because it is cancelled out in
109. ent GroundstationApp GroundstationView groundstationView GroundstationConnection groundstationConnection GroundstationData groundstationData app startup GroundstationView cclass Integer model DefaultTableModel packageFieldTypes ArrayList packageFieldLabels ArrayList packageFieldStringSize ArrayList view readTextFieldsAndLabels grayOut actionButtons write TextFieldsAndLabels writeDataTable GroundstationConnection GroundstationData ipAddress gpsData flags timeStamp socket flags ae data O peda writelnitalCSVFiles ourpuleream processCanSatData connection addData disconnect writeCSVFiles connect T newThread i send IVA receive lt lt interface gt gt Type addData Figure 10 3 Class diagram showing the structure of the RUC Notice the class attributes and methods have been simplified and renamed in order to maintain the overview The public and private indicators have been removed from the attributes and methods PC Ground Station Status Disconnected IP gr503 lab es aau dk Connect CanSatID 13 Disconnect Conformance Class 1 Conformance Class 2 Figure 10 4 The PC Ground Station panel as seen in the RUC 94 Section 10 2 User Interface and Functionalities Upon making the initial connection the RUC specifies the current settings by sending a number of packages to the ground station
110. ent of Worst Case Execution Times 5 4 Results Task ISR Case time ethSender Task 5 5 ms uipPeriodicTask 4 56 ms encIrqHandler Task 510 byte RUC data 26 6 ms 27 byte RUC data 2 6 ms rfmPkgHandler 712 us controllerTask 1 076 ms encIrqHandler 22 2 us rfmIrqHandler Receive last byte 110 us Receive normal byte 36 0 us Transmit normal byte 38 0 us Transmit last byte 66 8 us encoderAzimuthIRQ 3 71 us encoderElevationFIQ 2 81 us Table 5 3 Measured worst case execution time for the tasks and ISRs of the ground station software 5 5 Measurement Uncertainties There is a limitation in how accurate the execution time of each task can be measured In the measurements of the ISRs the time used for reading the interrupt vector from the interrupt controller of the LPC2138 is not included in the measurements as well as the time used for saving and restoring two registers In order to compensate for this an extra execution time of approximately 50 clock cycles 1 us can be added to the ISRs of the IRQs and 20 clock cycles 0 3 us to the ISRs of the FIQ These values are however rough estimates Larger values can be added to the execution time of the tasks in order to compensate for the overhead of context switching 165 Journal 6 Acceptance Test 1 Journal 6 Acceptance Test 1 6 1 Purpose The purpose of this test is to determine if the designed system meets requirement 1 and 2 in the requirement specification seen in section 3 2
111. ents to the deadline for this task e The time it takes to initiate transmission of CanSat commands when packages with the clear to send bit set is received e The time it takes to process reception of GPS coordinates and feed these into the controller When receiving a package from the CanSat it will contain a bit specifying whether the ground station is allowed to send commands to the CanSat in the following 50 ms The packages that are to be sent to the CanSat can be up to 12 bytes long including start stop and escape bytes A package of this size takes the following time to send including a preamble and synchronization pattern of 7 bytes 3 1 12 7 bytes 19200 P EUU 7 9ms 11 3 8 Do When receiving a package specifying that the ground station is allowed to send it has 50ms to send the package The processing of the package is thus allowed to take 50 ms 7 9 ms 42 1 ms From receiving a set of GPS coordinates to these have been fed into the controller a maximum of 36ms may pass see section 2 3 1 on page 9 This is the most stringent deadline and the tasks deadline is thus 36 ms The deadline of the rmfPkgHandlerTask ensures that the telemetry data from the CanSat will be in the Ethernet out queue within 36 ms after reception The interarrival time of the ethSenderTask ensures that the Ethernet out queue will be emptied ev ery 56ms In worst case the just received telemetry data will suffer
112. er away until it is not possible to hold the antenna in a position where even a single package can be received without errors 8 Again note some landmark 9 Measure the range lengths by use of Google Maps The results from the test can be seen in table 1 2 Test Result m Always acceptable connection 260 No error free packages received 400 Table 1 2 Measurement result for uplink test 1 5 Downlink Test For the downlink test the following steps are performed The test is done in both a vertical and horizontal orientation to examine the effect of wrong polarization between the antennas The antennas are polarization matched when holding the CanSat antenna in a horizontal position 18 groundstation 19 jo0urnals rf_comm uplink test diff 20 journals rf_comm uplink arduino 151 Journal 1 Range Test of RF Communication The arduino mini pro is programmed with the software found at 1 This software transmits a package similar to the one in the uplink test every second Note that the package has a valid CRC8 character in the end Also the letter r is printed on the arduino s serial port when a package has been transmitted The ground station is programmed with the software found at with the patch 652 applied This software echoes all received packages to the serial port The ground station antenna should point directly towards the CanSat antenna at all times during the test With a laptop co
113. erform some sort of remote control of a CanSat while they are airborne The communication protocol must thus be 2 way and allow commands to be sent from the ground station to a CanSat What these commands do is not to be specified by the protocol To keep the protocol simple it has been chosen that the command is sent as a command number that can then be used to execute the corresponding function on the CanSat It will not be possible to send arguments along with the commands It is required that only one ground station is communicating with each CanSat A transmission scheme similar to the one used for transfer of telemetry data cannot be used for this When the user has asked for a command to be executed he needs to be assured that this command has actually been performed Therefore a scheme where a CanSat has to send an acknowledgement after successfully receiving a command package will be used It is desired to ensure that the ground station doesn t transmit a package at the same time as the CanSat is transmitting a package For this a flag in the packages going from the CanSat to the ground station is used to indicate if the ground station is allowed to transmit in a time interval following the reception of the package This time interval has been chosen to be 50ms As it will be shown in chapter 11 sending a command package in the used setup will take 8 ms 12 CHAPTER Requirements Specification The analysis in the previ
114. eriodicTask ASER start lt iA uipSemaphore N P ui A RUA A E encDeviceDriver kg Out A 1 rer HSER uip_poll O f HSER encTransmitPacket eee ict HSER uip_input 20 NU HSER encReceivePacket HSER uip_periodic lt Ethernet Connection frame In Out Status RUC 4 AN P Appcall P ethPkgHandler HH OG Ethernet TCP frame In Out Controllnfo pkg data In RUC HSER Appcall pkg In HSER ethPkgHandler TCP OS Y data Ou 7 Y gt data P options Antenna Controller el controllerTask calibrate HSER setAutoCtrl On OMO HSER calibrate Av Elvalues HSER setAutoCtrl o gt HSER setManualDirection HSER setManualDirection HSER setGroundstationLoc a GPS data O gt HSER setGroundstationLoc HSER setControllerType Ctrl Type O gt HSER setControllerType setNonlinearCompensation gt HSER setNonlinearCompensation setCanSatLoc On Off O gt HSER setCanSatLoc GPS data Q gt encoderAzimuthISR encoderElevationISR ASER BY IT start ASER BY IT start Azimuth Elevation rotary encoder rotary encoder Figure 11 1 HRT HOOD logical architecture design of the final ground station software The white boxes represents passive objects that doesn t have their own tasks or ISRs allocated to them The circles with arrows indicates the data flow 107 Chapter 11 Scheduling of Ground Station Software A task is determin
115. es how the motor driver is linked together with the ARM board and the motors ARM board Azimuth Vist SD 8 5 1 PWM2Q 4 amp 3 i II ne 12V AZI_CWO 2 oL gl y c2 sIn 7408N 100n E E eS ici ME hi BR mima BA a ri Ne I vec vs f ANW le Motor 0 2 6 Y ENABLE A SENA H R2 2 MOI M1_2 AzI_CCWQ 5 gt ENABLEB SEN B 15 3 2 o2 ae ak 7408N 5 INPUTI our FF Elevation INPUT2 OUT2 A 49 inPura ours 13 L PWM5O H amp 5 INPUT4 OUT4 GND GND ELE CWO 19 8 GND SiN 7408N L o gt 2 v1 4 GND 12 amp 82 Elevation fa 4 Motor gt E ELE_CCwO 8_ O O 6 7408N M21 M22 E 5 ENCODER sA EIN E 6 1 ENC_AZI 5 gt dl iL 8 3 5V ENC_AZI BO 7 7 END GND 10 B L Azimuth GND ENCODER2 6 1 ENC_ELE 7 2 ENC_ELE_BO S s 5V 10 BE sal Elevation GND Figure 9 17 This figure illustrates the schematic of the motor driver The L298 IC 35 is a dual full bridge driver designed to drive inductive loads such as DC motors From the L298 datasheet 35 a standard application for driving a DC motor has been chosen The diodes function are to take care of the voltage inducted by the motors The sense output can be used to provide overcurrent protection or just measuring the motor current The AND gates are added because the PWM signal fo
116. est received telemetry data This backup must contain data from the last 5 minutes or more given a package rate of 5 Hz with each package being the maximum package size 150 bytes Due to time limitations the ground station data backup was never implemented into the designed system Testing this functionality is therefore pointless and the test is considered not to be passed Evidently requirement 6 isn t satisfied 12 1 5 Test 5 Covers Requirement 7 e The connection between ground station and CanSat must be able to transmit 60 byte packages at a distance of 1 5km with a maximum package loss of 10 This is assuming that the CanSat and ground station are placed in line of sight the CanSat is within the antennas half power beamwidth and the package transmission rate is 5 Hz Based on the test results from measurement journal 1 on page 150 it has been decided not to test this requirement This is because the journal shows that all packages were corrupted at 400m for uplink transmissions and after 3m for downlink transmissions The journal used 21 byte packages at a transmission rate of 1 Hz The acceptance test specifies a distance of 1 5km in either direction for 60 byte packages at a transmission rate of 5Hz Because the demands set by the acceptance test are much stricter such a test wouldn t be reasonable to conduct Therefore requirement 7 isn t satisfied 12 1 6 Test 6 Covers Requirement 8 e The ground station must be able
117. event from one of the arrow keys is captured the angle is changed 3 degrees or to the limits and a package type 128 is send with the new values 10 2 6 Ground Station Commands In order to send commands from the RUC to the ground station a package type 131 is specified in the RUC protocol in appendix C on page 135 It can be seen from the RUC protocol that each ground station command has a valid range between 0 and 255 even though most of the numbers aren t used Since each command number serves a specific function their functionality is implemented with buttons All these buttons are grayed out until a connection to the ground station is established Command 5 6 7 8 and 9 are implemented with the buttons seen on figure 10 14 Controller Settings Controller P P Controller Model Non inearity correction enabled PI Controller Lead Controller J Enable non inearity correction Disable non inearity correction Figure 10 14 Controller panel in the RUC The buttons are used to set the controller options on the ground station These buttons manages which controller and model the ground station uses for con trolling the antenna The labels seen on figure 10 14 indicates which model and controller is currently selected Clicking the Get Saved Data button as seen on figure 10 15 will send a ground station command package 3 Notice the PI Controller and data storage for the Get Saved Data feature was never
118. expression is derived from eq 8 4 on page 53 with E Ia t 0 as the effect of La is neglected as previously mentioned and w t 0 as the offset voltage will not cause the motor to rotate peed eee 8 22 ana oe en 8 23 y Ra Voffset he K 8 24 8 4 Non linearity in Elevation Model For elevation the antenna rotates around a horizontal axis Therefore it would be ideal to have its center of mass lie exactly on the axis of rotation whereby the gravitational force would be equal in both ends effectively cancelling out regardless of orientation Due to the design of the antenna though it has been necessary to mount it so the center of mass lies approximately 5cm above the axis This means that gravity does affect the antenna differently depending on how far to either side it s been rotated This is not a problem for azimuth rotation e I 24 1 e e 03 e 1 F e ASL F I a I 24 1 I d e S H 4 yf H e O s e Fy Ses l AS ety l 4 e K Y e Pe e se Figure 8 6 An illustration showing how gravity affects the rotation of the antenna in the elevation direction Figure 8 6 shows how gravity affects the system The angle 0 specifies the rotation of the antenna and F is the gravitational force the product of the gravitational constant 97 Chapter 8 Modelling of Pan amp Tilt Platform g and the mass of the antenna m To calculate the effect of gravity more specifically t
119. f the elevation during the constant velocity s7 phase a is the acceleration during the constant acceleration phase Umax is the maximum velocity of the rocket 2 r is the horizontal distance between the ground station and the launch m site hy is the distance travelled by the rocket during the constant acceleration m phase ty is the duration of the constant acceleration phase s t is the time since the beginning of the launch s With the assumed values for r a and Vmax the angular velocity of the elevation angle versus time can be plotted as shown in figure 2 3 on the facing page The angular ve locity increases during the acceleration phase and the maximum velocity is reached in under 1 second From the graph the maximum angular velocity wmax can be read as approximately 0 4rad s Note that because of the assumptions made in the calculations the angular velocity found is a rough estimation 10 Section 2 3 WARP AAU Radio Protocol 0 5 T T T T T T 0 4P 4 o rad s 0 0 5 1 1 5 2 2 5 3 3 5 4 4 5 5 t s Figure 2 3 Calculated angular velocity of the desired ground station elevation versus time during the launch GPS position update time The maximum angular velocity of the antenna tracking platform has been calculated to approximately 0 4rad s This value can now be used to get an idea of how often the GPS position must be updated in order to be able to track the CanSat with the antenna It is assumed that
120. f the report These appendices contains test journals protocols and other things that support the development of the product as well as the report The appendices are denoted A B C and so on while the test journals are numbered In appendix G on page 146 a schematic of the entire system and a part list can be found Along with the report a CD is enclosed containing datasheets developed software test software Matlab scripts and a PDF version of this report On the CD a folder with videos and pictures of the developed system can be found Throughout the report there will be referenced to material on the CD in this way the full path can be found as a footnote Kent Basselbjerg Thomas L Hansen Peter B Jorgensen Niels G Myrtue Rasmus Pedersen Bo Povey 1 multimedia 1 Introduction Part I Project Specification 2 Preliminary Analysis 2 1 CanSat Competition 2 2 System Overview 2 3 WARP AAU Radio Protocol Requirements Specification Sel USE CASOS n dd of wie ee A A A 3 2 Requirements Specification 3 3 Acceptance Test Specification Part II Design amp Implementation 4 vi Modularization 4 1 Utilized Hardware 4 2 Remote User Client Protocol 4 3 Ground Station Subtasks Real Time Operating System DL System Galls 2 002 Se eB ge a ea RG aI 5 2 Multitasking
121. factor for latitude is constant By knowing that the circumference of the Earth going through the poles is 40008 km 34 the conversion factor can be calculated 40008 diat 111 134k 9 36 lat 360 m The conversion factor for degrees of longitude is not constant though as the distance between two degrees will depend entirely on the latitude as illustrated on figure 9 14 Again by assuming that the Earth is a perfect sphere the distance between two consec utive degrees of longitude can be calculated using the following expression diong cos D A 9 37 where diong is the distance between two consecutive degrees of longitude m is the current latitude A is the distance between two degrees at the equator m The circumference of the Earth along the equator is 40075 16 km 34 and the value of A is given by 4 wl Ne 0075 16 111 320k a 320 km 9 38 2Note that this is assumed only for individual calculations as different values for circumference are used for latitude and longitude 79 Chapter 9 Feedback Control of Pan amp Tilt Platform Calculating Azimuth and Elevation Figure 9 15 An illustration of the angles that define azimuth and elevation With latitude and longitude converted into meters calculating azimuth and elevation is done by using trigonometry To ease the notation latitude longtitude and altitude are henceforth denoted by x y and z respectively Since azimuth can be def
122. ferent kinds of friction are illustrated on figure 8 5 Only the viscous friction is linearly depen Figure 8 5 Different types of friction in the ground station system dant of wm The other two types of friction introduces a non linearity into the system The stiction is only present when wm is zero and it will not be taken into account in the modelling of the platform The dry friction is constant and independent of the angular velocity and will be dealt with in the following Eq 8 4 expresses the total torque on the motor shaft Substituting the total friction torque Tf by a viscous friction component given by B wm and a dry friction component Te gives d J Ger Tm TL Te B wm 8 21 56 Section 8 4 Non linearity in Elevation Model where J is the moment of inertia kg m wm is the angular velocity of the motor e Tm s the torque applied by the motor Nm TL is the torque of the load Nm Te is the dry friction component Nm B is the viscous friction coefficient Rms The dry friction parameter accounts for both actual friction but also voltage drops in the H bridge used to supply the motors with power since this is a similar non linear effect To counter the effects of dry friction a voltage offset is added to all values applied to the motor The offset value is calculated using the following equation which calculates the voltage required for the motor to deliver a torque as large as Te The
123. function that takes an applied voltage as input and outputs the resulting position of the antenna te 0 s H s Vi s Such a model is necessary in order to design an efficient control scheme for the system The first section of this chapter gives an overview of all the components that are to be modelled This includes a description of how each component is modelled and what parameters are needed The following section describes how the individual parts of the model are combined and finally presents the transfer functions to be used for simulation of the physical components and for the design of a feedback control system Finally the output of the model is compared to the actual performance of the physical components for verification 8 1 Model Overview A sketch of the physical system to be modelled is shown in figure 8 1 on the following page The antenna platform consists of two parts e A tower structure that holds the entire construction The tower can be rotated 360 by a DC motor and determines the azimuth of the antenna e A small platform at the top of the tower on which the antenna is mounted The platform can be tilted back and forth by a DC motor and determines the elevation of the antenna The rotation is physically limited by the tower The DC motors are connected to their load through gears Each gear consists of two cogwheels and a belt that transfers torque from the motor to the part being rotated Since both
124. g at figure 8 2 on page 53 and acknowledging that the voltage across the motor coil is 0 V due to a constant current J is given by _ Vi Vemt La 8 33 8 33 V K Wm A m 8 34 i 8 34 Inserting the found expression into 8 32 we have V K wL N 0 PR KB ipo N aoe 8 35 In which the only unknowns are B and re By writing two equations using the sampled data both friction parameters can be determined 8 5 1 Azimuth Friction Parameters Two tests have been performed to determine azimuth parameters applying voltages of 4 and 6 V For calculating the velocity at 4 V the data points 0 8063 rad 1 552 sec and 0 8273 rad 1 592 sec have been chosen from the recorded CSV files where the position slope is constant By using eq 8 30 the angular velocity can be determined 0 8273 0 8063 _ rad 1 592 1 424 ers S05 Wav For the velocity at 6 V the following data points have been chosen 2 1450 rad 1 552 sec and 2 2026 rad 1 592 sec The velocity is then 2 2026 2 1450 rad 1 44 S 8 37 Vev 1 592 1 552 sec ea All known values are now inserted in 8 35 Keeping in mind that the sampled angular position is for the antenna and not the motor the velocities must be multiplied by the gear ratio _ 6 13 3 1073 1 75 14 8 9 0 Te 13 3 1073 B 0 524 14 8 9 Te 8 38 8 13 3 1078 288 14 8 9 0 o 433 1073 B 1 44 14 8
125. g the 3 Ethernet tasks 3 consecutive priorities so only one of them can execute at any given time and they thus can be considered as a single priority in this regard Priority Assignment When a TCP ACK package has been received the following events occur 1 encIrqHandlerTask is signalled by an ISR and takes the uIP semaphore as it enters the uIP critical region 108 Section 11 2 Scheduling 2 It processes the ACK package and ups the ethCt sSem on which the ethSenderTask is blocked in order to signal that a new TCP package can be sent 3 The encIrqHandler leaves the critical region and thereby ups the uIP semaphore It then blocks waiting for more input from the Ethernet controller 4 The ethSenderTask downs the ethCtsSem and then the ulP semaphore After doing its job the uIP semaphore is again upped The ethSenderTask is set to a lower priority than encIrqHandlerTask in or der to avoid three unnecessary context switches triggered by the events just stated If the ethSenderTask was higher priority context switches would occur when the ethCtsSem is upped by the encIrqHandler Then ethSenderTask would block on the uIP semaphore causing another context switch to encIrqHandler which won t do much more than upping the semaphore causing another context switch When ethSenderTask completes it s job it would generate another context switch to the encIrqHandler which then would block waiting for new Ethernet input The priori
126. g to gr503 lab es aau dk on port 8 2010 12 09 10 46 03 Connected 2010 12 09 10 46 03 Sending SetSatID package 129 with ID 13 2010 12 09 10 46 03 Sending GSCmds package 131 Operation 4 Manual Antenna Control 2010 12 09 10 46 03 Sending GSCmds package 131 Operation 5 Use P Controller 2010 12 09 10 46 03 Sending GSCmds package 131 Operation 9 Disable non linearity correction Figure 10 16 A typical example of the event log The RUC is connected to a server and has established the initial settings by sending several packages to the ground station 10 3 Threads In order for the RUC to receive data on the Ethernet connection keep the GUI running smoothly and be able to send packages two threads are needed as the receive loop will be blocking between received bytes One for receiving and handling the incoming packages and one to draw the GUI and send outgoing packages Until the user clicks the connect button the Java program is executed in one thread only This thread is the event dispatcher thread which is part of and started by the Swing GUI library 36 This thread is denoted as the view thread in the code comments When a connection needs to be established a new thread is started to execute the needed code for maintaining the connection and receive the data on the Ethernet link This thread is denoted the connection thread An illustration of this can be seen on figure 10 17 on the faci
127. ge of a command sent to the CanSat the canSatCmd object is informed This one forwards this information to the RUC Only one CanSat command can be enqueued for transmission at any given time thus the RUC should not allow the user to issue multiple CanSat commands 7 4 Verification Having designed the wireless communication it is now to be verified that this commu nication is working as desired The transmission of data from the ground station to the CanSat uplink is working well while transmission from the CanSat to the ground sta tion downlink doesn t work very well It has been tested how far uplink transmission is working as described in journal 1 on page 150 It is seen that a distances up to 260 m a reliable connection is always available independent of the orientation of the CanSat antenna When moving further away at least some packages can be transmitted de pending on orientation of the CanSat until a distance of 400 m is reached This is not as far as is required 1500 m so a better antenna or more powerful transceiver module is required For downlink it has not been possible to achieve a link that is usable in practice In the test of the downlink also described in journal 1 it was only possible to achieve an acceptable link at distances of up to 3m and then correct orientation of the CanSat antenna was required The orientation where transmission is possible is when the an tenna is held horizontally which is
128. gh tests done on the system The inertia parameters have been roughly determined by direct measurements of the dimensions and weight of the moving parts and so these values cannot be assumed accurate and must be verified first The friction parameters can be determined by observing how the system performs when a constant voltage is applied This has been done in a set of tests all described in Test 2 and 3 of journal 3 on page 155 Method for Determination of Parameters The data that s been sampled is position data so the velocity must be found by differen tiation By observing where the slope of the position curve is constant and selecting two consecutive values of position and the corresponding time the angular velocity is found by P2 P wL aes 8 30 where pi is the first position value rad p is the second position value rad ti is the first time value s to is the second time value 58 Section 8 5 Parameter Determination and Model Verification Note that wy is the angular velocity measured after the gear and is thus 4 where N is the ratio of the internal and external gears combined To minimize quantization errors due to the limited resolution of the data the values are chosen 5 samples apart from each other instead of 1 If the velocity is constant the acceleration is 0m s2 and the terms 4w and Tr vanish dt from eq 8 21 It thus reduces to eee 8 31 I K B wm Te 8 32 By lookin
129. gher priority than IRQ s and can preempt these The IRQ s are also prioritized but cannot preempt each other The lower the IRQ number the higher priority encoderElevationISR is guaranteed to meet it s deadline as it has the highest priority and can preempt other tasks The remaining IRQ s cannot preempt each other and may have to wait for any of the other interrupts to complete before it can execute Table 11 3 shows the ISRs and their worst case completion time relative to their ready time The encoderAzimuthISR may not meet its deadline because it may wait for up to 112 8 us before executing if the rfmIrqHandler and encoderElevationISR are triggered at the same time This problem could have been solved by having it run as a FIQ as well sharing this status with encoderElevationISR This has not been possible due to some problems implementing both ISRs as FIQ s in the vectorized interrupt controller VIC of the LPC2138 microcontroller It is noted that the interarrival time for the encoder interrupts are a theoretical worst case value based on the angular velocity for the motors when no load is applied to them This is not the case in practice and the interarrival time will thus be higher in reality even if the antenna is rotating at full speed Also the computation time for the rfmIrqHandler is a worst case value that only appears when a stop byte is received Upon reception or transmission of a regular byte in a package computation t
130. h means the calling task will be additionally blocked if another object is using the object Data flow between objects is represented by an arrow O gt labeled with a brief de scription of the data There exists rules concerning which object types can include which objects and which relations can exist between each object type for more info see 13 4 3 3 Decomposition of Ground Station Software into Objects The ground station system basically has three natural objects e Control the position of the antenna based on either GPS data from the CanSat or a manual specification of the position from the user e Handle the data received from the CanSat and send commands to it based on the specifications in the WARP protocol e Handle the TCP IP Ethernet connection to the RUC which basically means im plementing a stack of handlers for the protocol layers used by the link o Interface to the ENC28j60 Ethernet controller and handle Ethernet level pack ages o Handle the TCP amp IP protocol layers o Receive and send packages in compliance with the RUC protocol These 3 objects are shown in figure 4 3 They are all active objects that thus can be broken down into a number of smaller objects It can be seen that sending a package on the RF CanSat link or to the RUC through Ethernet is done as asynchronous execution requests ie the transmission of the package is queued and then performed whenever the link is ready for the transmis
131. hat is applied to the rotor by the load in this case either the antenna or the entire tower via the gears The physical parameters of the antenna platform have all been calculated from mea surements made on the platform All measurements and calculations can be found in Test 1 of journal 3 on page 155 The relevant parameters are shown in table 8 2 Property Symbol Value Unit Antenna inertia Ja 11 3 1078 kg m Elevation gear ratio Na 46 1 Total platform inertia diok 18 5 1078 kg m Azimuth gear ratio Naz 8 9 1 Table 8 2 Antenna platform parameters 8 2 Combining the Model In the following a complete model that express the position of the antenna in terms of the motor input voltage is derived The derivation is true in general and thus valid for both azimuth and elevation The first step in combining the elements of the model is to Laplace transform the equations involved This is done to both ease calculations and to eventually allow frequency domain analysis of the system Transforming equations 8 2 and 8 4 yields Vi s Ials Ra 8 La Ials K wn s 8 13 8 Jm Wm s K Ials Tr B wm s The effect of the inductance La can be examined by comparing the electrical and me chanical time constants The mechanical is given by 27 1 msec 29 and will be even higher when the motors are loaded The electrical time constant can be calculated by La _ 0 372 107 1 2 1 a 3 65 02 usec 8 15
132. he fact that the CanSats can only transmit a very weak radio signal because they can only contain small antennas Also they run on small batteries and maximum transmission power is specified by government regulations These government regulations are investigated further in section 7 on page 45 This directional antenna must thus be pointed in the direction of the CanSat at all times during flight It has been chosen that this ground station system must have the following functionalities e Ability to automatically point the antenna at the CanSat and track it as it moves e Ability to receive the wireless data from the CanSat namely telemetry data mea sured from onboard sensors and transmit them in realtime to a computer located elsewhere This transmission is done via an internet connection The receiving computer is henceforth referred to as the remote user client or just RUC e Facilitate control of the ground station from the remote user client An overview of the project content can be seen on figure 2 1 CanSat a ti Embedded System aa Antenna Network Ground Station Remote User Client Figure 2 1 This figure illustrates the CanSat Ground Station and Remote User Client The project is limited to the objects contained within the boxes Note that the construction and design of the CanSat and the network between the ground station and the remote user client is not part of thi
133. he force F is resolved into two components F and F gt that are perpendicular to each other F will always point towards the axis so this force will never affect the rotation of the antenna It might affect friction but this effect is neglected F gt on the other hand will result in a torque on the rotation axis and it s value must therefore be determined This torque is non linear and depends on the position of the antenna By looking at the figure the following expression can be written F cos 4 gt F cos 9 Fg 8 25 g Since F and Fp are perpendicular it follows that 4 90 0 and exploiting that sin 9 cos 90 0 F gt can be written as F gt sin 0 Fy 8 26 The torque can be found by multiplying with the distance from center of mass to the axis Because the torque is applied at the load though it must be divided by N the combined gear ratio to find the necessary motor torque F3 d 2 Tg N 8 7 Substituting all known values the final expression is given by Tg sin 0 0 388 9 82 0 05 8 28 sin 9 0 190 8 29 This is thus a non linear torque that will affect the model for elevation Now that the value of the torque is known it can be taken into account in the control system 8 5 Parameter Determination and Model Verification Since some parameters in the model namely inertia and friction are difficult to measure directly it is necessary to determine these throu
134. his purpose uipSem is used To prevent deadlocks no blocking calls are made within the critical region protected by uipSem 6 3 3 Queueing and Assembling of RUC Packages The ethernetSend operation request is an asynchronous execution request This can be accomplished in practice by the use of a queue that contains the outgoing pack ages To avoid a lot of data copying only pointers to the packages are written into the queue This requires a memory allocation system so that the Ethernet communi cation module can free the memory used by the packages when the packages have been successfully sent A simple memory allocation system has been implemented in the file helper c 80 buffers with the fixed size of 158 bytes which is the maximum length of a RUC package has been statically allocated A pointer to each buffer is put into a queue bufFreeQ A buffer is dynamically allocated by reading out a pointer from the queue and freed by writing it back This system is fast simple and generates no memory fragmentation The disadvantage is that it becomes memory inefficient when sending a lot of small packages Note that the allocation system is only used for packages When the ethSenderTask shown in figure 6 4 manages to trigger an appcall several RUC protocol packages may be queued up in the Ethernet queue Each RUC package can be small in size and it would be inefficient to send an Ethernet packet for each RUC packet In the appcall the
135. iB flash ROM e Usual microcontroller features 6 x PWM 2 x SPI 2 x 12C 2x UART ADC DAC and Timer Counter all with various interrupt possibilities e Debugging and programming over JTAG For wireless communication with the CanSat the RFM12B 11 12 transceiver is used more details can be found in chapter 7 on page 45 23 Chapter 4 Modularization ARM development board Bipom Mini Max ARM E RS232 port for errors 8 warnings JTAG programming 8 debugging Microcontroller NXP LPC2138 CPU core ARM7TDMI he WARP Protocol PWM Signals for actuators through motor driver SPIO Ethernet controller Microchip ENC28j60 Motor encoder giving antenna rotation information SPH RF Transceiver RFM12B Ethernet Internet RUC Protocol system can be seen in appendix G on page 146 4 2 Remote User Client Protocol Remote User Client Figure 4 1 Overview of the hardware used in the system A full list of utilized hardware a total schematic and the physical construction of the All user interaction with the ground station is done through the remote user client The communication between the ground station and the RUC is done over a TCP IP connection On top of this TCP IP connection an application level protocol must be defined this protocol will be referred to as the RUC protocol 4 2 1 Information to
136. ic pressure and a Signed Integer labelled Wind speed The drop down boxes seen in figure 10 5 allows the user to choose between several data types The text fields allows the user to label the data The add button adds another data box and the remove button removes the most recently added data box Once a connection is established the buttons and text fields seen in picture 10 5 will be grayed out Once the data is received it will be written to the data log Here the names of each data type will match the names given by the user as seen in figure 10 6 on the following page 95 Chapter 10 Remote User Client File Help Configuration Ground Station Control Event Log Data Log Data Log time ms gpsheigh gpslongit gpslongit gpslongit gpslongit gpslatitu gpslatitu gpslatitu gpslatitu Temperat Atmosph Wind speed 65258 9999 E 100 22 1111 90 33 1111 les 0 1094795585 65259 9999 E 10 faz 1111 i o s mm es o 1094795585 165260 9999 E 100 22 1111 IN so 33 1111 l6s 0 1094795585 65261 9999 E 100 22 1111 so 33 1111 l6s 0 1094795585 65262 19999 E 100 22 1111 A 190 33 1111 les o 1094795585 Figure 10 6 Illustration of the data log in the GUI Expected data is set to the following Signed Byte labelled Temperature Unsigned Short labelled Atmospheric pressure and a Signed Integer labelled Wind speed Notice this data log is specif
137. ication is passed 10 6 Further Development Some features have been left out of the RUC due to time and resource limitations These would have been added if further development was to be done and are as follows e 2D and 3D graphs to illustrate received CanSat telemetry in order to allow the user of the RUC to gain a better understanding of the data These graphs should be updated whenever new telemetry is available to allow live interpretation by the user e A tool would be made to allow user customization of the graphs e Extended save load options would be implemented so that the user could simulate the flight of a CanSat from captured data Summary In this chapter the RUC was designed as a multi threaded Java based GUI program The finished RUC is capable of establishing a TCP IP based connection to a server adhering to the RUC protocol retrieve and send data using this connection displaying 103 Chapter 10 Remote User Client retrieved data and saving these to CSV files From this it is concluded that the RUC meets all RUC specific requirements 104 CHAPTER Scheduling of Ground Station Software Design and implementation of all the modules identified in the modularization chapter has been discussed This chapter looks into how these modules are put together The main concern is the integration of the ground station software since these modules are coupled together through their software interfaces a
138. ied as conformance class 2 As a result GPS data is added The check box seen on figure 10 6 enables auto scroll This enables automatic scrolling to the most recent data in the table whenever new telemetry data is received The received data is also written to a CSV file This includes the GPS data if conformance class 2 is specified New information will be written to the CSV file whenever a package type 0 is received Doing so ensures the data is saved if the RUC should crash and also allows easy data extraction as CSV is a well established format Inside the CSV file the data types will be labelled as to match the labels written in the GUI The location of this CSV file is chosen by the user in a dialog box before a connection is established An example of such a CSV file can be seen in figure 10 7 Temperature Atmospheric pressure Wind speed 65 0 1094795585 65 0 1094795585 65 0 1094795585 65 0 1094795585 65 0 1094795585 Figure 10 7 Snapshot of a data CSV file example Expected data is set to the following Signed Byte labelled Temperature Unsigned Short labelled Atmospheric pressure and a Signed Integer labelled Wind speed A CSV file containing the Azimuth and Elevation information described in sec tion 10 13 on page 98 will also be created together with the data CSV file This CSV file will be placed in the same directory as the data CSV file with the text RegInfo added to its filename Information written to this CSV fil
139. ifferent frequency multiple pairs of RFM12B can be 45 Chapter 7 RF Communication with CanSat connected without disturbing each other The maximum allowed transmission output of the specified frequency span is limited to 25 mW effective radiated power 25 by danish government regulation The RFM12B have a maximum output power of 7dBm 5mW 12 Since the effective radiated power cannot become larger than this the law is thus obeyed The RFM12B can be used at different bitrates up to 125 kbit per second The higher the bitrate the higher demand is set to the quality of the link On the basis of this the bitrate has been chosen to 19 2kbit s It is noted that at 19 2kbit s the longest possible WARP package of 302 bytes including control characters escape start and stopbytes will take the following time to transmit _ 302 byte 8 bit byte t ooops 7 125 8ms 7 1 This allows for a whole package to be transmitted between the time a new package are ready for transmission which is every 200ms There might be problems if multiple CanSats are airborne at the same time though This can be solved by having each CanSat ground station pair use a different frequency band within the 868 MHz band For this project these specific frequency settings are used e Carrier frequency 860 32 MHz e FSK frequency variation dffsk 90 kHz The groups who are building CanSats for use with the ground station uses the same RF transce
140. ill be buffered up and the ethSenderTask will send maximum sized TCP segments Thus in the worst case scenario high load the ethSenderTask will converge towards the highest throughput sending scheme maximum sized segments Sending more and smaller TCP segments will generate more TCP ACK packets which decreases the interarrival time of the encIrqHandlerTask The interarrival time of the encIrqHandlerTask can be close to zero since the Ethernet controller will buffer up incoming packets and keep on generating interrupt requests as long as there are unprocessed packets in the buffer Furthermore the amount of traffic on the Ethernet caused by ARP Address Resolution Protocol ICMP Internet Control Message Proto col etc are unknown Because of the nondeterministic behavior of the Ethernet module it is preferred to assign its tasks low priorities to ensure the rest of the ground station system is working independently of the behavior of the Ethernet tasks All three Ethernet tasks are acquiring the uIP semaphore as long as they are ex ecuting This will make the tasks wait for each other s completion In addition the ethSenderTask will be blocked waiting for the encIrqHandlerTask to up the ethCtsSem Clear to Send semaphore which happens on a new connection and on the arrival of TCP ACKs Priority inversion may occur because no priority inheritance mechanism exists in the operating system Priority inversion can be avoided by assign in
141. ime is maximally 38 us as shown in journal 5 This decreases the severity of the IRQ problem but it should be noted that the measured azimuth position in theory may drift because of the risk of missing interrupts ISR Delayed by in worst case Completion time us Tal ys encoderElevationISR None 2 8 15 encoderAzimuthISR rfmIrqHandler 110 2 8 3 7 116 5 15 encoderElevationISR r mIrgHandler encIrqHandler 22 1 2 2 8 3 7 110 141 4 417 2 encoderElevationISR encoderAzimuthISR encIrqHandler rfmIrqHandler 2 2 8 2 3 7 110 22 1 145 1 1000 2 encoderElevationISR 2 encoderAzimuthISR Table 11 3 Worst case completion time for each ISR relative to its ready time The completion time is composed of the total computation of the blocking ISRs plus the computation time of the ISR itself Having shown that the scheduling of interrupts is acceptable except for 112 Section 11 2 Scheduling encoderAzimuthISR the interrupts can be excluded from the scheduling analysis To do this all the remaining tasks computation times are multiplied by a factor to account for the time the CPU will spend servicing the interrupts This can be done because the interrupts occur very often compared to the remaining tasks except for encIrqHandler but this fact is neglected in this analysis as it s computation time is very low compared to the remaining tasks The CPU utilization by the interrupts alone ca
142. implementation of a full TCP IP protocol stack is outside the scope 37 Chapter 6 Wired Communication with Remote User Client Sat Data TCP TCP Transport Data IP IP Internet Header Data Application 2 SSS oe ie A Ethernet Ethernet Ethernet Link Header Data Footer Figure 6 1 TCP IP Layer Model and the corresponding encapsulation of application data The grey boxes are provided by the uIP library and the dashed boxes are provided by the Ethernet controller of this project Instead the open source TCP IP stack called uIP has been ported to the platform The library supports IPv4 and ARP Address Resolution Protocol and is designed for embedded microcontrollers See the author s homepage 20 for detailed documentation This library provides the boxes marked with grey in figure 6 1 The Ethernet module software is structured into several tasks within ARTOS In the follow ing sections the design considerations around the Ethernet communication module are discussed 6 2 Ethernet Controller The ENC28J60 Ethernet controller provides the MAC sublayer as well as a 10Base T physical layer Instead of going through all the technical internal details of the chip and the procedure for setting up the 128 internal registers only the important features will be outlined here The details can be found in the datasheet 21 The most important features are e Supports full and half duplex modes configured for half duplex
143. ined as the angle between the ground station and the satellite on the horizontal plane as seen on 9 15 it can be calculated by az arccos 9 39 2 y Elevation can be defined as the angle between the ground station and the satellite on a vertical plane that contains both points The angle can be calculated by Z el arcsin 9 40 VT Y Calculation Example The following example shows how a conversion is done using real coordinates The ground station and satellite positions are given by the following GPS coordinates and the goal is to calculate the azimuth and elevation that points the antenna at the satellite Ground station latitude 56 59 9243 N longitude 9 57 0225 E altitude 0 CanSat latitude 57 0 1404 N longitude 9 56 8074 E altitude 400 m 80 Section 9 3 Implementation The first step is to combine degrees and minutes 59 9243 Bian 56 y 56 998738 9 41 57 0225 ESlong 9 950375 9 42 0 1404 sabias 57 57 002340 9 43 56 8074 sationg 9 9 946790 9 44 Next the conversion factor for longitude is found using eq 9 37 The ground station is used as reference diong cos 56 998738 111320 60630 m 9 45 The degrees can now be converted to meters 2S 56 998738 111134 6334 497m 9 46 ZStong 9 950375 60630 603 291 m 9 47 satiat 57 002340 111134 6 334898 m 9 48 sationg 9 946790
144. information is seen below where comments are used to give further description The packages that go from the ground station to the RUC are listed below the structs describe the contents in the pkgContents field 135 Appendix C RUC Protocol Specification struct pkgSatData uint32_t timestamp Milliseconds since some arbitrary reference time x uint8_t flags Bit0 1 if CRC mismatch 0 otherwise struct pkgWarp warp A type0 WARP package excluding start stop and escape bytes 5 struct pkgControlInfo int16_t currentAzimuth 1 10 degree 0 is north int16_t currentElevation 1 10 degree 0 is vertical int16_t wantedAzimuth 1 10 degree 0 is north int16_t wantedElevation 1 10 degree 0 i vertical uint32_t timestamp Milliseconds since some arbitrary reference time y The packages that go from the RUC to the ground station are struct pkgManualAntennaCtrl int16_t azimuth 1 10 degree 0 i vertical int16_t elevation 1 10 degree 0 is north struct pkgSetSatld uint8_t satld CanSat ID of CanSat to use struct pkgSetManualLocation struct gpsData gps GPS data giving location of ground station This is a string with the same format as GPS data in the WARP protocol x Ground station commands sent from PC define CMD_CALIBRATE 0 define CMD_AUTO_CONTROL 1 define CMD_GET_SAVED_DATA 3
145. ing as a byte stream There are two conformance classes for the protocol Conformance class 1 is the simplest and facilitates transmission of measured telemetry data from the CanSat to a ground station Conformance class 2 is a superset of the specifications for class 1 Class 2 devices facilitates the use of a ground station that automatically can track the CanSat with it s antenna using GPS coordinates Class 2 thus defines a way to include GPS coordinates in the data being sent from the CanSat to the ground station Furthermore there are some timing restrictions to ensure that the ground station have adequate recent GPS coordinates at all times The protocol defines 2 package types that each accomplish a different task Not all devices has to implement all package types they can choose to ignore package types that provide features that are not wanted in that application The protocol gives the possibility to create 14 custom package types that can be utilised as desired The following are basic specifications set by the protocol e All multi byte values are sent as little endian e All signed numbers are in the two s complement format e The protocol uses 0xBE as a start byte and OxEF as a stop byte to delimit packages Any occurrences of these two bytes in the package header or payload must thus be escaped using byte stuffing As escape character 0x42 has been arbitrarily chosen Occurrences of this byte must thus also be escap
146. iods in the PWM signal are equal R 9 35 1 5 wee where f is the PWM frequency Hz R is the motors internal resistance 9 Lis the motors internal inductance H P is the maximum current deviation The values for the motor parameters R and L are known from section 8 1 2 on page 52 Because the resistance in the MOSFETS driving the motors are much smaller than the resistances inside the motors these can be neglected The frequency can then be calcu lated by choosing a value for P A plot of allowable deviation and PWM frequency can be seen in figure 9 13 A table with selected P values can be seen in table 9 3 2 on the next page PWM frequency Hz 0 i i L ji 0 5 10 15 20 25 30 35 40 Allowable deviation Figure 9 13 The figure illustrates PWM frequency as a function of current deviation in percentage The PWM frequency has been chosen to 120kHz which gives a deviation of 4 lIt is chosen not to derive the expression in the rapport but refer to 33 instead 77 Chapter 9 Feedback Control of Pan amp Tilt Platform Percentage PWM frequency 1 488 1 kHz 5 95 6 kHz 10 46 6 kHz 20 21 9 kHz 40 9 6 kHz 60 5 4kHz 80 3 0 kHz Table 9 1 Current deviation in percentage at different PWM frequencies 9 3 3 Conversion of GPS data When the ground station successfully receives a package containing a set of GPS coor dinates it must be able to translate this into a
147. is command was send relatively fast he might think the try was unsuccessful and try again However the command or the acknowledge thereof may just be stored somewhere in the network and the user ends up having sent a number of commands even though he only wanted to send one Therefore it has been chosen that once a CanSat command has been sent another one cannot be sent until the first one has been acknowledged This also simplifies the protocol since the CanSat command acknowledge sent from the Section 4 3 Ground Station Subtasks ground station to the RUC will always be an acknowledge of the last command sent These considerations have been part of the base from which the protocol has been designed 4 2 4 Protocol Outline The RUC protocol uses one way messages ie when sending a message there is no direct reply message As described above this is acceptable also with large network latencies TCP provides a byte stream ie it does not preserve package boundaries so the RUC protocol must provide a way to distinguish messages from each other in the byte stream For this each message is put into a package and each package is started by a start byte and then followed by a length field specifying the length of the package Occurrences of the start byte in the package are escaped using byte stuffing No checksum is used since TCP guarantees data integrity The details of the RUC protocol can be found in appendix C on page 135
148. is created rucspam c which connects to the ground station and sends a RUC package of the type pkgSetManualLocation which is the RUC package requiring most processing because of the conversion of GPS coordinates The execution is read out on the oscilloscope 36 controllerTask The cont rollertTask is upped to the highest priority and IO toggling is assigned to this periodic task The remote user client connects to the ground station and applies the lead controller and the non linearity correction feature which requires most execution time for the controllerTask 37 rfmPkgHandler The rfmPkgHandler task is upped to the highest priority and IO tog gling is assigned to this task The Arduino based CanSat stand in is programmed with the software found on the cd This program sends maximum sized 150 bytes WARP packages to the ground station with fake telemetry data The time processing time spent by the rfmPkgHandler is read out on the oscilloscope 39 rfmIrqHandler The Arduino based CanSat stand in is used as in the test of rfmPkgHandler The IO toggling is added in the rfmIrqHandler The han dler receives bytes from the CanSat There is an execution time difference be tween receiving the normal bytes of a package and receiving the last byte The last byte requires more processing because the package must be passed on to the rfmPkgHandler via a queue Both execution times are noted Another test is made by setting the rfmIrq
149. is example the data is a new elevation angle for the antenna controller so the application sets a global variable in the controller and returns control to uIP 5 Back in the uip_input function a TCP ACK packet is now written into uip_buf and uip_len is set to the length of the new package uIP returns to the main loop 6 The main loop checks the uip_len variable which is non zero thus a call to encTransmitPacket is made 7 The TCP ACK packet is copied to the Ethernet controller and send The call graph for this particular example is shown in figure 6 3 on the facing page Note however that an invocation of uip_input not necessarily generates an invocation of the application function appcall e g if the incoming IP packet was an ICMP Internet Control Message Protocol packet used for Pinging 6 3 2 Structuring into Tasks Instead of using the mainloop polling reference implementation just mentioned the uIP processing is structured into three different tasks The processing of incoming Ethernet frames from the Ethernet controller can be put into a task of its own The task will be sporadic and triggered by the interrupt output of the Ethernet controller The task is named encIrqHandlerTask and is shown in HRT HOOD diagram in figure 6 4 on the next page The task is synchronized with the interrupt service routine through a semaphore encIrqSyncSem The main loop in the uIP example main loop has one more operation to do It peri o
150. is interface allows access to eight different classes capable of interpreting data into several types and storing them The following classes implements the interface FloatType SignedByte SignedShort SignedInt StringType UnsignedByte UnsignedShort and UnsignedInt After the interpretation data is stored in an array list The Type interface is able to extract information from this array list as well Notice that the user specified names for each data type is stored within each instance of the data types The names can also be extracted through the Type in terface The structure of the interface can be seen illustrated through the use of a class diagram on figure 10 2 on the facing page A class diagram of the RUC can be seen on figure 10 3 on page 94 For simplification some attributes and methods are not included in the diagram and some encapsulates 92 Section 10 2 User Interface and Functionalities GroundstationData FloatType SignedByte SignedShort Signedint StringType UnisgnedByte UnsignedShort UnsignedInt data ArrayList lt Float gt data ArrayList lt Byte gt description StringType description StringType Y al fee z floatType signedByte Bey lt lt interface gt gt Type addData ByteBuffer safeGetData int safeGetDescription Figure 10 2 Class diagram showing the interface named Type N
151. is protocol has been specified as well which allows for the RUC and ground station to be developed in parallel 30 CHAPTER Real Time Operating System To implement the system described in chapter 4 a real time multi tasking operating sys tem is required Real time means the ability to fulfill strict timing demands e g reacting to incoming events before a certain deadline A multi tasking environment introduces con current execution of different tasks from the programmer s point of view which supports the HRT HOOD design paradigm well This chapter regards the design and implemen tation of the operating system tailored for this project Overall the system must have the following features e Concurrent pseudo parallel execution of several prioritized tasks e Synchronization and message passing between tasks e Scheduling and execution of periodic tasks The operating system in this project is dubbed ARTOS which is an acronym of ARM Real Time Operating System Throughout this chapter the design and inner workings of ARTOS will be discussed The chapter ends with a verification test of the operating system s functionality 5 1 System Calls System calls or syscalls represents the interface between user programs and the operat ing system In ARTOS there are 14 different system calls which are shown in table 5 1 on the next page These are supposed to give an overview of the different features of the OS The prototypes for
152. is the main method used throughout the RUC to ensure correct program execution Methods using SwingUtilities invokeLater will be denoted with the name safe in front An example of such a method could be safeSetConnectionStatusLabel In some cases the event dispatch thread might use the SwingUtilities invokeLater method on itself This is acceptable as this will simply add the task to the end of the event dispatch threads queue 37 As mentioned briefly the two threads are each responsible for different tasks The connection thread establishes the Ethernet connection handles incoming packages pro cesses these and writes them to the CSV files The event dispatch thread updates and responds to the GUI creates the CSV files writes the initial information in the CSV files handles outgoing packages and starts and stops the connection thread when needed The connection thread is started and stopped when a connection is established and closed Dividing the work like so allows the GUI to stay responsive during the operation of the RUC 10 4 Receive and Send Methods One of the basic and important features of the RUC is the processing of packages from the Ethernet network These packages hold valuable information regarding the CanSat and GS alike Because the RUC protocol is a level above the TCP protocol the first order of business is to interface to the ground station through the TCP protocol As the RUC is written in Java a
153. istic if all it s ready times are known at time 0 Tasks are categorized as hard real time if the deadlines must never be missed and soft real time if the deadlines are specified on a mean value basis and can be missed from time to time In this chapter all tasks will be regarded as hard real time 11 2 1 Ethernet tasks There are three tasks in the ground station system dealing with Ethernet handling as described in chapter 6 The tasks are listed in table 11 1 and the reason for the assign ment of priorities will be described in this section The three tasks are highly dependent Priority Task name Type 3 uipPeriodicTask Cyclic 2 encIrqHandlerTask Sporadic 1 ethSenderTask Sporadic Table 11 1 The three tasks of the Ethernet communication software Higher priority number means higher priority on one another and are coupled through the use of semaphores for mutual exclusion and synchronization Furthermore the interarrival time of the sporadic tasks depends on the time given to these tasks by the CPU as well as the round trip time of the Ethernet link For example the ethSenderTask can send up to 510 TCP data bytes when it is invoked but if less data is available in the Ethernet out queue it will be sent imme diately Sending the RUC packages in small TCP segments requires more computation time per amount of sent data because of the encapsulation overhead of sending TCP data If the system is under heavy load the outgoing packages w
154. iver module They have chosen to use a whip antenna consisting of a piece of wire a quarter wavelength long As will be investigated below a directional antenna is needed to be able to receive the signal from the CanSat as this is fairly low power For this a Yagi Uda style antenna with 6 elements is used 26 27 7 2 Link Budget To determine the range available in this setup a link budget is calculated This link bud get calculates the available range by considering how much of the power emitted by the transmitting antenna which can be collected by the receiving antenna If the antenna is isotropic it emits an electro magnetic field EM field that propagates spherically in all directions Therefore the EM field power density available for an receiving antenna decreases by the square of the distance between the antennas The danish radio engineer Harald T Friis formulated this in what has become known as Friis transmission equa tion The equation can be found in 28 pp 95 Assuming impedance and polarization matching and neglecting losses in antennas it reduces to P aV 2 02 where P is the power delivered to the load at the receiving antenna terminals W P is the power delivered at the transmitting antenna terminals W G is the gain of the transmitting antenna compared to an isotropic an dBi tenna Gr is the gain of the receiving antenna compared to an isotropic antenna dBi A is the wavelength m R is the distanc
155. kernel and RFM12B driver code developed by group 502 Used Equipment Instrument AAU No Make and type CanSat stand in Arduino Mini Pro w RFM12B and 8 63 cm wire whip antenna See appendix F on page 145 Table 1 1 Equipment used in the test 1 3 Approach A different approach is used for the uplink and the downlink tests because these act very differently in practice The transmission link quality is sensitive to the orientation of the transmitter and receiver For the uplink two distances are determined e The maximum distance where an error free link is available independent of the orientation of receiver transmitter e The maximum distance where it is not possible to successfully transmit even a single package This test doesn t make much sense for the downlink connection as reception on the ground station is very bad Therefore it is here examined how the connection quality varies at different distances and orientations This is done by taking measurements of how large a percentage of packages can be successfully transferred at different distances and orientations The measurement of the distances are not required to be of high accuracy since the range cannot be precisely determined It is highly dependent on the surroundings where the measurements are taken Therefore measurement of the distance is done by noting landmarks during the measurement and then using Google Maps to measure the distance 150 Journa
156. l 1 Range Test of RF Communication 1 4 Uplink Test The uplink test is performed in the way described below An acceptable connection is understood to be a connection where 10 consecutive packages are transferred without errors 1 The ground station is programmed with the software found at 0 8 with the patch 61 applied This software transmits this package once every second static uint8_t buf 0x0d 0x00 0x00 Oxab Oxcd Oxef Oxab 0x00 0x12 0x34 0x56 0x78 Ox9a Oxbc Oxde Oxff Oxed Oxcb Oxa9 0x87 Oxeb 2 The arduino mini pro is programmed with the software found at 2 This software echoes all received packages on it s serial port at baud 115200 The package contents printed on this serial port is compared to the package specified above to verify if it s contents is correct 3 Let the ground stations antenna point in a direction where it is possible to walk far while still keeping a clear line of sight to the ground station 4 With a laptop connected to the arduino s serial port walk away from the ground station Keep a clear line of sight to the ground station Walk further away until an error free package is not received 5 Walk closer to the ground station until it is not possible to rotate the RFM12B antenna in such a way that the connection is not acceptable anymore see definition above 6 Note some landmark nearby for later length measurement on Google Maps 7 Continue walking furth
157. lculated from eq 11 4 is 37 2 The computation time of the remaining tasks are thus to be multiplied by 1 372 Regular Tasks Taking into account that the computation times are increased by 37 2 the fixed priority scheduler will give the result in figure 11 2 if all tasks have their ready times at time t 0 In the figure deadlines are shown as a small vertical line e g it can be seen that uipPeriodicTask and encIrqHandlerTask tasks have their deadlines at 50 ms Execution of a tasks is shown as a fat black line The CPU is able to handle the load and completes execution of all tasks before their deadline As it is the worst case scenario that all tasks have their ready time at the same time instant it has thus been shown that the chosen prioritization of tasks is feasible and all deadlines will be met controllerTask IH E E E E E E rfmPkgHandler i l J uipPeriodicTask ME el enclrqHandlerTask a J ethSenderTask 50 E IA copada dol i i L i i i i L i i 0 5 10 15 20 25 30 35 40 45 50 55 Time ms Figure 11 2 Scheduling of tasks with deadline monotonic assignment Effect of uIP Mutex The above analysis does not take into account the effect of the 3 Ethernet tasks executing under mutual exclusion This effectively means that they can be forced to wait for each other before they are scheduled The ethSenderTask are the lowest priority and it has thus already been forced to wait for the rem
158. ll return immediately and the caller must determine from the return value if the write was successful Returns O if write was successful and a value has been written to the queue nonzero if the queue was full and no write operation has been performed uint32_t osQueueWriteFromlsr struct queue queue void dataSource 141 Appendix E ARTOS Function Prototypes Writes one value to a queue in a FIFO manner Parameters queue A pointer to the queue to write to dataSource A pointer to the memory where the value to be written is read from Returns 0 if action was performed successfully no rescheduling is required 1 if rescheduling is required i e a task with higher priority than currentTask was unblocked 2 if action could not be performed since queue was full Definition at line 376 of file os c void osSemDown struct semaphore sem Decreases the semaphore value by one Blocks the caller if the semaphore is already zero Parameters sem A pointer to the semaphore to be downed void osSemiInit struct semaphore sem uint32_t initialValue Initializes a semaphore struct with the given value Parameters sem A pointer to the semaphore struct to be initialized initialValue The starting value of the semaphore Definition at line 226 of file os c void osSemUp struct semaphore sem Increase the semaphore value by one If a higher priority task is currently blocked by the semaphore res
159. lysed as if they were cyclic Computation time c is the total execution time of the task under the assumption that it is the only task running Starting time is the instant in time where the task first gets to run Completion time is the instant in time where the task is done executing Deadline is the instant in time where the task has to be finished Relative deadlines t are assigned to tasks which is the difference between the ready time and the deadline 106 Section 11 2 Scheduling A RF Link amp WARP handler gt RFM12B Byte to send pawar ASER sendCanSatCmd Cmd number rfmirqHandler chip ASER_BY_IT stat lt 40 HSER r mSend_ lt Received byte e canSatCmd VARIP amel eke i WARP package HSER enqueueCanSatCmd lt HSER cmdAckReceived S r mPkgHandler HSER getUnackedCmd E 4 CanSat WARP cmd pkg cmd number J we CmdAcknowledge package y 40 RUC SatData package A Ethernet RUC protocol N enclrqHandlerTask ASER ethernetSend RUE 2 3 ethernetSend _ pkg Out La ASER_BY_IT start lt J l ethSenderTask Y C uipP
160. mmands consists of a number between 0 and 255 Since the function of each CanSat command is unspecified in the RUC protocol layer see appendix C on page 135 and thus interpreted individually by each CanSat these commands will simply be typed into a text field To send a CanSat Command the user must click the send button Upon clicking this button a package type 131 containing the CanSat command is sent As a way to keep the user from sending CanSat Commands before a connection to the ground station is established the text field and send button will be grayed out as long as the RUC remains disconnected Because CanSat commands must be acknowledged by the CanSat the send button and text field are also grayed out until an acknowledge package RUC protocol package type 2 is received as specified in the RUC protocol This is done to ensure that all CanSat commands are received and to keep the user from flooding the radio link from the ground station to the CanSat Furthermore a status label is placed above the text box to inform the user of the current acknowledge status An illustration of these functionalities can be seen on figures 10 10 on the following page 10 11 on the next page and 10 12 on the following page 97 Chapter 10 Remote User Client Status OK to Send CanSat Commands Send Figure 10 10 No Ethernet connection established Send button and text field grayed out Status OK to Send CanSat Commands Send Figure 10 1
161. model of how the system behaves The DC motors used in the system setup are both A Max 110949 29 with a built in planetary gear head order nr 144029 30 Data sheet parameters for motors and gear are shown in table 8 1 Property Symbol Value Unit Torque constant K 13 3 1073 Na Terminal resistance Ra 3 65 Q Terminal inductance La 0 372 1079 H Rotor inertia Jig 1 32 107 ke m Gearhead inertia Js 5 1076 kg m Gear ratio N 14 1 Table 8 1 Motor and gear parameters 53 Chapter 8 Modelling of Pan amp Tilt Platform 8 1 3 Antenna platform Top view Side view Platform motor Figure 8 4 A side and top view of the antenna platform showing what parts are rotated by the motors Fm illustrates the force that affect the belt The antenna platform is essentially the load of the DC motors and thus determines the value of Tz Since the azimuth and elevation axis are rotated independently different parts of the platform will act as load for each motor This is illustrated in figure 8 4 It can be seen that the relationship between the radii of the cogwheels determines the gear ratio from shaft to load The ratios for azimuth and elevation are given by Ro Naz 8 5 Ri ee R3 Na 8 6 1 Ry 8 9 The following is calculated for the external gears but the derived expression is general and can be applied to the internal gear as well When torque is applied to the motor shaft a force Fm affects the bel
162. n a TCP IP based network on TCP port 8 The basic package structure looks like this struct pkgRuc uint16_t length uint8_t pkgType char pkgContents y The contents of the pkgContents field is determined by the pkgType Table C 1 lists the possible package types available in the RUC protocol Package 0 127 go from the ground station to the RUC while packages with numbers higher than 127 go from the RUC to the ground station Having specified the different types of packages the contents pkgType Describing struct Description 0 pkgSatData Contains telemetry data received from the CanSats 1 pkgControlInfo Information about current and wanted az imuth and elevation of the antenna 2 pkgAcknowledge Informs the RUC that a command previ ously send to the CanSat has been suc cessfully received by the CanSat Consists of the basic package structure only 128 pkgManualAntennaCtrl Specifies wanted azimuth and elevation for antenna when using manual antenna con trol 129 pkgSetSatld Specifies the CanSat ID to use 130 pkgSetManualLocation Specifies the GPS location of the ground station which is used for automatic CanSat tracking 131 pkgGSCmd Miscellaneous commands from the RUC to the ground station that doesn t require any arguments 132 pkgCanSatCmd Request the ground station to send a com mand to the CanSat Table C 1 List of package types in the RUC protocol of each package must be specified This
163. n be seen that the ground station has to be connected to the remote user client over a TCP IP based network In the following the application level protocol for the communication over this network will be defined This protocol defines the interface between the two major subsystems the ground station system and the remote user client The ground station functionality can furthermore naturally be divided into a number of subtasks This division into subtasks will be described thus further modularizing the system For this decomposition of ground station tasks the Hard Real Time Hierarchic Object Oriented Design method HRT HOOD is used 4 1 Utilized Hardware Before going into further details with the breakdown of the systems into smaller parts an overview of the system is given This overview is shown in figure 4 1 on the next page The figure emphasizes which hardware components are used in the system and how they are connected As the base for developing the ground station a development board based on the ARM7TDMI 7 CPU core has been chosen The Mini Max ARM E development board from BiPOM Electronics 8 has an on board Ethernet controller chip which makes it easier to develop the Ethernet support required for the ground station The development board is based on the LPC2138 microcontroller from NXP 9 10 A summary of the NXP LPC2138 features e ARM7TDMI CPU core that can be clocked at speeds up to 60 MHz e 32KiB RAM e 512K
164. nd share the same execution environment This chapter provides an overview of the software modules put together followed by a scheduling analysis to ensure that the hardware platform is shared in such a way that every task gets its job done in time 11 1 Software modules The interfaces between the software modules have already been defined in the modular ization chapter Connecting the software modules each designed and developed in their respective chapter yields figure 11 1 on page 107 Overall the ground station software can be decomposed into 5 tasks and 4 interrupt service routines A summary of their functionality is given in the following list encoderElevationISR amp encoerdAzimuthISR ISRs that count the ticks from the rotary encoders of each motor on the tilt and pan platform rfmIrqHandler ISR that is invoked by the RFM12B radio communication module every time a byte has been send or received encIrqHandler ISR that signals encIrqHandlerTask by upping a semaphore which makes the task run The interrupt is triggered when the ENC28J60 Ethernet con troller has a pending interrupt request most often caused by a received Ethernet frame controllerTask Cyclic task that controls a PWM output voltage to each of the DC motors of the pan and tilt platform The behaviour of the controller depends on the options set by its associated functions rfmPkgHandlerTask Sporadic task that is invoked through a queue by the rfmIrqHandle
165. nd station system because the tasks to be done are known in advance and it makes the system more deterministic The osWaitForDivisibleTick is the only way to create cyclic tasks within AR TOS This syscall takes a 32 bit bitmask as argument The syscall will block until the mask bitwise ANDed with the system tick counter is zero As an example the mask is Ob11 and OS_SYSTICK_TIME is 8 ms which mean the system tick counter is incre mented by 1 for every 8 ms The caller will be unblocked when the two least significant bits of the system tick counter is 0 This happens every 4 8 ms The periodic task will 32 Section 5 2 Multi tasking then look like this for osWaitForDivisibleTick 0b11 lt Work that takes less than 32 ms gt The masked approach enables the implementation of periodic tasks to be efficient and precise A conventional sleep function would not take into account the time it takes for the periodic code to execute or that it may take some time before the execution of the code is begun Many of the system calls will put the calling task into a blocking state When re turning from supervisor mode the processor will then resume execution of another task in user mode This leads to the following discussion of multi tasking 5 2 Multi tasking Multi tasking is a way of sharing computational resources among different tasks so they are executed concurrently from the programmers point of view The operating s
166. ng page 100 Section 10 4 Receive and Send Methods Event Dispatch Connection Connection established Figure 10 17 The event dispatch thread starts the connection thread when a connection needs to be established One reason for dividing the execution of the program into separate threads is because the GUI should be executed smoothly As a consequence the event dispatch thread should never execute time consuming tasks 36 Such tasks could be listening for new packages on the Ethernet connection process these and write the processed data to CSV files If a large quantity of incoming packages needed to be processed the GUI could potentially lock up for a period of time if everything was executed by a single thread The use of two threads in the RUC has some implications that needs to be addressed For instance all the used Swing objects for drawing the GUI aren t thread safe 36 As a result the Swing objects must only be accessed by the event dispatch thread If several threads were to read write to a certain non thread safe object at the same time errors would occur When the connection thread needs to update parts of the GUI such as text fields of labels the SwingUtilities invokeLater is utilized 37 The connection thread will then put a Runnable object in a queue for execution by the event dispatcher thread Once the event dispatch thread is ready to execute a new task the task added to its queue will be executed This
167. ng software Packages that have been assembled by the rfmIrqHandler are forwarded to the rfmPkgHandler which decodes the package according to the WARP specification If it is a type O package the GPS coordinates are extracted and send to the controller by setCanSatLoc Hereafter a RUC SatData package is built and sent to the Ethernet object for transmission to the RUC To avoid having to copy the WARP package when sending it between objects the buffer system described in section 6 3 3 on page 42 is used This also means that a queue is used for the ASER between rfmIrqHandler and rfmPkgHandler Upon reception of the first byte of a package the rfmIrqHandler retrieves a free buffer and fills the package into this It is filled into the buffer at an offset so that there is room to build an RUC package around it when the buffer is forwarded to the rfmPkgHandler and this has to forward the received WARP package to the RUC 48 Section 7 4 Verification Commands that are to be sent to the CanSat are saved by the canSatCmd object Whenever a type 0 WARP package is received it will contain a bit specifying if the ground station is allowed to transmit a package If so the getUnackedCmd is used to get the command that needs to be sent if one such exists The command is then immediately transferred to the CanSat by the rfmIrqHandler When the command has been transmitted rfmIrqHandler starts receiving bytes again When receiving an acknowled
168. nly 16 bit 2 byte so when a byte has been trans mitted or received the microcontroller must have handled it before the next byte has completed transmission reception otherwise FIFO overflow or underflow will occur At 19 2kbit s the transmission of 1 byte takes 8 bit A 7 4 19200 bit s pe m As this is fairly often it has been chosen to implement the handling of each byte directly in the interrupt service routine servicing the interrupt from the RFM12B chip This is shown as the sporadic task rfmIrqHandler in figure 7 1 The RFM12B module is set to receive the majority of the time because the WARP protocol specifies time constraints as to at what times the ground station are allowed to transmit During receival the ISR handles the removal of start stop and escape characters and collects the received bytes into packages A RF Link amp WARP handler RFM12B Byte to send polis ASER sendCanSatCmd Cmd number Sn ela E SAR ASER BY IT start lt 40 Received byte HSER rfmSend P canSatCmd WARP cmd paf y WARP package HSER enqueueCanSatCmd lt 4 HSER cmdAckReceived HSER getUnackedCmd r mPkgHandler ASER start e WARP cmd pkg RUC EN package RUC SatData package Y HSER setCanSatLoc ASER ethernetSend Figure 7 1 ART HOOD analysis of RF and WARP handli
169. nnected to the arduino s serial port hold the CanSat antenna 1m from the ground station antenna Hold the antenna in a horizontal position Hold down the reset button on the arduino release it and wait for it to have transmitted 10 packages Now look at the ground station serial output and note how many packages were received successfully respectively received with CRC errors Repeat step 5 while holding the antenna in a vertical position i e rotated 90 deg in a plane normal to the direction the antenna is pointing Repeat step 4 6 increasing the length 1m until nothing has been received for 3m The results from the test can be seen in table 1 3 Distance Orientation Packages OK Packages w Lost packages CRC mismatch 2m Horizontal 10 2m Vertical 10 3m Horizontal 10 3m Vertical 10 4m Horizontal 10 4m Vertical 10 5m Horizontal 10 5m Vertical 10 6m Horizontal 10 6m Vertical 10 7m Horizontal 10 7m Vertical 10 10m Horizontal 10 10m Vertical 10 Table 1 3 Test results of downlink test 1 6 Measurement Uncertainties The environment where the measurements are taken can have a significant implication on the results as reflections and absorption of the RF signal occur The measurement has been taken as free line of sight directly above the earth When flying the CanSat it will be in the air and thus further away from any reflection sources such as the earth 21
170. nsstyrelsen 2010 Aug Cansat l ring pa dase Downloaded 20 09 2010 Online Available http www fi dk nyheder nyheder 2010 cansat laering paa daase 2010 CanSat Competition Downloaded 28 09 2010 Online Available http www cansatcompetition com Main html University Space Engineering Consortium 2010 Comeback Competition Downloaded 12 12 2010 Online Available http www unisec jp history comebackcompetition e html ESA 2010 CanSats in Europe 2010 competition requirements Down loaded 20 09 2010 Online Available http www esa int SPECIALS CanSat SEMFTUCKP6G 0 html Andgya Rocket Range 2010 Cansat Downloaded 01 10 2010 Online Available http www rocketrange no page_id 299 ARM Ltd ARM7TDMI Technical Reference Manual Apr 2001 issue G t BiPOM Electronics Mini Max ARM C and Mini Maz ARM E Aug 2006 revision 1 04 O NXP LPC2131 32 34 36 38 Single chip 16 32 bit microcontrollers Oct 2007 re vision 04 10 NXP UM10120 LPC2131 2 4 6 8 User manual Oct 2010 revision 3 11 Hope RF Universal ISM Band FSK Transceiver Module RFM12B O 12 Hope RF RF12B Universal ISM Band FSK Transceiver 13 A Burns and A J Wellings A structured design method for hard real time systems Downloaded 20 09 2010 Online Available http www springerlink com content k1128146787553h8 14 ARM Ltd ARM Architecture Reference Manual Jul 2005 issue I O
171. o a 20 step for elevation with lead control 88 Section 9 4 Verification of Controllers a better response with less overshoot and less steady state error The correction thus seem to be able to at least decrease the effect of this non linearity e For elevation the motor only has to move the antenna whereas for azimuth the motor must rotate the whole pan z tilt platform This results in the elevation model to be more sensitive to unforeseen forces as these will be relatively higher compared to the forces that are modelled in the system This is also seen in the figures as the measured results for azimuth are more smooth than for elevation It thus cannot be concluded if the deviation from the simulated values is caused by deviations in the model parameters or that it is caused by non linearities All the measured responses follow the simulated responses well until a position of about 10 At this point the angular velocity decreases very fast for the lead controller it almost decreases to 0 Within 50 ms the antenna movement continues again This is a very strange behaviour that at first cannot be explained by non linearities or model parameter values It has not been possible to determine what causes this effect Because of the above mentioned it has not been possible to meet the requirements for t and M which respectively are 100 ms and 10 It is acceptable that these are not met as they were simply design criteria u
172. oad field as a 23 character text string The format is a slightly modified version of the GGA field in NMEA 0183 the standard used by most GPS receivers The following format is to be used for transmitting the GPS data to the ground station char 4 height Height in meters can be negative by prefixing with the char Valid range is thus 999 to 9999 m x char 1 longitude_east_west Either E or W x char 3 longitude_degrees Longitude degrees char 2 longitude_minutes Whole longitude minutes char 4 longitude_minutes_frac Longitude 1 1000 s of a minute char 1 latitude_north_south J Either YN or S x char 2 latitude_degrees Latitude degrees x char 2 latitude_minutes Whole latitude minutes x char 4 latitude_minutes_frac Longitude 1 1000 s of a minute x Furthermore there are some timing requirements to ensure that the ground station always has an adequately recent GPS coordinate available It is required that a new type 0 package containing new GPS coordinates are transmitted at a fixed rate of 5 Hz The GPS coordinates contained in each of these packages must not be any older than 200 ms when they are transmitted B 4 Type 1 Packages Type 1 packages facilitates sending commands from the ground station to the CanSat These commands will then correspond to an action to be performed on the CanSat It is noted that it is not possible to send any arguments along
173. on is made available by the author of uIP by a module named uIP TCP throughput booster hack Since this solution adds more complexity and the required throughput is relatively low a simpler solution has been chosen The maximum TCP segment size has been set to 510 bytes which prevents the delayed ACK algorithm from kicking in on the hosts tested It should be noticed however that the result may vary between different TCP implementations Equation 6 1 implies that the throughput of uIP will suffer greatly from delays in the network link The estimated worst case throughput requirement outlined in the beginning of this chapter was 7100 B Say the average segment size is 400 due to only an integral number of RUC packages will be assembled into a single segment solving equation 6 1 for tres tta yields 400 trtt ta 7100 0 056 s 6 2 The maximum tolerated delay in the network is thus around 56 ms 43 Chapter 6 Wired Communication with Remote User Client 6 4 1 Throughput Test A throughput test program has been created which will continuously fill the outgoing Ethernet buffer with RUC packages with the size of 42bytes arbitarily chosen size to represent RUC package size under typical usage The test program can be found on the cd The ground station is connected to the laboratory network of AAU lab es aau dk and a PC is connected to the wired network of AAU Ping packets give a round trip time of 2 2 ms in average The
174. on page 17 This test will be performed with respect to acceptance test 1 seen in section 1 on page 19 6 2 Test Object The test object is the fully implemented system described in chapter 4 on page 23 Used Equipment Instrument AAU No Make and type CanSat stand in Arduino Mini Pro w RFM12B and 8 63 cm wire whip antenna Table 6 1 Equipment used in the test The software running on the CanSat stand in is based on the kernel and RFM12B driver code developed by group 502 The CanSat stand in is described further in appendix F 6 3 Approach A connection is established from the RUC to the ground station and a specific CanSat ID is specified The ground station code is modified so that all correctly received CanSat packages with the corresponding ID increments a package counter A CanSat stand in is then set up to transmit packages with a matching and a different CanSat ID periodically After 50 ms a CanSat package with a matching ID is transmitted 100 ms later a CanSat package with a different CanSat ID is sent In this manner a package with the correct CanSat ID is transmitted approximately every 150 ms for at least 5 minutes Afterwards the counter on the ground station and the number of received packages on the RUC is compared 6 4 Test 1 For this test the code found at 45 was used on the CanSat stand in The test was running for approximately 12 minutes The packages received on the RUC can be seen in the generated
175. ood circumstances and was found to be 65 EB The maximum total delay in the network under which this implementation is still able to deliver a throughput of 7100 B worst case estimate of required throughput was found to be 56ms The weakness of uIP is the inability to cope with more than one unacknowledged Ethernet frame at a time This makes the throughput prone to delays in the network The maximum delay requirement requirement 3 from the requirement specification has not been tested because it heavily depends on the way the tasks are scheduled The scheduling analysis is performed in chapter 11 on page 105 and the requirement is tested in the acceptance test in chapter 12 on page 117 2 tests ethtest main c 3 tests ethtest wireshark cap 44 CHAPTER RF Communication with CanSat The ground station has to communicate with the CanSat over a wireless link This link should be fairly reliable even though some bit errors in the transmission can be accepted The checksum present in packages sent over the link WARP protocol packages will enable detection of any errors and erroneous packages will be discarded The design of the RF communication is done in cooperation with other groups who are creating CanSats to enable the ground station to work with these CanSats later on The requirement specification mentions the following which has relevance for the connection link e Requirement 1 Must implement and adhere to the WARP protocol
176. operations that have been invoked S Sporadic Objects that start executing at arbitrary time instances These are often started by an interrupt They have a minimum arrival time associated with them specifying the maximum rate at which they occur Having mentioned the different object types the relations between objects can be ex plained There are many different types of execution requests in HRT HOOD each describing a way one object can invoke an operation of another object Here only these will be mentioned and used 28 Section 4 3 Ground Station Subtasks Object Type A Object Name Operations that can be operation1 Sa performed on the object operation2 Figure 4 3 Graphical way of representing a HRT HOOD object 13 ASER Asynchronous Execution Request When an operation is invoked by an ASER the caller is not blocked but continues to execute The execution request is noted and performed by the called object at some later time ASER_BY_IT Asynchronous Execution Request from Interrupt Same as ASER but is invoked by an interrupt either via a synchronizing semaphore or directly as an interrupt handler HSER Highly Synchronous Execution Request The calling object is blocked un til the requested operation has been completed Effectively a regular call to a method in C PSER Protected Synchronous Execution Request The same as HSER but in voked on a protected object whic
177. or the controller e Requirement 8 The ground station must be able to control the antenna so that an object following the launch graph on figure 2 3 on page 11 can be tracked The target must be within the half power beamwidth of the antenna at all times 9 1 Interpretation of the Requirement It is now desired to analyse the requirement given above and turn it into requirements that are suitable for designing the controller Time domain specification is used for this which means specifying rise time t and overshoot Mp for the response of a unit step input to the closed loop system An illustration of how these are defined is seen in figure 9 1 on the next page Settling time is not very relevant as the antenna position will continuously be adjusted during tracking so it is not specified Elevation Requirements From the WARP protocol described in appendix B on page 131 it is evident that new packages with GPS data will arrive every 200 ms It is necessary for the controller to keep up and be able to adjust to the new position before a new package arrives The rise time doesn t include the time it takes for the controller to accelerate until 10 of the step and the time for the deacceleration after 90 of the step has been reached 65 Chapter 9 Feedback Control of Pan amp Tilt Platform Figure 9 1 This figure illustrates how tr ts and Mp is defined Therefore the rise time is chosen to 100 ms which pro
178. ore and use the specified CanSat ID 1 User Specifies the desired ID 2 System Receives the ID and stores it e The user specifies an invalid CanSat ID The system ignores the user input and warns the user 7 Save Sensor Data Goal description Normal scenario Exceptions The user specifies a destination for the saved data 1 System Queries the user to specify a file destina tion to store the data 2 User Specifies a destination e The user specifies an invalid file destination The system ignores the file destination and the user is given the opportunity to retry 8 Retrieve Ground Station Telemetry Data Backup Goal description 16 The user can send a request specifying that he she wants to obtain the ground station telemetry data backup Normal scenario Exceptions Section 3 2 Requirements Specification User Queries the system to retrieve telemetry data backup from the ground station System Receives the query and attempt to re trieve the backup The ground station telemetry data backup is empty The system reports that the requested backup is empty 9 Send Commands to CanSat Goal description Normal scenario Exceptions The user can send different commands from the system to the CanSat 1 User Queries the system to send commands to the CanSat System Receives the query and sends the speci fied command to the CanSat The
179. ory must be statically allocated by the user Furthermore the user must ensure that the allocated stack size is sufficient to prevent stack overflow void osTaskTerminate Terminates the currently running task Has the same effect as returning from the task void osWaitForDivisibleTick uint32_t mask Blocks the caller until the system tick count systickCnt ANDed with the mask is zero 143 Appendix E ARTOS Function Prototypes E g if OS_SYSTICK_TIME is 8 ms and the mask is 0b11 the caller will be unblocked when the two least significant bits of the systickCnt is 0 which happens every 8 4 ms OS_SYSTICK_TIME mask 1 This masking system makes the implementation of osWaitForDivisibleTick efficient This system call can be used to create periodic tasks Parameters mask 32 bit number to be ANDed with the systickCnt Variable Documentation volatile uint32_t systickCnt The system time measured in system ticks This variable shall be considered readonly from user programs Definition at line 24 of file os c Referenced by osGetTime and osGetTimeFromIsr 144 Appendix F CanSat Test Stand in Appendix F CanSat Test Stand in In order to perform tests of the system a device acting as a CanSat is needed For this an Arduino Mini Pro 38 with an RFM12B 11 radio transceiver is used As the antenna for the CanSat stand in an 8 63 cm wire is used ie a quarter wave length whip antenna This setup ha
180. osition values according to the following formula into the controller The formula has been derived by integrating eq 2 2 and 2 4 which were described in section 2 3 1 on page 9 1 2 cart arctan 2 0 lt t lt t w t ne t t1 arctan it lt t where a is the acceleration during the constant acceleration phase 9 825 20 196 4 5 Umax is the maximum velocity of the rocket 6008 166 672 2 r is the horizontal distance between the ground station and the launch m site 400 m h is the distance travelled by the rocket during the constant acceleration m phase 70 7 m t is the duration of the constant acceleration phase 0 849 s s t is the time since the beginning of the launch s A new angle is calculated and fed into the system every 200 ms to simulate the effect of a GPS update rate of 5 Hz Feeding the values into the controller is done from a modified 29 0urnals controller measurements stepelevPnonRegInfo csv 30 50urnals controller measurements stepelevLeadnonRegInfo LESY 3l Journals controller measurements stepaziRegInfo csv 161 Journal 4 Controller Verification version of the RUC which can be found on the CD The test results can be found on the CD 0 and a plot of the test can be seen in figure 9 24 on page 90 4 10 Measurement Uncertainties No significant measurement uncertainties are present for these tests 32 4 ournals controller gscurvetracer 33 journals controller measurement
181. ote user client is implemented as a GUI application running on such a system The project thus consists of the following technical aspects that are implemented in the product e Automatic Antenna Direction Control The antenna needs to be adjusted to point straight towards the CanSat at all times To ensure this functionality a pan and tilt platform assisted by a controller is utilized The controller is designed and constructed by the project group whereas a pre built pan and tilt platform will be used In order to design the controller it is necessary to design a mathematical model of how the motors on the pan and tilt platform affect the direction the antenna is pointing In order to know which way to point the antenna the ground station needs to know where the CanSat is For this it has been chosen to require the CanSat to be equipped with a GPS These GPS coordinates will then be sent to the ground station over the radio link which can then be used to calculate in which direction to point the antenna CanSats that should be tracked automatically by the ground station must thus be equipped with a GPS For this to work the ground station must know the GPS coordinates of its own location as well Furthermore it is desirable to be able to override this automatic antenna control and manually control the antenna This can be used if the ground station is used with a CanSat that do not contain a GPS or if the ground station looses track of the
182. otice that most of the classes in the interface have been simplified or left blank in order to maintain the overview several of the methods attributes that are actually used in the code Therefore pub lic private indicators have been removed 10 2 User Interface and Functionalities In order to allow the remote user easy access to the ground station a GUI for the RUC is designed The interface is divided into 4 tabs e Configuration e Ground Station Control e Event Log e Data Log The content of these tabs is discussed in the following 10 2 1 Initial Connection When the GUI is first presented to the user a number of choices are available In section 10 2 2 on page 95 a description of the selectable datatypes is given which needs to be specified before connecting to the ground station Furthermore the user needs to specify whether the ground station will be using Conformance Class 1 or Conformance Class 2 This specifies whether automatic CanSat tracking is available as described in appendix B on page 131 The PC Ground Station panel can be seen on figure 10 4 on the following page In order to connect to the ground station the user needs to know the IP Address of the ground station which will be using TCP port 8 Also the user needs to type in the CanSat ID By clicking the Connect button a connection will be established after the user has specified a filename for the CSV file 93 Chapter 10 Remote User Cli
183. otocol and transmit it The package payload will be 150 bytes The ground station and RUC will be connected directly through an Ethernet cable Once the package has been transmitted the timer will be stopped This is repeated for 1000 packages and the worst case time is extracted If the worst case time is less than 200 ms this test is passed Test 3 Covers Requirement 4 and 5 10 000 packages with known data are sent to the RUC using the RUC protocol The saved data is compared with the data received to see if they were stored correctly Afterwards the test is repeated but this time the RUC is terminated by the OS halfway through receiving the data In order to pass this test all received packages must in both cases be stored correctly Test 4 Covers Requirement 6 The ground station is set to track a CanSat with a specific CanSat ID Packages ad hering the WARP protocol with this specific ID is send to the ground station at a rate of 5Hz with each package being the maximum package size 150 bytes The RUC is then disconnected from the ground station After 5 minutes the package transmission is stopped The RUC is then reconnected to the ground station and the stored data in the ground station data back up is requested In order to pass this test the ground station must be able to send the last 5 minutes of CanSat telemetry received to the RUC Test 5 Covers Requirement 7 A ground station and a CanSat is placed in lin
184. ous chapter outlines some of the aspects that form the basis of this project It described the basic composition of the project and the product to be de signed In the following chapter use cases are used to describe the desired functionalities of the final product seen from the users perspective Next a requirement specification outlines the technical requirements that the product should comply with Based on this an acceptance test specification is made If the product can pass this test it complies with the requirements specification The use cases and the requirements specification are based on the previous analysis 3 1 Use Cases To establish an overview of what the product should contain seen from the users perspec tive a use case diagram has been drawn up The diagram is based on the preliminary analysis and the chosen areas of focus described in chapter 2 Each use case describes a functionality that needs to be incorporated into the final product These use cases set the scope for the product but without eliminating the opportunity to add extra functionality The use case diagram can be seen in figure 3 1 on the next page 3 1 1 Actors The system has the following two actors e User The user could be a student at an upper secondary school who is participating in the CanSat competition e CanSat The CanSat is what needs to be tracked by the ground station It provides the ground station with different kinds of data such
185. quency can then be lowered by lowering the value of Kp By lowering the value of Kp the phase margin and t will increase while M will decrease Choosing a value for K will be a compromise between Mp and tr 69 Chapter 9 Feedback Control of Pan amp Tilt Platform Bode Diagram Gm Inf dB at Inf rad sec Pm 58 6 deg at 7 71 rad sec 50 Beit pee we we E ESE a a eee A RE Re EE RS CA PS CoO ete et Rare eee ee 0 2 3 10 10 10 10 10 Frequency rad sec Figure 9 4 Bode plot of the open loop system where Kp is 19 1 Choice of Parameters In figure 9 5 a plot of Mp and t as a function of K can be seen The figure shows that the controller meets the requirements as long as Kp is between 13 6 and 19 1 30 Y T T T T T T T T 0 6 Overshoot 25L A Rise time Los wo 20 40 4 _ D cy 3 2 15H cea 40 3 a o Q a N iok aera 40 2 5f 30 1 0 ji i ji i i i 0 0 5 10 15 20 25 30 35 40 45 50 Gain factor Kp Figure 9 5 This figure illustrates Mp and tr as a function of Kp In figure 9 6 on the next page a simulation of the systems response to a step function can be seen The dotted curve is when the value of Kp is the highest possible value and the solid curve is for K equal to the lowest possible value The value of Kp has been chosen to the highest value 19 1 which means a quick response small
186. r driving a motor CW is the same as driving it CCW Output signals from the encoders are connected directly to input pins on the ARM board 9 3 5 Software Implementation From the design of the controllers it is clear that they need to be sampled at different frequencies and therefore should be run in separate cyclic tasks For simplicity it has been chosen to run the two controllers in the same task though A HRT HOOD diagram of the controller software can be seen in figure 9 18 on the next page As mentioned the controller can work both in manual mode and in automatic mode To toggle between them a package is sent from the RUC to the ground station Routines handling the Ethernet link then calls the function setAutoCtr1 with either a 0 or a 1 82 Section 9 3 Implementation E Antenna Controller controllerTask HSER calibrate HSER setAutoCtrl Wipe HSER calibrate HSER setManualDirection HSER setAutoCtrl Az El values Oj _y 5 roe HSER setGroundstationLoc BERS steel GPS data O gt HSER setGroundstationLoc HSER setControllerType gt HSER setControllerTi ype 4 A Ctrl Type O gt HSER setNonlinearCompensation gt HSER setNonlinearCompensation HSER setCanSatLoc On Off O HSER setCanSatLoc GPS data O gt ASER ethernetSend ruc S encoderElevationISR Controllnfo pkg S encoderAzimuthISR ASER_BY_IT sta
187. r contains the actual data to be transmitted and the data received from the network The buffer is divided into a configurable receive and transmit area When the microcontroller has a packet ready it is transferred via SPI to the transmit area of the buffer and some control registers are programmed with the start and end address of the packet The transmission process is started by writing to another register The buffer s receive area works like a circular FIFO buffer The chip is configured to assert the interrupt pin whenever there are unprocessed packets in the buffer The first two bytes of the packets written to the receive buffer is a pointer to the start of the next packet In that way the Ethernet controller s receive buffer can contain several unprocessed packets structured as a linked list If the receive buffer gets filled up any incoming packages will be discarded The microcontroller must free the receive buffer space by setting a special read pointer within the receive area and decrement the count of pending packages by writing to one of the control registers The device driver for the ENC28J60 Ethernet controller can be found on the CD and has the following function prototypes void encInit void uint16_t encReceivePacket uint8_t buf uint32_t length void encTransmitPacket const uint8_t x buf uint32_t buflen void encRegDump void uint8_t encReadIrqFlags void void encSetBank uint8_t bank uint8_t encR
188. r system the position curves would quickly accelerate and then form into straight lines Because of the gradual shift in gravity though this doesn t happen The compensation improves the situation but doesn t manage to make the curves en tirely linear It does make the acceleration faster though and it stabilizes the velocity especially at lower voltages The result is considered enough of an improvement that the compensated curves can be used to determine friction parameters for elevation 8 5 4 Elevation Friction Parameters All elevation tests were performed with non linear compensation enabled in the software The tests were carried out by applying voltages of 4 6 and 8 V Points on the curves were chosen where the angular velocity is approximately constant and the values can be seen in table 8 3 The velocities have been found using eq 8 30 on page 58 61 Chapter 8 Modelling of Pan amp Tilt Platform T vy 2t 4 1 57 4 3 lt a 4L Tet J 4V Y 0 5F J With compensation Without compensation 0 ih j L 1 1 0 500 1000 1500 2000 2500 3000 time ms Figure 8 10 A plot comparing the measured elevation performance with non linear compensation enabled and disabled V ti t2 p p2 WL 4 1 152 1 192 1 1380 1 1973 1 4835 6 0 512 0 552 1 2078 1 3456 3 4470 8 0 352 0 392 1 2182 1 4277 5 2360 Table 8 3 Measured time and position values from elev
189. r task wants to run If the preprocessor variable OS_SLEEP_ON_IDLE is defined the idle routine will put the CPU into idle mode which removes the clock signal to the CPU core to save power but keeps the peripherals of the LPC2138 powered The CPU will wake up on interrupts Sleep on idle is disabled by default because it will turn off the JTAG debugging interface as well It should be considered whether using idle mode increases the interrupt latency but the LPC2138 user manual 10 provides no information on this issue The operating system creates a priority 1 task as well which will run the main procedure This is the starting point for user mode programs T 5 2 1 Inter task Communication When having several concurrently running tasks they need a way to communicate As all tasks are executing in the same memory space the simplest form of communication is by reading and writing to the shared memory This will lead to errors though when two tasks are working on the same memory simultaneously In order to ensure only one task is working on a shared variable one can use a critical region basically by disabling interrupts before working on the variable This ensures that no other task gets to run until the task has left the critical region ARTOS supports critical regions with the osEnterCritical and osLeaveCritical syscalls The major drawback 34 Section 5 3 Fixed Priority Scheduling of this solution is
190. r the user to save this data in a CSV file e Information about the antenna position Two value sets are to be sent Current actually measured antenna position and wanted position position being fed into the controller This information must be shown to the user who can then decide if manual or automatic antenna control is to be used By both supplying the wanted and current antenna position it is possible for the user to see if the feedback control is able to follow the antenna position that is wanted This information must be sent at a high rate so that it can be used to test the feedback control as well The RUC should save the received information about antenna position in a file so that it can be analyzed when testing the feedback control of the pan amp tilt platform e Acknowledgment of commands previously sent to the CanSat 4 2 2 Underlying Protocol TCP has been chosen because it provides reliable connection oriented byte stream trans fer between two hosts and it is widely supported by existing networks and hardware This means that TCP guarantees that sent data will ultimately arrive in the order they were sent and without errors The most obvious alternative to TCP is the UDP pro tocol It is fundamentally different from TCP since it s datagram oriented instead of connection oriented UDP doesn t make any guarantees about data actually being de livered data integrity on delivery or the order in which the data is delivered
191. r when a whole package has been received The checksum of the package is verified then information from the package is extracted and passed on to the two other modules 105 Chapter 11 Scheduling of Ground Station Software uipPeriodicTask Cyclic task which updates the internal timers of the uIP library and is responsible for retransmitting TCP packages Takes the uIP semaphore uipSem before executing encIrqHandlerTask Sporadic task that processes the interrupt request from the Eth ernet controller Most often it will interpret incoming Ethernet frames and react on its contents If the incoming package contained a TCP ACK or a new TCP connection has been established the clear to send semaphore ethCtsSem will be upped Takes the uIP semaphore uipSem before executing ethSenderTask Sporadic task that is executed when there is pending outgoing appli cation layer packages in the outgoing Ethernet queue and the networking system is clear to send Thus the ethSenderTask can be blocked in three different ways The outgoing Ethernet queue ethOutQ is empty the clear to send semaphore ethCtsSem is 0 or the uIP mutual exclusion semaphore uipSem has been acquired by another task There furthermore exists the interrupt generated by the system tick in the ARTOS operating system This is though neglected in the following analysis as it should be executed very fast and only for every 8ms Having all the tasks of the ground station sy
192. rd some overall tasks have to be solved e The encoder signals need to be interpreted and converted into radians or degrees e A PWM frequency needs to be chosen e The GPS coordinates need to be converted to azimuth and elevation coordinates e A physical link between the ARM board and the motors encoders needs to be implemented 9 3 1 Encoders The encoders mounted on the azimuth and elevation motors are of the type 225771 32 from maxon motors It is a rotary encoder that gives 128 counts per turn or a count for every 2 8 There are two signals from each encoder to the ARM board consisting of an A signal and a B signal The B signal is 90 delayed compared to signal A The A signal from each encoder are attached to an interrupt pin on the ARM board When an A signal goes from low to high an interrupt routine is run This interrupt routine checks if signal B is high too If so the motor must be turning in one direction otherwise the motor must be turning in the opposite direction In this manner the motor rotation can be measured If both A and B are high the interrupt routine increments the encoder value if not it decrements the value An illustration of how signal A and B from the encoders work can be seen in figure 9 12 on the next page The encoder value are converted by dividing the encoder value with the value of an entire revolution and then multiplying with 27 for radians or 360 for degrees How the interrupt routines are
193. re smooth curve for the controller to follow and thereby avoid the stair case input shape Summary In this chapter the controllers for the antenna positioning system have been designed For azimuth a single proportional controller has been designed For elevation a proportional and a lead controller has been designed By comparing these both in simulations and measurements it has been determined that the lead controller is the one that is best suited for tracking the CanSat By simulating a CanSat launch and feeding this into the designed controller it has been shown that the system is able to track the CanSat in a satisfactory way T journals controller processing m 90 CHAPTER Remote User Client In this chapter the design and construction of the remote user client RUC is described The RUC needs to enable a remote user to adjust and control the ground station antenna and send commands to the CanSat and ground station itself It must also enable the user to easily gain access to CanSat telemetry data both during and after a CanSat Fight and log all relevant activities In order to accomplish these functionalities a Java based graphical user interfaced GUI program has been designed To ensure a reliable communication between the ground station and the remote user client an Ethernet link has been utilized Therefore the RUC needs to support this kind of connection The packages sent over this connection will follow the RU
194. re implementation of the elevation controller differs from the azimuth con troller in several ways It isn t just a proportional controller so the continuous equation needs to be converted into a discrete form that can be implemented in the software It has also been chosen that the user should be able to switch between different types of controllers The 4 different types that can be chosen are e Proportional controller e Proportional controller with non linearity correction e Proportional controller with lead compensation e Proportional controller with lead compensation and non linearity correction Continuous to Discrete Conversion Because the lead elevation controller is designed in continuous time it needs to be con verted to discrete time in order to be implemented on the ARM board In equation 9 55 the expression for the continuous controller can be seen Figure 9 19 on the facing page shows a block diagram of how the continuous controller is converted to a digital controller 0 063 s 0 741 D s 25 A rae ed 9 55 84 Section 9 3 Implementation RRE e o a e a ta e a e e de eke eh Digital Controller r kTg elkTa Difference O T Z equation r t y t y kTa Figure 9 19 Block diagram of a discrete controller The difference equation is found from the contin uous equation of the controller Tg is the sample time To convert the controller from continuous to discrete time
195. read written to the serial port Each test consists of a C file that replaces the original main file The files can be found on the cd Each file contains a brief description of the test and the expected result Run the test by replacing main c file in 4 by the test file and compile as described in the comment at the top of the file The operating system has passed all the tests and is thus considered to be working and fulfilling the originally defined requirements Summary The preemptive operating system ARTOS has been designed and tested It only provides the kernel of an operating system and is used as a platform for the further development of the ground station system software The operating system s feature highlights are semaphores message queues periodic task execution and a fixed priority scheduler The features of the system are utilized by the other software modules 3 tests ostests main c test lt gt 4 groundstation sre 36 CHAPTER Wired Communication with Remote User Client This chapter is about the design and implementation of the Ethernet amp RUC protocol block shown in figure 4 4 on page 30 The following requirements from the requirements specification is directly related to this module e Requirement 2 Must implement and adhere to TCP IP and Ethernet protocols e Requirement 3 No more than 200 ms may pass from a package is received on the ground station s wireless link until
196. rection In this test the elevation position is set to 20 initially This is done to test the effect of running the controller with the non linearity correction enabled The elevation position is then changed to 40 instantly The test results can be found here A plot of the test can be seen in section 9 4 on page 86 4 7 Test 4 Elevation Lead Controller With Non linearity Correction In this test the elevation position is set to 20 initially for the same reason as in test 3 The elevation position is then changed to 40 instantly The test results can be found here 9 A plot of the test can be seen in section 9 4 on page 86 4 8 Test 5 Azimuth P Controller In this test the azimuth position is set to 0 initially The azimuth is then changed to 20 instantly The test results can be found here Gl A plot of the test can be seen in section 9 4 on page 86 4 9 Test 6 Acceptance test 6 Only the elevation controller will be a part of this test because it is assessed that when the CanSat is launched the antenna is pointing at it and the rocket containing the CanSat will fly straight op in the air It can be seen from the plots in section 9 4 on page 86 that the elevation controller with the best step response and therefor the one chosen for the test is the lead controller with the non linearity correction enabled The elevation position is initially set to 0 A CanSat launch is then simulated by feeding p
197. requested command never reaches the CanSat If the system doesn t receive an acknowledge ment from the CanSat the command will timeout When the command times out it will be re sent This procedure will be repeated until the system re ceives the acknowledgement 3 2 Requirements Specification The purpose of this chapter is to define and specify the requirements for the product These requirements are based on the general goal of the project and the previous analysis of the system The final product must comply with the following requirements Requirement 1 Must implement and adhere to the WARP protocol To be able to receive and process data from any CanSat the ground station must imple ment the WARP protocol described in appendix B Requirement 2 Must implement and adhere to TCP IP and Ethernet pro tocols The ground station will be connected to a network via an 8P8C connector also known as RJ45 connector This network will be TCP IP based and the connection to it will be 17 Chapter 3 Requirements Specification an Ethernet connection The ground station and RUC must thus adhere to the TCP IP protocol suite and the Ethernet protocol Requirement 3 No more than 200 ms may pass from a package is received on the ground station s wireless link until the processed package containing this information is sent to the RUC if this is connected through a direct Ethernet cable This requirement will ensure a certain
198. response time for the user when using the system by limiting the ground station s package processing time It is assumed that the response time of the RUC is insignificant compared to the processing time of the ground station This assumption is based on the fact that the ground station is implemented on an embedded system and the RUC is implemented on a PC Requirement 4 The RUC must save all received data as a comma separated values file CSV This requirement stems from the need to save all recorded data in an easily handled format CSV is cleartext with a simple format and is supported by many applications Requirement 5 If the RUC crashes any data that already has been received must not be lost In order to achieve this requirement all data processed by the RUC should be saved to a file immediately after reception Requirement 6 The ground station must keep a backup of the latest received telemetry data This backup must contain data from the last 5 minutes or more given a package rate of 5Hz with each package being the maximum package size 150 bytes If the connection to the RUC is lost prior to or during a flight it is desirable to backup all received data It noted that the rules for the competition state that a CanSat cannot be airborne for any more than 120s 5 It is estimated that a data recording won t last for any more than 5 minutes and the maximum package rate will not be more than 5 Hz Please note the maximum pa
199. rise time has been chosen at the cost of a higher overshoot This gives a steady state error of 6 35 when the input is a ramp The final value of K can always be altered under testing to tune the controller It might be necessary to tune the controller since an ideal model of the system can t be realized 70 Section 9 2 Controller Design Step Response 1 4 T Kp 19 1 1 2 Amplitude 1 1 5 Time sec Figure 9 6 This figure illustrates the systems response to a step input Simulated values 9 2 3 Elevation Controller The elevation direction controller is designed the same way as the azimuth direction controller The only difference between these is a non linear element in the elevation plant The non linear element appears because the antenna is balancing on a point of gravity that shifts when the antenna is changing direction An illustration of the non linear element can be seen in figure 8 6 on page 57 Non linearity Correction From equation 8 45 on page 61 it is seen that the only element that aren t a constant is 0 Since 0 is known at all times because of feedback from the motor encoders described in section 9 3 1 on page 76 it is possible to calculate the voltage that needs to be subtracted from the controller output to counter the effect of the non linearity Please note that the sign changes depending on the angle and thus the result can both increase or
200. rst case scenario a result from section 6 4 is used In order to achieve the throughput of 7100 B which is a worst case estimate the maximum allowed total delay in the network link is 56 ms Still assuming 100 CPU load the interarrival time Tmin for the ethSenderTask for high est possible throughput requirement is thus 56 ms Giving 20 ms to the round trip time and the processing of the TCP packet by the RUC the deadline of the ethSenderTask is 36 ms When neglecting the ACK processing time of the encIrqHandlerTask its interar rival time is determined by the amount of requests sent from the remote user client All requests from the RUC are issued by the user It is assumed that the user is not able to issue requests faster than 100 ms thus the interarrival time is 100 ms in worst case The deadline of this task is set to 50 ms 109 Chapter 11 Scheduling of Ground Station Software The last task uipPeriodicTask is controlled by the osWaitForDivisbleTick function of the operating system and is invoked every 500 ms Its main job is to update internal timers within uIP and do retransmission if required It is assumed that setting a deadline of 50 ms is sufficiently small to make uIP fully functional 11 2 2 Timing Attributes Worst case execution time c has to be determined for all tasks in the system It can be found using static code analysis or by measurements It has been chosen to use measurements The execution time is m
201. rt ASER_BY_IT start Azimuth Elevation rotary encoder rotary encoder Figure 9 18 HRT HOOD analysis of the antenna controller software as argument where 1 will set it to automatic mode The controller pointing position depends on coordinates given as azimuth and ele vation In order for the controller to know these coordinates it needs to know where it is pointing compared to north and what its elevation position is compared to level A calibrate function calibrate which is called from the Ethernet handling routine when a button on the RUC is pushed The calibrate function clears the value of currentAzimuth and currentElevation It is up to the operator of the systems task to make sure that the antennas pointing direction is north and that the elevation position is horizontal when the system is calibrated In order for the controller to work it needs an input in the form of a reference angle The reference can be inputted either in manual mode or in automatic mode In manual mode a package with azimuth and elevation position of the antenna is sent from the RUC to the ground station When the ground station receives the package it calls the function setManualDirection which sets the global variables desiredAzimuth and desiredElevation to the values inputted on the RUC Before the ground station can track a CanSat it needs its own GPS position as a reference point The location of the ground sta
202. s Preface This report has been composed by group 503 at the faculty of engineering nature and medical science at Aalborg University in the period from 2 9 2010 to 20 12 2010 Itisa 5 semester project at the Department of Electronic Systems Electronics and IT and has been created in cooperation with supervisor Jens Dalsgaard Nielsen The general theme of the project is distributed embedded systems in cooperation with physical systems In the project an antenna system for tracking a CanSat has been designed The target group for this report is university students and teachers Because the project is made mainly for educational purposes the final product is not to be thought of as having commercial value The report is divided into three main parts Project Specifications Design amp Implementation and Assessment amp Conclusion Referenced sources are denoted by a number in square brackets like 1 This number refers to the list of references which can be found on page 127 If the report is read electronically it is possible to jump to chapters sections figures tables and citations by clicking on their references Different acronyms and terms are widely used throughout the report In appendix A on page 130 a list of these can be seen The reader is advised to read this carefully In the report functions and variables written in code are emphasized by a different font Appendices are placed in the end o
203. s been largely copied from the CanSat designed by group 502 autumn semester 2010 5 semester EE at AAU The Arduino Mini Pro is programmed through the FTDI Basic Break 3 3 V pro grammer This also provides a connection to the serial rs232 port used in some of the tests The connection of the RFM12B RF transceiver to the Arduino Mini Pro is done according to table F 1 RFM12B pin see 11 pp 2 Arduino Mini Pro pin see 38 nIRQ 2 nSEL 10 SDI 11 SDO 12 SCK 13 FSK DATA nFFS VCC through 10kQ resistor VDD VCC GND 2 pins GND Table F 1 Connecting the RFM12B to the Arduino Mini Pro Unmentioned pins are not connected Software To perform the tests various pieces of test code has to be executed on the Arduino This testing code is build on top of the kernel and support software developed by group 502 To get this code compiled into the binary image uploaded by the Arduino tool the core that includes this kernel must be added to arduino The core is found at 615 To tell Arduino where the core is located add the following to the boards txt file found in the Arduino installation folder On Linux this is most likely the folder usr share arduino hardware arduino boards txt aau_pro328 name Arduino Pro or Pro Mini 3 3V 8 MHz w ATmega328 and AAUduino aau_pro328 upload protocol stk500 aau_pro328 upload maximum_size 30720 aau_pro328 upload speed 57600 aau_pro328 bootloader low_fuses 0xFF aau_pro32
204. s curvetraceLeadnonRegInfo csv 162 Journal 5 Measurement of Worst Case Execution Times Journal 5 Measurement of Worst Case Execution Times 5 1 Purpose The purpose of this test is to determine the worst case execution time of each task and interrupt service routine of the ground station When tasks depend on each other only the execution time of the task itself is to be measured 5 2 Test Object The test object is the complete ground station system hardware The ground station software is altered to test one task at a time The tasks and interrupt service routines ISR shown in table 5 1 are measured in the test The used equipment is shown in table 5 2 The CanSat stand in used is documented in appendix F on page 145 Name Type ethSenderTask Task uipPeriodicTask Task encIrqHandlerTask Task rfmPkgHandler Task controllerTask Task encIrqHandler ISR rfmIrqHandler ISR encoderAzimuthIRQ ISR encoderElevationFIQ ISR Table 5 1 Tasks under test Used Equipment Instrument AAU No Make and type CanSat stand in Arduino Mini Pro w RFM12B and 8 63cm wire whip antenna Oscilloscope 52772 Agilent Mixed Signal Oscilloscope 54621D Laptop Lenovo R61 Table 5 2 Equipment used in the test 5 3 Procedure The oscilloscope is connected to pin 0 27 of the LPC2138 microcontroller This pin is high 3 3 V when the task under test is running and low 0 V otherwise The time when the pin is high is measured on the oscillo
205. s done separately as the type 0 package contains a payload field with telemetry data that is directly affected by the user chosen datatypes The bytes in the payload field are then interpreted as one or more datatypes based on user choices and saved in both the data log and the data CSV file 10 5 Verification In the following section the requirements specified for the RUC will be tested These can be seen in the introduction to this chapter on page 91 These test results will be used to determine whether the RUC satisfies the specified requirements 10 5 1 Requirement 2 test results As the TCP IP protocol is implemented into the RUC using the standard Java imple mentation this requirement is met 10 5 2 Requirement 4 and 5 test results These requirements are tested in test journal 2 on page 153 in test 1 with respect to the acceptance test specifications in test 3 on page 19 Evidently the RUC can save both CanSat Telemetry and control data in CSV files correctly Also it is shown that even though the RUC crashes while receiving data that data is still available in the CSV files Hereby the RUC passes requirement 4 and 5 from the requirement specification 10 5 3 Conclusion Given the previously mentioned test results it can be concluded that the RUC module is fully functional Also it can be seen that requirement 4 and 5 from the requirement specification are met since test 3 on page 19 from the acceptance test specif
206. s from N rresundby Gymnasium participated in the Euro pean CanSat competition in Norway along with 10 other groups of students from upper secondary schools The competition was hosted by the European Space Agency ESA in order to motivate young people to study science and technology 2 by having them build and launch a CanSat A CanSat is a tiny satellite built to fit inside a standard 330mL soda can It is deployed from a rocket in an altitude of approximately 1km before parachuting back to Earth During the travel the CanSat sends telemetry data to a ground station to be used for educational purpose e g to calculate the apex highest point of the flight The goal of the CanSat competitions is not to build real satellites but rather to have students gain insight into the process of building a real satellite Many space organisations have held CanSat competitions for students from upper secondary school or universities 3 4 5 These competitions seek to inspire young scholars to follow careers within science and engineering This way the space organisations hope to ensure the future workforce of scientists and engineers for developing space programmes The Danish Agency for Science Technology and Innovation are considering hosting a CanSat competition for students in danish upper secondary schools Therefore they have requested Aalborg University to develop a CanSat kit The kit must be designed to be easy to use low cost open source and
207. s project The premise for choosing Section 2 2 System Overview the elements that the project contains has primarily been that they should contain technical aspects that the group would like to learn about e The automatic pointing of the antenna requires the development of feedback con trol of the physical system consisting of the tilt and pan platform and antenna e The radio link to the CanSat requires a data transfer protocol to be developed and implemented e By having the ground station and remote user client placed at different locations a network connection must be established between them Again an application level network communication protocol is needed for this link e The ground station is going to be an embedded system with real time and multi tasking requirements A real time operating system is thus required e The application on the remote user client must be a GUI application that can manage the GUI and service the network connection To do this in a satisfactory way multi programming techniques must be used 2 2 2 Technical Aspects The ground station is implemented as an embedded system that takes care of receiving radio data from the CanSat forwarding these to the remote user client and controlling the antenna direction The remote user client needs to be capable of saving the received data and representing this to the user Since a PC offers great conditions for data storage and representation the rem
208. scope For each task tested the ground station soft ware is patched in order to stimulate it to the worst case execution time for the specific task A patch for each test can be found on the CD The tests are performed with printf debugging disabled i e compiled with the command DFLAGS DDISABLE_PRINTE make environment overrides Each task ISR is tested as described in the fol lowing The patch for each test is shown as a cd reference ethSenderTask The ethSenderTask is upped to highest priority in order to avoid preemption by other tasks A task is added which fills up the Ethernet outgoing Queue with RUC packages of 8 byte in size thus a lot of RUC package assembling 163 Journal 5 Measurement of Worst Case Execution Times is required The IO pin is set to high as long as the ethSenderTask is running The laptop connects to the ground station through Ethernet and the width of the widest pulse is read out on the oscilloscope 34 uipPeriodicTask The same scenario as for the ethSenderTask is used The uipPeriodicTask is changed to highest priority and the IO toggling is assigned to this task When the laptop has established the connection the Ethernet cable is unplugged which causes the uipPeriodicTask to issue a retransmission The time spent by the retransmission is read out on the oscilloscope 35 encIrqHandlerTask The encIrqHandlerTask is upped to highest priority and IO tog gling is assigned to this task A PC program
209. sec 100 aot rot ory Bo Spb BE EEE hing o So ic Q al 50 100 i 90 T T D D o la amp SS ON ve was Coe al oc A nO a aa o 135 a e eee dice So eda EE ee T Ae sae oy lt igo E A ATA at ee eee rr 10 10 10 10 10 Frequency rad sec Figure 9 8 This figure illustrates the phase margin of the open loop system without lead compensation minimize the overshoot From figure 9 9 on the following page it is seen that in order for M to be 10 or less the phase margin should be 60 or higher Knowing that the phase margin of the system is 43 1 and needs to be 60 the phase lead can be calculated This is done by subtracting the PM at we from the wanted PM The value of z then becomes 16 9 this can be put into equation 9 26 on the preceding page 2 B tan So en SF 1 gt 8 1 35 9 27 With the values of 3 and we known the lead network can be found from equation 9 25 on the facing page o 1 ee el 135 s z 1 0 063 s 0 741 0 046 s 1 LEAD s 9 28 9 29 The phase margin of the system with the lead network incorporated can be seen in figure 9 10 on the next page The stability criterion is met due to a phase margin of 60 and thus no further frequency analysis of the elevation controller is necessary Effect of Design By designing the controller with a lead network no parameters are left to be chosen The effect of sample frequency steady stat
210. sed as a reference when designing the controller Chosen Controller It can be seen that the controller that has the best response to the step input is the lead controller with non linearity correction enabled This controller has the smallest overshoot and almost no steady state error It can furthermore be seen that after 200 ms the response never deviates more than 5 from the reference which is less than the maximum allowed deviation of 15 9 4 2 CanSat Launch Simulation This test is performed according to acceptance test 6 to test if it fulfills requirement 8 of the requirement specification The test procedure is described in test 6 of journal 4 on page 160 To test the performance of the tracking during launch of a CanSat the result from section 2 3 1 on page 9 is used to find the angular position of the CanSat during a launch This angle is applied as an input to the system This is a simulation of the elevation position that would be fed to the controller during launch The requirement of the controller is that it may never deviate more than 15 from the input reference value The input reference values are discretized to a sampling time of 200 ms as this is the sampling time for the GPS device in the CanSats Figure 9 24 on the next page shows the measured result to this input By inspecting the raw measurement data the maximum deviation between the reference and measured value is found to be 4 5 This is below the req
211. set the ground station location If no ground station location is set the automatic antenna tracking button is grayed out Notice this functionality is used for conformance class 2 only If no ground station location have been set the automatic antenna tracking button will be grayed out until it is The location is specified in GPS coordinates and thus entered in the same syntax as the GPS coordinates transmitted by the CanSat This is done to allow easier im plementation on the ground station The Set GS Location button seen in figure 10 9 sends a package of type 130 to the ground station as specified in the RUC protocol see appendix C on page 135 This package will contain the information typed into the 9 text fields To ensure that a valid GPS location have been entered in these text fields input validation is performed on all these text fields before transmission The Insert Latest GPS button seen on illustration 10 9 will auto fill the text fields with the latest GPS location received by the ground station from the CanSat This functionality will allow the user to quickly set the ground station location by simply holding the CanSat next to the ground station and clicking the insert latest GPS button followed by a click on the Set GS Location button 10 2 4 CanSat Commands The user must be able to send commands to the CanSat by typing them into the GUI The selected conformance class plays no role in this operation The CanSat co
212. sier if a maximum package size has been specified This way 1t is known how much buffer space to allocate for received packages This maximum package size will be specified as the package size before adding start and stop bytes and escape characters since it is expected that devices will be removing these bytes before saving them into a buffer The maximum package size has been chosen to be 150 bytes Since errors may occur in the bytes transmitted over the wireless link a way to ensure that the package was transferred without any errors is required For this a checksum field will be used Transfer of Telemetry Data Obviously it should be possible to transmit measured telemetry data from a CanSat to the ground station The measurement will likely happen at a fixed time rate e g 2 Hz Each time such a measurement has been performed it should be transmitted to the ground station If there is bandwidth and computation power left over it is better spent on increasing the rate at which measurements are taken and transmitted than using them on some acknowledgement scheme that ensures arrival of every measurement taken For this reason an unacknowledged transmission scheme will be used for this type of data where a CanSat just transmits a number of packages and the ground station receives as many of these as the circumstances allows it to Remote Control of CanSats It has been chosen that the students should be offered the possibility to p
213. sign 9 2 1 Design Strategy In figure 9 2 a general block diagram of a negative feedback loop can be seen This block diagram gives cause to some general equations that are used when designing the controller Direct term D s G s 9 1 Open loop L s D s G s H s 9 2 Closed loop T s i ET ie paler 9 3 e T s Direct term 9 4 I4 Open loop Y s Figure 9 2 This figure illustrates a general block diagram of a feedback loop R s is the setpoint E s is the error D s is the controller U s is the controller output G s is the plant H s is the feedback and Y s is the output of the system In the special case where the closed loop T s is a 2 order system as the one seen in eq 9 5 some clear design rules are specified for the time domain Let the 2 order system be written in the standard form 2 w T s 9 5 a 9 5 where wn is the natural undamped frequency rad s E is the damping factor E Then these design rules exists as derived in 31 2 Is 9 6 T Mp exp 9 7 p ss 9 7 ta at H s 9 8 where x is the percentage deviation when calculating settling time For 1 x 0 01 The above are design rules for the time domain and thus it is also necessary to analyze the design in the frequency domain Since the controller is implemented on a microcom puter it is necessary to determine at what frequency the controller should b
214. sign methods e g Bode plots For rotation on the azimuth axis a proportional con troller has been found sufficient For elevation a lead controller has been introduced in order to achieve the desired overshoot and rise time Verification of the controller has been performed by simulating a CanSat launch These tests have shown that the antenne position never deviates more than 5 from the virtual CanSat position A deviation of 15 is allowed The remote user client RUC developed in Java provides the user interface to the ground station This allows the user to easily control the system and save telemetry data Besides providing the user interface the RUC has eased the process of controller design with the ability to save antenna position data to CSV files A schedulability analysis of the ground station software has been performed The fixed priority scheduling scheme implemented in ARTOS has been found feasible The deadline of one of the rotary encoder s interrupt service routine may not be met though due to some problems configuring the microcontroller to use more than one FIQ Fast Interrupt Request This only seems to be a theoretical problem when considering the absolute worst case Fulfillment of Requirements Of the features specified in the requirements specification that has been implemented in the project only one requirement has not been met It has not been possible to achieve the required range on the wireless link
215. sion Upon reception of a package in one of the two links the package is decoded and the required action is performed immediately by performing synchronous calls to the antenna controller or ASER s to send package on the other link For example reception of telemetry data from the CanSat would result in an ASER to the Ethernet amp RUC protocol object asking it to forward the received data to the RUC 29 Chapter 4 Modularization RUC Controllnfo Package o gt A Ethernet amp RUC protocol Antenna Controller A ASER ethernetSend HSER calibrate HSER setAutoCtrl HSER setManualDirection HSER setGroundStationLoc HSER setControllerType HSER setNonlinearCompensation HSER setCanSatLoc Options 40 do PS data ASER sendCanSatCmd lt Cmd number 40 A RF Link amp WARP handler o RUC SatData Package gt Figure 4 4 RT HOOD Logical Architecture Design of the Ground Station Summary Above the basic platform for constructing the ground station system has been chosen Also the overall structure of the software to be executed on the ground station has been designed This allows for each ground station subsystem to be designed in detail and implemented independently The interface between the RUC and ground station is the application level protocol used on the TCP IP connection between them Th
216. sks the grey boxes access the uIP data and functions protected by mutual exclusion with the uipSemaphore The circles shows data flow labelled with type of data and origin In means the data is coming from the Ethernet and Out means the data eventually will be sent through the Ethernet 41 Chapter 6 Wired Communication with Remote User Client packets The functionality is structured into a periodic task called uipPeriodicTask as shown in figure 6 4 A third task is added to the Ethernet communication module which is responsi ble for sending RUC packages to the remote user client Because of the nature of uIP applications are only allowed to send TCP stream data when the appcall is in voked with the correct flags set In the used implementation data is only sent when the uip_poll flag is set which means that the connection has no outstanding pack ages The ethSenderTask shown in figure 6 4 will actively call uip_poll_conn whenever outgoing RUC packages are pending and the connection has no outstanding TCP packages The task is notified by encIrqHandlerTask through a synchronization semaphore ethCt sSem when there are no outstanding TCP packages The semaphore is not shown in the figure for simplicity The outgoing RUC packages are transferred to the ethSenderTask via a queue a system that will be described in further detail in the next section The three Ethernet tasks access the uIP library under mutual exclusion For t
217. stem defined it now becomes possible to analyze if they will meet their deadlines when everything is put together 11 2 Scheduling A multi tasking operating system has been implemented and discussed in chapter 5 The implemented preemptive scheduler is using a fixed priority scheme and has been configured to not preempt between tasks at equal priority i e no preemption on system ticks What characterizes scheduling in real time systems is that it has hard deadlines that has to be met In the following all the tasks of the ground station system will be analyzed in order to find deadlines ready time etc The goal of this analysis is to determine the priority assignment to tasks and if the system is schedulable i e if the system can meet the specified deadlines First of all some scheduling definitions and terms need to be introduced A task is a piece of work to be executed by the CPU Each task can be characterized in time with the following attributes Ready time is the instant in time where a task becomes ready for execution Interarrival time is the difference between two consecutive ready times If the inter arrival time is constant the task is cyclic Otherwise it is sporadic These terms maintains consistency with the equivalent HRT HOOD type of objects Sporadic tasks can have a mean and or minimum interarrival time associated to it In this analysis only minimum interarrival times Tmin are used Sporadic tasks are thus ana
218. sum is calculated from the complete package excluding the start and stop bytes the checksum field itself and without any byte stuffing i e without any escape characters inserted B 2 Type 0 Packages Type 0 packages are unacknowledged packages going from the CanSat to the ground station They will be sent with a fixed or variable time interval and contain the telemetry data measured on the CanSat as their payload The protocol makes it possible to detect if a package is lost in transit or contains errors on arrival Lost or erroneous packages are simply lost and cannot be reconstructed or requested re sent If adequate bandwidth is available the same package can be transmitted multiple times to increase the chance of a successful transfer Figure B 2 shows the layout of a type 0 package PKGtype Payload CTS SatID ae oxBE Package cres 8b 1b 3b 4b 16b 8b 8b Figure B 2 Layout of a type 0 package The fields in the package that are added to the general package layout are the following e Package The package number is used to make sure that the same package is not received twice and to detect if a package has been lost in transit The first package being transmitted will be package number 0 and the package number is then incremented by one for each new package sent If the same package is transmitted multiple times the package number should not be incremented If the package number reaches it s maximum value i
219. t in both directions due to Newtons third law of motion Since torque is defined as 7 r F and ignoring friction for now the following equations can be written Js Los a Em Ti 8 7 d JL f ate Fm 12 8 8 where Js is the moment of inertia of the motor side of the gear kg m ws is the angular velocity of the first cog wheel motor side pad ri is the radius of the first cog wheel motor side m J is the moment of inertia of side being driven through the gear kg m wr is the angular velocity of the second cog wheel pad ra is the radius of the second cog wheel m Ts is the torque provided to the first cog wheel by the motor Nm Fm is the force that affects both cog wheel through the belt N By isolating Fm substituting wz yz in 8 8 and inserting in 8 7 we have E Je d Ts v di 8 9 Where Next is the external gear ratio given by 2 Knowing the amount of torque transferred from load to shaft the total load torque that affects the rotor is then given 54 Section 8 2 Combining the Model by TA ES s Nex Z wm 1 as TW w 8 10 dt Where Nint is the internal gear ratio Since the moment of inertia of the motor shaft itself is small and furthermore is divided by Nint it can be neglected The expression is thus reduced to my d Next _ 74 Wea dy 11 TL 1 z T 8 11 JL d yt oer 8 12 a Next z dt Equation 8 12 thus defines the torque t
220. t should continue from 0 Payload The payload is the telemetry data measured by the CanSat The contents of this field consists of a number of measured data values The layout of this payload is not specified in this protocol but the basic datatypes that can be used to build this field are The list of allowed datatypes can be found below This way the user is able to construct a payload field that suits the types and number measurements the CanSat is taking and then feed these into both the ground station and the CanSat The ground station will then know how the layout of the payload field is and thus it can extract the values and present them to the user The 8 datatypes that can be used in the Payload field are the following 132 e signed unsigned char 8 bit integer e signed unsigned short 16 bit integer Appendix B WARP Protocol Specification e signed unsigned int 32 bit integer e float 32 bit TEEE 754 binary32 floating point number e text string The text string is a fixed length array of char s the length of this string is to be specified as part of the specification of the payload field layout It is recommended that ISO 8859 1 is used as the charset for these text strings but this is not required B 3 Conformance Class 2 Requirements Conformance class 2 devices are required to send GPS location data in each type 0 package that is transmitted This GPS location data is transmitted at the beginning of the payl
221. t the same as for the proportional controller The only difference is that the non linearity correction is added to the value ofoutput Proportional Controller with Lead Compensation To calculate the value of output equation 9 60 on the previous page is used As it is seen the expression needs both the previous input and output values The previous output and input value are saved in the end of the algorithm Proportional Controller with Lead and Non linearity Correction The calcula tion is done the same way as for the Proportional Controller with Lead Compen sation Non linearity correction is added to the value of output 9 4 Verification of Controllers In this section the designed controllers are tested to see if they perform as intended The setup of the azimuth and elevation controller most suited for a CanSat tracking is then 3 simulink con_dis_controller mdl 86 Section 9 4 Verification of Controllers tested according to acceptance test 6 to investigate if the system meets requirement 8 specified in the requirement specification A unit step is applied to each controller to test these This allows the theoretically calculated unit step response to be compared with the actually occurring unit step re sponse Since two different controllers have been designed for elevation multiple tests are performed on this controller The measurements are further documented in journal 4 on page 160 All graphs shown in
222. taken out of the other Since it s a wireless link no assurances are made that the bytes are transfered undamaged It is worth noting that often the rockets will bring multiple typically two CanSats into the air at the same time Measures must thus be taken to ensure the radio link will be working correctly even if multiple CanSats all using the WARP protocol are airborne at the same time There might also be multiple ground stations all using WARP It is desired however that different CanSats ground station pairs use different frequency bands for their communication so interference between them is avoided Package Delimiting A way to delimit each chunk of information is needed It has been chosen to use a package oriented protocol To delimit these packages a start and a stop byte will be used The advantage of using this scheme compared to fx having a length field in the packages is that it is known that if an unescaped start byte is received then that is the start of 11 Chapter 2 Preliminary Analysis the next package This will thus correct any errors in the transmission If only a length field was used errors in one of these length fields would result in all following packages not being received correctly since the package limits would be unknown This requires all occurrences of the start and stop byte to be escaped which will be done using byte stuffing Implementing devices that adhere to the protocol is much ea
223. tation to calibrate specifying automatic manual control specifying feed back controller type and asking to receive telemetry data backup Obviously latency here will result in a delay from the time the user specifies a setting to the time it takes effect This effect cannot be avoided If the latency is large it is possible that multiple configuration setting commands specifying dif ferent values for a setting will be stored in the network Since TCP guarantees correct reception order of the data the last issued setting command will be the one that is received last and thus also the setting that will be effective which is the desired behaviour CanSat commands from RUC to ground station and acknowledgment thereof When sending commands to the CanSat the WARP protocol specifies that the CanSat must acknowledge successful reception of the command This information should be passed to the user There might be a considerable delay from sending a CanSat command until it has actually been delivered The command has to be transferred from the RUC to the ground station then over the wireless link to the CanSat which then acknowledges the reception of the command Hereafter the ground station must forward the acknowledge to the RUC The part that is transferred over the wireless link may require some retransmissions if the link is bad which will further delay the delivery of the command If the user doesn t receive an acknowledge that h
224. te for this a lead network is incorporated into the controller In the following it is desired to have a proportional controller to compare to this lead controller For this proportional controller Kp is chosen to be the value between the two above ie Kp 17 3 Mp lt 0 1 exp Design of Lead Compensation The general expression for a lead network can be seen in equation 9 25 A lead network enables a controller to decrease the rise time while the overshoot remains the same This is done by raising the phase margin with a zero followed by a pole This increased phase margin then allows for an increase of the crossover frequency until the phase margin again is lowered to the original values The increased crossover frequency results in increased system bandwidth and thus lower rise time LEAD s 2 Pied 9 25 AS E where we is the crossover frequency rad s The value of P can be calculated with equation 9 26 b tan z y tan 91 1 9 26 72 Section 9 2 Controller Design where Pz is the phase lead rad The design of a lead compensation takes place in the frequency domain Knowing the minimum value of Kp the crossover frequency we is found The value of K should be higher then 23 2 and are therefore chosen to 25 In figure 9 8 the phase margin and we of the system can be seen The phase margin of the system can then be changed to Bode Diagram Gm Inf dB at Inf rad sec Pm 43 1 deg at 16 rad
225. tem at low motor input voltages The dry friction has a relatively large torque compared to the torque delivered by the motor in this case This could for example be caused by a slight deviation in the value of Te which was determined in section 8 5 2 on page 60 The steady state error is 0 5 determined by inspecting the raw measurement results This is a very small value and is considered an acceptable steady state offset Elevation For elevation 4 measurements have been performed They are seen in figures 9 22 and 9 23 on the following page The measurements for the proportional controller and for the lead controller show the same characteristics and deviations from the simulated responses Therefore they will be discussed collectively in the following The measured and simulated results doesn t follow as well as for azimuth The mea surements have a considerable higher overshoot This is probably caused by some de viation between the model and reality either some non linearity or inaccurate model parameter values It is here noted that the elevation model mainly differentiates from the azimuth model in two ways e The elevation is affected by gravity differently at different locations This non linearity has been tried cancelled by adding a non linearity correction It can be seen in the figures that the responses with non linearity correction enabled have 4 journals controller processing m 5 journals controller measuremen
226. the CanSat and ground station coordinates in the way described in section 9 3 3 on page 78 The function then sets the azimuth and elevation values used as reference by the controller Azimuth Controller The first thing to be done in the azimuth controller algorithm is to calculate the value of output output is calculated by taking the global variable desiredAzimuth and subtracting the value of encoderAzimuth The result is then multiplied by the chosen K The value of output can be both positive and negative depending on which direction the antenna should turn The output from the ARM board is a PWM signal which is always positive Thus in order to make the antenna turn in both directions the value of lastVal_azi_out is compared to the new output value and logic pins are asserted or cleared Finally the PWM duty cycle is set and the value of output is saved to lastVal_azi_out This algorithm can be put in a point form e Calculate output with output Kp desiredAzimuth encoderAzimuth e If lastVal_azi_out is gt 0 and the value of output is lt 0 turn the antenna CW Else if Last Val_azi_out is lt 0 and the value of output is gt 0 turn the antenna CCW Set the PWM duty cycle from the absolute value of output Save the value of output to lastVal_azi_out Because of dry friction the offset found in section 8 5 2 on page 60 is added to the value of output when setting the PWM duty cycle Elevation Controller The softwa
227. the bilinear transformation is used The bilinear transformation is a first order approximation of the natural logarithm function It maps the left half of the complex s plane to the interior of the unit circle in the z plane If the controller designed in continuous time is stable it will also be stable when converted to discrete time with the bilinear transformation The converting factor can be seen in equation 9 56 2 z 1 aia 9 56 where Ta is the sampling time s The required sampling frequency fs for the controllers are 40 Hz and 81 Hz for azimuth and elevation respectively These are minimum requirements It is not possible to run the controller software with a sampling frequency of 81 Hz because of the way ARTOS handles cyclic tasks more information about this can be found in chapter 5 on page 31 The only possible sampling frequency that meets the requirements is 125 Hz so the sampling time becomes 8ms With the sample time known the result of the bilinear transformation is 0 063 zs E 0 741 D z 25 9 57 0 046 zs 354 1 32 52 z 29 57 Re NA ca To implement the discrete controller into the software an inverse Z transformation needs to be done To make the system causal equation 9 58 is multiplied by z271 The expres sion for D z then becomes U z 32 52 29 57 27 O NS aT Om The difference equation can then be found by inspecting equation 9 59 to get u k 0 84 u k 1 32 52
228. the equation Steady State Error In the special case where H s is 1 the system type is the same as the number of poles in 0 of D s G s By solving the denominator in D s G s it becomes evident that the system has a pole in 0 This means that the system is a type 1 system and therefore has no steady state error ss if the input is a unit step When the input is a unit ramp ramp with slope 1 the ess is a constant and when the input is a parabola the ess will evolve towards infinity The equations for finding steady state errors are derived in 31 p 335 If the input is a ramp then ess can be calculated from ss ramp E rad 9 15 where Ky lim sD s G s 9 16 s gt 0 In this case 1 657 Ky li Ky K 0 473 K 9 17 230 O27758 3 5008 ao a Which means ss ramp is given by 2 116 ss ramp Kp 9 18 Frequency Analysis In order to choose a value for Kp a stability analysis needs to be performed This takes place in the frequency domain In figure 9 4 on the following page a bode plot of L s where K is the highest allowable value can be seen It is evident from figure 9 4 on the next page that when 13 6 lt K lt 19 1 the system is stable The minimum phase margin is approximately 60 If K is chosen to the largest possible value then wgw is given by T s 3dB gt w amp 12 5 rad s 9 19 This means that ws gt 20 12 5rad s which equals fs gt 40 Hz The sample fre
229. the following are produced with the Matlab script 4 9 4 1 Step Responses Figures 9 21 9 22 and 9 23 on the next page show measured and simulated response for a step input to the azimuth elevation with proportional controller and elevation with lead controller respectively The step is applied at time t 0 1s A step of 20 has been chosen as a compromise between a small step which would result in large influence by non linearities for small voltages and a large step which result in the voltage fed to the motor to reach saturation For the elevation control the measurements have been carried out with and without the non linearity correction The steps for elevation have been performed from an antenna location of 20 tilt to a 40 tilt in order for the non linearity problem to be present Here follows a discussion of the results Azimuth For azimuth only a proportional controller has been designed Measured and simulated response to an input step of 20 is shown in figure 9 21 on the following page It can be seen that the simulated and measured response are almost identical By inspecting the graph it is also seen that the requirements set to tp and Mp which respectively are 200 ms and 10 almost are met precisely There is a slight steady state error for the measured response which theoretically should not be present because the system is of type 1 This steady state error is most likely caused by some non linearities for the sys
230. tion can be specified in the RUC and sent over the Ethernet link The Ethernet software then calls setGroundStationLoc with a pointer to the package containing the GPS data The data is split in to altitude latitude and longitude by the function convertGPSstrToCoord The controller can now use these values as reference points to the GPS data sent from the CanSat It is possible to choose between a proportional and a lead controller The idea is to observe and demonstrate what the difference in performance of the controller will be A package can be sent from the RUC to the ground station with a num ber This number indicates which controller type that should be used The Ethernet software can then call to different functions depending on the number The function setControllerType sets controller to run with or without the lead compensation The function setNonlinearCompensation indicates if the non linearity correction should be on or off in the controller It should be noted that it is only possible to alter the elevation controller When the wireless link receives a CanSat package with GPS data the wireless soft ware seen in figure 7 1 on page 48 calls the function setCanSatLoc with the GPS data The data is first split into altitude latitude and longitude Afterwards the func tion updateAzimuthElevation is called if the controller is in auto mode This 83 Chapter 9 Feedback Control of Pan amp Tilt Platform function interprets
231. tion data measured lt gt 158 Journal 3 Model Parameter Determination Results CSV files containing the collected data can be found on the CD 09 The dataset consists of the angular position in degrees multiplied by a factor 10 and a timestamp measured in milliseconds The dataset has been trimmed by removing all data points up until the point where voltage is applied 26 4ournals parameter_determinat ion data measured lt gt 159 Journal 4 Controller Verification Journal 4 Controller Verification 4 1 Purpose The purpose of this test is to determine if the controllers designed in chapter 9 on page 65 functions as intended and whether the system meets requirement 8 in the requirement specification seen in section 3 2 on page 17 For this purpose several tests will be done 4 2 Test Object The test object is the fully implemented system described in chapter 4 on page 23 Used Equipment Instrument AAU No Make and type Alternative RUC Added Curvetracer function Table 4 1 Equipment used in the test In this journal an alternative RUC is used This version has a button added that makes the ground station trace the curve on figure 2 3 on page 11 This way a CanSat launch is simulated 4 3 Approach The RUC establishes a connection to the ground station and an arbitrary CanSat ID is entered In test 1 through 4 a controller type will be selected and the wanted elevation position will be changed
232. to any multi tasking operating system This section will look into the concept of a real time operating system A real time system can be defined as a system which maps a sequence of real time events to another sequence of real time events A real time operating system makes it feasible for the programmer to specify an appropriate response to a real time input sequence 16 A task in a real time system is associated with a deadline which is the instant in time where the task has to be finished executing Tasks can be categorized as hard real time if the deadline may never be missed and soft real time if the deadline is specified as a mean value that the task can miss from time to time without fatal consequences as long as the deadline is met when taking the average of completion times Scheduling is the discipline of sharing CPU time between a set of tasks Scheduling algorithms have different goals depending on which type of systems they are designed for For some systems maximizing job throughput may be the primary goal For real time systems the scheduler s primary goal is to pick tasks in such a way that all deadlines are met 17 The scheduling scheme can be preemptive or non preemptive A non preemptive scheduler won t pick a new task before the current task releases the CPU voluntarily This approach is simpler compared to a preemptive scheduler but it is not well suited for real time systems with several aperiodic tasks Furthermore sched
233. ts and their relations 4 3 1 Usage in This Project The design life cycle of HRT HOOD is shown in figure 4 2 on the next page It starts out with the requirements specification after which the logical architecture design is done It is here the decomposition into objects is done The physical architecture design maps the designed system onto the platform hardware and kernel available Schedulability analysis is performed to analyze if the platform is sufficiently powerful for the job Detailed design and coding follows implementing the software At last HRT HOOD specifies that testing should be done As with all software design methods a perfect design cannot be made the first time so some iteration between the design stages is to be expected as shown by the arrows to the left in figure 4 2 on the following page In this project the HRT HOOD design life cycle is not used as described above The decomposition is started below to specify which subobjects should be constructed and the interface between them Only a first level decomposition is performed here 27 Chapter 4 Modularization Requirements Definition Logical Architecture Design Decomposition into objects Physical Architecture Design Schedulability Analysis y Detailed Design Y Coding Including code timing estimations Testing Including code timing measurements Figure 4 2 Life cycle of the HRT HOOD design method 13 When designing and impl
234. ts stepaziRegInfo csv 87 Chapter 9 Feedback Control of Pan z Tilt Platform Azimuth proportional contoller 25 T T T T T T T T T 20F F En VII E d 15 J Cc O 3 10H o o Reference A E O AA SD EE Simulated E Measured 0 i i i i i i i I I 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 1 1 Time s Figure 9 21 Simulated and measured response to a 20 step for azimuth Elevation proportional contoller gom DA ESTOT A E oe nan rs EE o J 7 x X 25t J P 207 r de AA ASP S 15 4 OD 10 Reference perce Simulated SP Measured w o non linearity correction Measured w non linearity correction 0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 1 1 Time s Figure 9 22 Simulated and measured response to a 20 step for elevation with proportional control Elevation lead contoller T T T T T T T T T 25 ee 20 en i Seger ar a Sa rr a 3 Tar 7 T Tr 0 2 15 Hain Se Bch Ge Ug adios La A A A IOS aE Bs A op Vy dass ORs A N g uke NRO 6S dB GW ve GAMO O Shs ET 4 9 E a 107 a E Reference 5l un Simulated Measured w o non linearity correction Measured w non linearity correction 0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 1 1 Time s Figure 9 23 Simulated and measured response t
235. ttp geography about com library faq blqzcircumference htm 35 STMicroelectronics L298 dual full bridge driver Jan 2000 0 36 Oracle and or its affiliates Concurrency in swing 2010 downloaded 30 11 2010 Online Available http download oracle com javase tutorial uiswing concurrency index html 37 Oracle and or its affiliates Class swing utilities 2010 downloaded 30 11 2010 Online Available http download oracle com javase 7 docs api javax swing SwingUtilities html invokeLater java lang Runnable 38 Arduino cc ArduinoBoardProMini Downloaded 14 12 2010 Online Available http arduino cc en Main ArduinoBoardProMini 39 EngineeringToolbox com Moment of inertia downloaded 03 12 2010 Online Available http www engineeringtoolbox com moment inertia torque d_913 html 14 datasheets L298_H_Bridge pdf 127 Appendices 129 Appendix A Word List Appendix A Word List This appendix contains a list of abbreviations and terms used throughout the report The list is made to help the reader gain a better understanding of the report content and should therefore be carefully read before reading the report itself Abbreviations WARP RUC GS ARTOS Terms upper secondary school ground station remote user client telemetry data event log telemetry data backup elevation azimuth 130 WARP is a recursive acronym for W
236. ture and air pressure These data must then be transmitted to the ground station at least once every second after release and during descend In addition to this primary mission a secondary mission of free choice must be accomplished The secondary mission can be anything as long as it has some technological investigative or innovative value It could for example be Advanced Telemetry measurement of acceleration GPS location or radiation lev els Telecommand having the ground station send commands to the CanSat Comeback have the CanSat autonomously navigate to a target land point e Landing System a safe landing system such as a bespoke parachute or airbag Chapter 2 Preliminary Analysis e Planetary Probe Simulate an exploration flight to a new planet e g taking mea surements on the ground after landing The rules for the competition are not directly targeted at the ground station they specify requirements such as size and weight of the CanSat itself The specific rules will thus not be mentioned here but they can be found on the ESA website 5 2 2 System Overview The purpose of this project is to design and build a ground station for CanSat satellites This ground station must be able to receive data from and send data to the CanSats constructed by other groups 2 2 1 Project Contents In previous years a directional antenna has been used to receive the radio signals from the CanSats This is due to t
237. ty of the uipPeriodicTask has been chosen to be the highest of the Ethernet tasks as it is responsible for retransmission upon ACK reception timeout and since it is desirable to retransmit as soon as possible in order to minimize the effect of lost packages Interarrival amp Deadline Times In order to deal with the Ethernet tasks in the schedulability analysis they will first be regarded as a number of independent tasks to include their direct computation time Afterwards the effect of them being executed under mutual exclusion will be analysed In order to assign timing attributes to the tasks they will be analysed in the case of highest possible throughput requirement in which the following statements apply e ethSenderTask will converge towards the most effective sending scheme as de scribed above ie each TCP package will be filled e ethSenderTask will only start executing when encIrqHandlerTask has re ceived a TCP ACK ethSenderTask can thus never starvate encIrqHandlerTask e The time for computation time for the encIrqHandlerTask receiving a single ACK and signalling the ethSenderTask is not included in the computation time of the ethSenderTask and is considered negligible compared to the worst case execution time of the ethSenderTask e The I O buffers of the ethSenderTask and encIrgHandlerTask are assumed to be sufficiently large to never overflow In order to find the interarrival time of the ethSenderTask in the wo
238. uired 15 and requirement 8 from the requirement specification has thus been fulfilled This simulation is based on the ground station being located 400m from the launch site It is assessed that because the maximum deviation is allowed to be 15 it wouldn t be a problem having the antenna platform placed closer to the launch site even though this would result in a faster rising curve By inspecting figure 9 24 on the following page in detail it can be seen that the movement of the antenna is jerky This happens because the controller is so fast that it is almost able to follow the stair case curve fed as input This may be more obvious 6 journals controller measurements curvetraceLeadnonRegInfo csv 89 Chapter 9 Feedback Control of Pan amp Tilt Platform Measured tracking of simulated launch a o al o o o o wm o Position deg ye o o L Measured A Reference 0 oe i i i i i i i i i i 1 0 05 1 15 2 25 3 35 4 45 5 55 6 65 7 Time s Figure 9 24 Measured response to an input reference simulating the launch of a CanSat Lead controller with non linearity correction enabled by looking at the graph in matlab where it is possible to zoom in see Y This may damage the motors over time because of the peaks in current from stopping and starting the motors rapidly It could thus be an idea to extrapolate the input data to give a mo
239. uling algorithms are categorized based on their execution time sharing scheme The following well known categories exists 18 Fixed schedules The schedule is defined pre runtime simple efficient but less flexible Round robin Each task is given an equal time slice simple flexible but less efficient Fixed priorities Priorities are assigned pre runtime The highest priority ready task will run simple and flexible but medium efficiency Dynamic priorities Priorities are assigned based on runtime parameters e g earliest deadline first complex flexible and efficient Within the prioritized schemes effort goes into assigning tasks the most optimum pri ority This requires characterization and analysis of each task which will be done in chapter 11 The scheduler scheme chosen for ARTOS is fixed priority because of its 35 Chapter 5 Real Time Operating System simplicity over dynamic priorities This requires the scheduler to be able to do preemp tion Preemption happens when a higher priority task becomes ready Furthermore the scheduler can be configured on compile time to do round robin scheduling between tasks of the same priority by setting the preprocessor variable OS_SYSTICK_RESCHEDULES This will make the timer interrupt handler reschedule on every tick Otherwise switching between equal priority tasks will only happen when the task runs to completion This way is preferred and used on the ground station because it is wante
240. und station and the satellite must be within radio communications range the distance between them will always be relatively small Therefore the azimuth and elevation can be calculated through a simpler albeit approximated method By using the approximated method the curvature of the Earth is assumed to be negligible within the area of interest and the GPS coordinates are treated as if they were Cartesian The procedure is as follows 1 Degrees and minutes are combined as a floating point degree value for both latitude and longitude 2 A conversion factor for the current latitude is calculated The longitude factor is assumed constant for all coordinates 3 The conversion factors are applied to latitude and longitude to convert the degrees to meters 78 Section 9 3 Implementation Longitude lines Lines with constant latitude Small area of approximation Latitude lines Lines with constant longitude Figure 9 14 An illustration of latitude and longitude coordinates and the approximation used 4 The ground station position is subtracted from the satellite s and the ground station is placed at the origin of the coordinate system The conversion factors are used to convert the longitude and latitude coordinates to meters In doing this it is assumed that the Earth is a perfect sphere whereby the distance between two consecutive degrees of latitude is the same everywhere Thus the conversion
241. ven moment Notice the half power beamwidth is determined by the utilized ground station antenna 18 Section 3 3 Acceptance Test Specification 3 3 Acceptance Test Specification The purpose of this section is to describe which tests needs to be performed on the designed system to ensure that it meets the system requirements The requirements can be seen in section 3 2 on page 17 These tests are as follows to see more details about how these tests are performed see chapter 12 on page 117 Test 1 Covers Requirement 1 and 2 Packages adhering the WARP protocol are sent to the ground station On the RUC an Ethernet connection is established and a specific package format from a specific CanSat ID is to be expected The packages send will be marked as originating from two differ ent CanSat s by setting different CanSat ID s in the packages These packages will be transmitted for at least five minutes The packages with the matching CanSat ID must be transmitted at least five times per second In order to pass this test the system must filter out the packages with the wrong CanSat ID It also has to retrieve the data from all the correctly received packages with the matching ID and display these on the RUC Test 2 Covers Requirement 3 A CanSat telemetry data package is sent to the ground station Once this is received a timer will be started The ground station will then prepare a package containing the received data for the RUC pr
242. vides an additional 100 ms for the mentioned acceleration and deacceleration In section 2 3 1 on page 9 the maximum deviation between the direction to the CanSat and the direction fed into the controller is determined to be 10 The half power beamwidth of the antenna is 25 which allows the controller to deviate up to 15 from the wanted direction Assuming that the maximum velocity of the antenna and thus the maximum overshoot will occur at a step of 50 this will allow an overshoot of Los 100 30 This is a fairly large overshoot and the maximum overshoot is set to 10 instead The above leads to requirements for the maximum overshoot Mp and the rise time t of the system e M lt 10 e t lt 100ms Azimuth Requirements The requirements outlined address the elevation controller and are therefore not appli cable for the azimuth controller The requirements for the azimuth controller are not as strict since the CanSat will not move as fast in this direction The requirements are set to e M lt 10 e t lt 200 ms 9 2 Controller Design The pan and tilt platform needs two separate controllers one for the azimuth direction control and one for the elevation direction control The models for each plant to control are derived in chapter 8 on page 51 As seen this gives two second order systems The task is to design the controllers so they meet the requirements set above 66 Section 9 2 Controller De
243. y with CanSat s The remote user client and ground station can communicate through an Ethernet link eg over the internet The ground station is designed as an embedded system and connected to a pan amp tilt platform with two PWM powered DC motors and an Yagi Uda type antenna at tached As the platform for the ground station software a preemptive real time operating system is designed and implemented on an ARM based microcontoller The pan amp tilt platform is modeled as two independent second order systems Non linear corrections are intro duced in order to compensate for the non linear nature of the friction and gravity affecting the platform Feed back control is designed using frequency domain design methods The user interface to the system is the remote user client developed as a Java based GUI application This pro gram allows the user to remotely control the ground sta tion and send commands to the CanSat It also han dles and saves incoming CanSat telemetry relayed by the ground station Conclusion The final system is able to accommodate most of the requirements The antenna controller system has been shown to be able to follow a simulated launch of a CanSat With further development it is possible to make the ground station system feasable for use in CanSat competitions The contents of this report is freely available but publication with source reference is only permitted as agreed with the author
244. ystem is the resource manager The simplest form of multi tasking comes with the introduction of hardware interrupts It is then possible to react on interrupts quickly in the interrupt service routine ISR and pass on time consuming work to the main program This concept is taken to the next step in a multi tasking operating system where the workload is passed between tasks in the main program as well In modern operating systems there is usually two types of tasks divided into processes and threads The main difference is most often that threads share their memory space and processes do not In ARTOS there is only one memory space since the hardware platform does not have a memory managing unit MMU Thus there is only one type of task in ARTOS Each task is represented in memory by a task descriptor struct taskDescriptor struct taskDescriptor nextTask Pointer to the next task x int32_t context 17 Saved task context RO R14 SR PC x uint32_t priority Priority of the task void stackBase Lowest address in stack x uint16_t stackSize Stack size in bytes x y The task descriptors are allocated by the user mode programs which means the OS supports an arbitrary number of tasks Every task has its own stack space which is also provided by the user mode program The programmer must assure that a task never uses more stack space than is assigned to it or the whole system will have unpredicted behaviour Ther

CanSat Ground Station

Contents

Download Pdf Manuals

Related Search

Related Contents