When/Where:
- FAB155, 7:00 pm - 10:00 pm
Attendees:
- ?JamesPerkins, AndrewGreenberg, ?PaulMullen, ?NathanDavenport, ?MarkusWeltin, ?ThomasLong, IanOsgood, ?DavidCassard, Stephan Scheller, Mark Ceisel, ?JayBeck
Agenda:
A discussion leader is listed in parentheses
- Discuss what sort of things we can have remote folks do (Andrew)
- Get everything compiling and development platforms standardized (James)
- Get all the wireless links talking to each other again (James)
- Discuss Launch Console Requirements (Karl)
- Can message test code design (Karl)
- Protocol additions for rocket state (James)
- Display requirements for rocket state vs. sensor data (James)
- Protocol router (Tom)
- CAN Bus IDs revisited (Andrew)
Things Remote People Can Do:
- Andrew gave us an overview of the basic application and identified software and avionics tasks.
- Java - rocketview (David), launchcontrol (Karl), CAN socket
- C - flight computer (James), Launch Tower Computer (Ian), and Infrastructure - CAN driver, RTLinux port, Boot stuff, shutdown?
- PIC - APS, GPS, IMU, ATV
- UDP packet router (Tom)
- CAN ID language convertor (Trevor)
- Other areas: antenna (Tom), poweramps, CANtalope (Larry), sysadmin (Cere?)
- Jay observed we need someone to help bring up folks on the development environment -- Andrew pointed out it is hard to do this until after the launch our main staff is regrettably overworked.
- TWiki registration at http://twiki.psas.pdx.edu
- Code at http://cvs.psas.pdx.edu
Assignments
- Tom - packet forwarder but esp. Antennas & physical design thereof
- Jay - antenna fabrication work?
- Stephan and Mark - RTLinux setup
Get everything compiling and development platforms standardized (James)
We need to get everything compilable on one machine. This is where the DevelopmentEnvironmentForLv2 comes into play. Our current problems include code using Java 1.4 extensions which are not supported on Debian testing, and various improvements breaking APIs.
Fortunately we can roll back to the pre-USENIX code, but we should try to get the new stuff working. Karl will be an important person in getting this working.
Get all the wireless links talking to each other again (James)
More properly, get all the network protocols working between the various network applications. In order to do this, I'd like to see all network applications able to handle some standard command-line arguments, probably:
-local <ipaddress>[:<port>]
-remote <ipaddress>[:<port>]
This should allow us to run several network elements of the application on our development workstations, and improve our testing environment as a result.
Discuss Launch Console Requirements (Karl)
Karl wasn't here, and Andrew suggested this be left for a later, small discussion.
Can message test code design (Karl)
I think some of the need for this may be improved by being able to test a larger amount of the system together. Alternatively, we could inject dummy "messages" into the Linux CAN Driver using an ioctl (and be able to pluck them out as well). I wonder what thoughts Karl had.
Protocol additions for rocket state (James)
James noted that we are going to need to add messages to the protocol to support interpretations that the flight computer application has to share with the world... overall system state, test results, calculated physical data, and the like. It did not seem to be the place in the meeting today to detail these.
Display requirements for rocket state vs. sensor data (James)
James was concerned about what rocketview needs to display. There were three possible types of data: CAN messages that rocketview has interpreted, position data that the flight computer interpreted and sent along, and an overall model of the planned flight -- and be able to display these together during flight.
Andrew thought this isn't such a great idea because the only really critical piece of data that we can do anything about on the ground is the expected time to apogee based on a timer, which is reset only on major discrete events (launch detect, mostly). Otherwise, the displayed position data should be those reports interpreted by the flight computer -- only the flight computer has access to all the data.
A detailed physical model that could be updated in real time with information from the rocket (possibly lossy due to connectivity problems) would be nirvana, but... not only does it require more human resources than we have, and is a hard problem, it just doesn't really matter much because the only thing we really have control over is the 2m recovery backup radio message to fire the chutes... so a single "Time to expected apogee" is about all that makes sense.
Protocol router (Tom)
Tom has found a port forwarder package to route UDP packets from the flight computer to telemetry computer network (net 10.0.0) onto the general ground listener network (net 192.168.x.*).
CAN Bus IDs Revisited (Andrew)
Andrew and Tim had a five hour discussion about CAN IDs (before this meeting, fortunately, or I would have died of boredom) and came up with a new model that will fit better with what we need to do (which I think is really neat). I wrote notes on it here, but they have been factored off to the CanBusIDs Twiki page.