Dane Sabo
8184e48dd3
M .task/backlog.data M .task/completed.data M .task/pending.data M .task/undo.data M Writing/ERLM/main.aux M Writing/ERLM/main.fdb_latexmk M Writing/ERLM/main.fls M Writing/ERLM/main.log
36 lines
1.3 KiB
Markdown
36 lines
1.3 KiB
Markdown
Okay so here's how things will go:
|
|
|
|
Integrate V design into the workings here
|
|
|
|
1. Requirement identification and translation
|
|
1. Point towards hardens lando thing
|
|
2. we're going to do a nuclear start up sequence
|
|
|
|
2. Synthesize requirements into a discrete automata
|
|
1. this makes up our mode switching behavior
|
|
2. There's probably going to be a serious amount of
|
|
refinement required here
|
|
3. Figure out by the structure of the nodes what the
|
|
purpose of the mode is
|
|
1. Do all traces leave? Do any traces leave? What
|
|
does this mean for the FUNCTION of the node?
|
|
|
|
3. Build controllers that satisfy each mode requirement
|
|
1. Reachability to ensure valid input and output sets?
|
|
2. We can ensure zeno behavior won't happen by looking
|
|
at the interface between modes
|
|
3. We should also see based on reachability that a well
|
|
built controller ONLY can enter the modes as
|
|
specified by the discrete automata
|
|
4. Contract based methods?
|
|
|
|
4. Fuck it man, that's like your provability or whatever
|
|
man.
|
|
|
|
What are the critical needs?
|
|
1. We need a way to build some operating procedures into
|
|
controllers for autonomy
|
|
2. How the hell do we know what the goals of each mode are?
|
|
3. How do we know for sure the continuous dynamics will
|
|
actually get us there?
|