psas.pdx.edu
Download
Report
Transcript psas.pdx.edu
2005/06 Capstone Avionics Systems
Team Project
Project Title: The Node
Front End design for
the PSAS LV2b
Avionics System
Members:
Sarah Bailey
Jacob Davidson
Glenn LeBrasseur
Date: 2006-2-3
2005/06 Capstone Project Team
Team members:
Sarah Bailey
Jacob Davidson
Glenn LeBrasseur
Industry sponsor:
Andrew Greenberg
Faculty advisor:
Mark Faust
Who are our customers?
Our single customer is the Portland State
Aerospace Society (PSAS)
PSAS is currently in the process of designing
their fourth rocket or launch vehicle (LV) titled
LV2b
Our Capstone Team will produce the interface
electronics of all of the LV's avionics systems
Redesign of a network based open
avionics system
What is it?
Why is it needed?
To ensure the integrity of the data the rocket generates and
its safe recovery from a flight, all systems within the rocket
must reliably interface with each other
What needs to be done?
The common electronics which will control the interfacing of
the various LV avionics systems
Design and build the interface circuitry
What will be produced?
A two-layer PCB containing the electronics implementing the
interface
Who is the Portland State Aerospace
Society (PSAS)?
Founded in 1997
First US student chapter of the Aerospace and
Electrical Systems Society (AESS) which is a
technical society of the Institute of Electrical and
Electronics Engineers (IEEE)
As far as the group knows, they are the most
advanced amateur rocket group in the world
PSAS designs, builds and launch amateur
rockets or launch vehicles (LV) into the lower
atmosphere
What is the purpose of PSAS and
their objectives?
Pioneering active guidance and open source
software and hardware aerospace systems
Long term goal:
Design, build and put a “nanosatellite” into Earth
orbit
What are the future plans for PSAS?
Design their fourth rocket, LV2b, which will be a
research platform for active guidance
The rocket will consist of a network of nodes,
each doing a specific function
The following is the block diagram of the LV2a
avionics system:
We are going to redesign the old
node interface of each node
LV2b nodes
MASTER NODE: Flight Computer (FC)
Amateur TV (ATV)
Inertial Measurement Unit (IMU)
Global Positioning System/Satellite (GPS)
Environmental Sensors
Magnetometer
Recovery Node
Where does the Capstone team fit
into PSAS plans?
We are in charge of designing the common
electronics that run all of the avionics nodes
Called a node front end, it includes:
32-bit microcontroller
Switching power supply
Communication bus interface
Block diagram of LV2b Node Front
End
LV2b Avionics Node
Switching power
supply
32-bit
microcontroller
Power
bus
Comm bus
Node Front
End
Application specific
circuits (e.g. IMU,
GPS)
What are the deliverables required
of the Capstone Team?
Design of the node front end
Schematic capture and PCB layout
Design notes
Front End prototype which includes:
Commercially built two-layer PCB
Populated and tested components
A white paper of the node front end design
What is the Node Front End?
(Example: Recovery Node)
What is the Node Front End?
Designed for PSAS
Used with every Avionics Node
Communications relay
Local processor for sensor data
Supplies power
Node Front End Environment
Rocket Environment:
-5o C to +40o C
Intense vibration
Acceleration up to 20 g
EMI (10MHz to > 2.4GHz)
Test Environment
frequent handling and transport
frequent power and communications
connect/disconnect
Front End Constraints
Should be < $150
Must be very robust
Immune to EMI
1" x 2" in size
< 0.5" thick
Power consumption <= 190mW
Condition power bus (10-20V) to required
voltages for the node
Parts Constrains
Parts should be
surface mount
able to be routed on a two-layer board
connectors should lock down during flight
Board may have a conformal coating
Redundant external connectors
Reproducibility
COTS components
open source or free software
documentation
PSAS wiki
design notebook
white paper
Power Supply Requirements
must condition 10V to 20V input to required
node voltage
> 70% efficiency
EMI from supply should not interfere with other
systems
external shutdown control
undervoltage lockout
overvoltage protection
current limited
Communications Bus Hard
Requirements
Must handle
shorts and opens on PHY layer
acceleration and vibration
Must prioritize messages
EMI
System critical messages should be sent, even at
the expense of non-critical messages
bandwidth >= 1Mbps
Communications Bus Soft
Requirements
“Shoulds”:
software handling retransmission
Faulty nodes can be shut down by FC
previous use in critical real-time systems
easy interface to laptops
node controllers flashed over bus
existing bus protocol drivers
CAN vs. USB
differential bus
differential bus
1Mbps
12Mbps
CAN in cars
message-by-message
prioritization
peer-to-peer
automatic
retransmission
USB in medical
devices
bandwidth
prioritization
mastered bus
depends on transfer
type
CAN vs. USB
laptop interfaces
through special
hardware
PSAS members wrote
CAN drivers for PIC
no CAN drivers for
Linux or eCos
laptop can directly
plug into the bus
local contacts who
wrote USB drivers
Linux has many USB
drivers
eCos has hardwareindependent USB
driver framework
Microcontroller Requirements
Needs:
32-bit, >= 128K flash, >= 32K SRAM
> 10 MIPS (around 60 MIPS is the goal)
OSS tools like gcc, gdb, or binutils
open debugger protocol (e.g. JTAG)
Usable packaging
QFP, less than 144 pins (64 pins is ideal)
BGA < 32 pins (with commercial mounting)
communication bus connection (USB or CAN)
Microcontroller Requirements
Wants
multiple implementations from more than one
manufacturer
integer math ALU, 10 bit ADC, 3 PWM, watchdog
timer, brown out reset
reasonable voltage requirements (3.3V only or
3.3/5V)
existing open source RTOS, like eCos
low power modes
low cost