|
Clingo C API
C API for clingo providing high level functions to control grounding and solving.
|
Extend the search with propagators for arbitrary theories.
For an example, see propagator.c.
Classes | |
| struct | clingo_propagator |
| An instance of this struct has to be registered with a solver to implement a custom propagator. More... | |
Typedefs | |
| typedef struct clingo_assignment | clingo_assignment_t |
| Represents a (partial) assignment of a particular solver. More... | |
| typedef int | clingo_propagator_check_mode_t |
| Corresponding type to clingo_propagator_check_mode_e. | |
| typedef int | clingo_weight_constraint_type_t |
| Corresponding type to clingo_weight_constraint_type_e. | |
| typedef struct clingo_propagate_init | clingo_propagate_init_t |
| Object to initialize a user-defined propagator before each solving step. More... | |
| typedef int | clingo_clause_type_t |
| Corresponding type to clingo_clause_type_e. | |
| typedef struct clingo_propagate_control | clingo_propagate_control_t |
| This object can be used to add clauses and propagate literals while solving. | |
| typedef bool(* | clingo_propagator_init_callback_t) (clingo_propagate_init_t *, void *) |
| Typedef for clingo_propagator::init(). | |
| typedef bool(* | clingo_propagator_propagate_callback_t) (clingo_propagate_control_t *, clingo_literal_t const *, size_t, void *) |
| Typedef for clingo_propagator::propagate(). | |
| typedef void(* | clingo_propagator_undo_callback_t) (clingo_propagate_control_t const *, clingo_literal_t const *, size_t, void *) |
| Typedef for clingo_propagator::undo(). | |
| typedef bool(* | clingo_propagator_check_callback_t) (clingo_propagate_control_t *, void *) |
| Typedef for clingo_propagator::check(). | |
| typedef struct clingo_propagator | clingo_propagator_t |
| An instance of this struct has to be registered with a solver to implement a custom propagator. More... | |
Enumerations | |
| enum | clingo_propagator_check_mode_e { clingo_propagator_check_mode_none = 0, clingo_propagator_check_mode_total = 1, clingo_propagator_check_mode_fixpoint = 2, clingo_propagator_check_mode_both = 3 } |
| Supported check modes for propagators. More... | |
| enum | clingo_weight_constraint_type_e { clingo_weight_constraint_type_implication_left = -1, clingo_weight_constraint_type_implication_right = 1, clingo_weight_constraint_type_equivalence = 0 } |
| Enumeration of weight_constraint_types. More... | |
| enum | clingo_clause_type_e { clingo_clause_type_learnt = 0, clingo_clause_type_static = 1, clingo_clause_type_volatile = 2, clingo_clause_type_volatile_static = 3 } |
| Enumeration of clause types determining the lifetime of a clause. More... | |
Assignment Functions | |
| CLINGO_VISIBILITY_DEFAULT uint32_t | clingo_assignment_decision_level (clingo_assignment_t const *assignment) |
| Get the current decision level. More... | |
| CLINGO_VISIBILITY_DEFAULT uint32_t | clingo_assignment_root_level (clingo_assignment_t const *assignment) |
| Get the current root level. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_has_conflict (clingo_assignment_t const *assignment) |
| Check if the given assignment is conflicting. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_has_literal (clingo_assignment_t const *assignment, clingo_literal_t literal) |
| Check if the given literal is part of a (partial) assignment. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_level (clingo_assignment_t const *assignment, clingo_literal_t literal, uint32_t *level) |
| Determine the decision level of a given literal. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_decision (clingo_assignment_t const *assignment, uint32_t level, clingo_literal_t *literal) |
| Determine the decision literal given a decision level. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_is_fixed (clingo_assignment_t const *assignment, clingo_literal_t literal, bool *is_fixed) |
| Check if a literal has a fixed truth value. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_is_true (clingo_assignment_t const *assignment, clingo_literal_t literal, bool *is_true) |
| Check if a literal is true. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_is_false (clingo_assignment_t const *assignment, clingo_literal_t literal, bool *is_false) |
| Check if a literal has a fixed truth value. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_truth_value (clingo_assignment_t const *assignment, clingo_literal_t literal, clingo_truth_value_t *value) |
| Determine the truth value of a given literal. More... | |
| CLINGO_VISIBILITY_DEFAULT size_t | clingo_assignment_size (clingo_assignment_t const *assignment) |
| The number of (positive) literals in the assignment. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_at (clingo_assignment_t const *assignment, size_t offset, clingo_literal_t *literal) |
| The (positive) literal at the given offset in the assignment. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_is_total (clingo_assignment_t const *assignment) |
| Check if the assignment is total, i.e. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_trail_size (clingo_assignment_t const *assignment, uint32_t *size) |
| Returns the number of literals in the trail, i.e., the number of assigned literals. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_trail_begin (clingo_assignment_t const *assignment, uint32_t level, uint32_t *offset) |
| Returns the offset of the decision literal with the given decision level in the trail. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_trail_end (clingo_assignment_t const *assignment, uint32_t level, uint32_t *offset) |
| Returns the offset following the last literal with the given decision level. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_assignment_trail_at (clingo_assignment_t const *assignment, uint32_t offset, clingo_literal_t *literal) |
| Returns the literal at the given position in the trail. More... | |
Initialization Functions | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_solver_literal (clingo_propagate_init_t const *init, clingo_literal_t aspif_literal, clingo_literal_t *solver_literal) |
| Map the given program literal or condition id to its solver literal. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_watch (clingo_propagate_init_t *init, clingo_literal_t solver_literal) |
| Add a watch for the solver literal in the given phase. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_watch_to_thread (clingo_propagate_init_t *init, clingo_literal_t solver_literal, clingo_id_t thread_id) |
| Add a watch for the solver literal in the given phase to the given solver thread. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_remove_watch (clingo_propagate_init_t *init, clingo_literal_t solver_literal) |
| Remove the watch for the solver literal in the given phase. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_remove_watch_from_thread (clingo_propagate_init_t *init, clingo_literal_t solver_literal, uint32_t thread_id) |
| Remove the watch for the solver literal in the given phase from the given solver thread. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_freeze_literal (clingo_propagate_init_t *init, clingo_literal_t solver_literal) |
| Freeze the given solver literal. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_symbolic_atoms (clingo_propagate_init_t const *init, clingo_symbolic_atoms_t const **atoms) |
| Get an object to inspect the symbolic atoms. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_theory_atoms (clingo_propagate_init_t const *init, clingo_theory_atoms_t const **atoms) |
| Get an object to inspect the theory atoms. More... | |
| CLINGO_VISIBILITY_DEFAULT int | clingo_propagate_init_number_of_threads (clingo_propagate_init_t const *init) |
| Get the number of threads used in subsequent solving. More... | |
| CLINGO_VISIBILITY_DEFAULT void | clingo_propagate_init_set_check_mode (clingo_propagate_init_t *init, clingo_propagator_check_mode_t mode) |
| Configure when to call the check method of the propagator. More... | |
| CLINGO_VISIBILITY_DEFAULT clingo_propagator_check_mode_t | clingo_propagate_init_get_check_mode (clingo_propagate_init_t const *init) |
| Get the current check mode of the propagator. More... | |
| CLINGO_VISIBILITY_DEFAULT clingo_assignment_t const * | clingo_propagate_init_assignment (clingo_propagate_init_t const *init) |
| Get the top level assignment solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_literal (clingo_propagate_init_t *init, bool freeze, clingo_literal_t *result) |
| Add a literal to the solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_clause (clingo_propagate_init_t *init, clingo_literal_t const *clause, size_t size, bool *result) |
| Add the given clause to the solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_weight_constraint (clingo_propagate_init_t *init, clingo_literal_t literal, clingo_weighted_literal_t const *literals, size_t size, clingo_weight_t bound, clingo_weight_constraint_type_t type, bool compare_equal, bool *result) |
| Add the given weight constraint to the solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_add_minimize (clingo_propagate_init_t *init, clingo_literal_t literal, clingo_weight_t weight, clingo_weight_t priority) |
| Add the given literal to minimize to the solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_init_propagate (clingo_propagate_init_t *init, bool *result) |
| Propagates consequences of the underlying problem excluding registered propagators. More... | |
Propagation Functions | |
| CLINGO_VISIBILITY_DEFAULT clingo_id_t | clingo_propagate_control_thread_id (clingo_propagate_control_t const *control) |
| Get the id of the underlying solver thread. More... | |
| CLINGO_VISIBILITY_DEFAULT clingo_assignment_t const * | clingo_propagate_control_assignment (clingo_propagate_control_t const *control) |
| Get the assignment associated with the underlying solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_control_add_literal (clingo_propagate_control_t *control, clingo_literal_t *result) |
| Adds a new volatile literal to the underlying solver thread. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_control_add_watch (clingo_propagate_control_t *control, clingo_literal_t literal) |
| Add a watch for the solver literal in the given phase. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_control_has_watch (clingo_propagate_control_t const *control, clingo_literal_t literal) |
| Check whether a literal is watched in the current solver thread. More... | |
| CLINGO_VISIBILITY_DEFAULT void | clingo_propagate_control_remove_watch (clingo_propagate_control_t *control, clingo_literal_t literal) |
| Removes the watch (if any) for the given solver literal. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_control_add_clause (clingo_propagate_control_t *control, clingo_literal_t const *clause, size_t size, clingo_clause_type_t type, bool *result) |
| Add the given clause to the solver. More... | |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_propagate_control_propagate (clingo_propagate_control_t *control, bool *result) |
| Propagate implied literals (resulting from added clauses). More... | |
| typedef struct clingo_assignment clingo_assignment_t |
Represents a (partial) assignment of a particular solver.
An assignment assigns truth values to a set of literals. A literal is assigned to either true or false, or is unassigned. Furthermore, each assigned literal is associated with a decision level. There is exactly one decision literal for each decision level greater than zero. Assignments to all other literals on the same level are consequences implied by the current and possibly previous decisions. Assignments on level zero are immediate consequences of the current program. Decision levels are consecutive numbers starting with zero up to and including the current decision level.
| typedef struct clingo_propagate_init clingo_propagate_init_t |
Object to initialize a user-defined propagator before each solving step.
Each symbolic or theory atom is uniquely associated with an aspif atom in form of a positive integer (clingo_literal_t). Aspif literals additionally are signed to represent default negation. Furthermore, there are non-zero integer solver literals (also represented using clingo_literal_t). There is a surjective mapping from program atoms to solver literals.
All methods called during propagation use solver literals whereas clingo_symbolic_atoms_literal() and clingo_theory_atoms_atom_literal() return program literals. The function clingo_propagate_init_solver_literal() can be used to map program literals or condition ids to solver literals.
| typedef struct clingo_propagator clingo_propagator_t |
An instance of this struct has to be registered with a solver to implement a custom propagator.
Not all callbacks have to be implemented and can be set to NULL if not needed.
| enum clingo_clause_type_e |
Enumeration of clause types determining the lifetime of a clause.
Clauses in the solver are either cleaned up based on a configurable deletion policy or at the end of a solving step. The values of this enumeration determine if a clause is subject to one of the above deletion strategies.
| Enumerator | |
|---|---|
| clingo_clause_type_learnt | clause is subject to the solvers deletion policy |
| clingo_clause_type_static | clause is not subject to the solvers deletion policy |
| clingo_clause_type_volatile | like clingo_clause_type_learnt but the clause is deleted after a solving step |
| clingo_clause_type_volatile_static | like clingo_clause_type_static but the clause is deleted after a solving step |
Supported check modes for propagators.
Note that total checks are subject to the lock when a model is found. This means that information from previously found models can be used to discard assignments in check calls.
| Enumerator | |
|---|---|
| clingo_propagator_check_mode_none | do not call clingo_propagator::check() at all |
| clingo_propagator_check_mode_total | call clingo_propagator::check() on total assignments |
| clingo_propagator_check_mode_fixpoint | call clingo_propagator::check() on propagation fixpoints |
| clingo_propagator_check_mode_both | call clingo_propagator::check() on propagation fixpoints and total assignments |
Enumeration of weight_constraint_types.
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_at | ( | clingo_assignment_t const * | assignment, |
| size_t | offset, | ||
| clingo_literal_t * | literal | ||
| ) |
The (positive) literal at the given offset in the assignment.
| [in] | assignment | the target |
| [in] | offset | the offset of the literal |
| [out] | literal | the literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_decision | ( | clingo_assignment_t const * | assignment, |
| uint32_t | level, | ||
| clingo_literal_t * | literal | ||
| ) |
Determine the decision literal given a decision level.
| [in] | assignment | the target assignment |
| [in] | level | the level |
| [out] | literal | the resulting literal |
| CLINGO_VISIBILITY_DEFAULT uint32_t clingo_assignment_decision_level | ( | clingo_assignment_t const * | assignment | ) |
Get the current decision level.
| [in] | assignment | the target assignment |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_has_conflict | ( | clingo_assignment_t const * | assignment | ) |
Check if the given assignment is conflicting.
| [in] | assignment | the target assignment |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_has_literal | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal | ||
| ) |
Check if the given literal is part of a (partial) assignment.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_is_false | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal, | ||
| bool * | is_false | ||
| ) |
Check if a literal has a fixed truth value.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| [out] | is_false | whether the literal is false |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_is_fixed | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal, | ||
| bool * | is_fixed | ||
| ) |
Check if a literal has a fixed truth value.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| [out] | is_fixed | whether the literal is fixed |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_is_total | ( | clingo_assignment_t const * | assignment | ) |
Check if the assignment is total, i.e.
there are no free literal.
| [in] | assignment | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_is_true | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal, | ||
| bool * | is_true | ||
| ) |
Check if a literal is true.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| [out] | is_true | whether the literal is true |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_level | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal, | ||
| uint32_t * | level | ||
| ) |
Determine the decision level of a given literal.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| [out] | level | the resulting level |
| CLINGO_VISIBILITY_DEFAULT uint32_t clingo_assignment_root_level | ( | clingo_assignment_t const * | assignment | ) |
Get the current root level.
Decisions levels smaller or equal to the root level are not backtracked during solving.
| [in] | assignment | the target assignment |
| CLINGO_VISIBILITY_DEFAULT size_t clingo_assignment_size | ( | clingo_assignment_t const * | assignment | ) |
The number of (positive) literals in the assignment.
| [in] | assignment | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_trail_at | ( | clingo_assignment_t const * | assignment, |
| uint32_t | offset, | ||
| clingo_literal_t * | literal | ||
| ) |
Returns the literal at the given position in the trail.
| [in] | assignment | the target |
| [in] | offset | the offset of the literal |
| [out] | literal | the literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_trail_begin | ( | clingo_assignment_t const * | assignment, |
| uint32_t | level, | ||
| uint32_t * | offset | ||
| ) |
Returns the offset of the decision literal with the given decision level in the trail.
| [in] | assignment | the target |
| [in] | level | the decision level |
| [out] | offset | the offset of the decision literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_trail_end | ( | clingo_assignment_t const * | assignment, |
| uint32_t | level, | ||
| uint32_t * | offset | ||
| ) |
Returns the offset following the last literal with the given decision level.
| [in] | assignment | the target |
| [in] | level | the decision level |
| [out] | offset | the offset |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_trail_size | ( | clingo_assignment_t const * | assignment, |
| uint32_t * | size | ||
| ) |
Returns the number of literals in the trail, i.e., the number of assigned literals.
| [in] | assignment | the target |
| [out] | size | the number of literals in the trail |
| CLINGO_VISIBILITY_DEFAULT bool clingo_assignment_truth_value | ( | clingo_assignment_t const * | assignment, |
| clingo_literal_t | literal, | ||
| clingo_truth_value_t * | value | ||
| ) |
Determine the truth value of a given literal.
| [in] | assignment | the target assignment |
| [in] | literal | the literal |
| [out] | value | the resulting truth value |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_control_add_clause | ( | clingo_propagate_control_t * | control, |
| clingo_literal_t const * | clause, | ||
| size_t | size, | ||
| clingo_clause_type_t | type, | ||
| bool * | result | ||
| ) |
Add the given clause to the solver.
This method sets its result to false if the current propagation must be stopped for the solver to backtrack.
| [in] | control | the target |
| [in] | clause | the clause to add |
| [in] | size | the size of the clause |
| [in] | type | the clause type determining its lifetime |
| [out] | result | result indicating whether propagation has to be stopped |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_control_add_literal | ( | clingo_propagate_control_t * | control, |
| clingo_literal_t * | result | ||
| ) |
Adds a new volatile literal to the underlying solver thread.
| [in] | control | the target |
| [out] | result | the (positive) solver literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_control_add_watch | ( | clingo_propagate_control_t * | control, |
| clingo_literal_t | literal | ||
| ) |
Add a watch for the solver literal in the given phase.
| [in] | control | the target |
| [in] | literal | the literal to watch |
| CLINGO_VISIBILITY_DEFAULT clingo_assignment_t const* clingo_propagate_control_assignment | ( | clingo_propagate_control_t const * | control | ) |
Get the assignment associated with the underlying solver.
| [in] | control | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_control_has_watch | ( | clingo_propagate_control_t const * | control, |
| clingo_literal_t | literal | ||
| ) |
Check whether a literal is watched in the current solver thread.
| [in] | control | the target |
| [in] | literal | the literal to check |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_control_propagate | ( | clingo_propagate_control_t * | control, |
| bool * | result | ||
| ) |
Propagate implied literals (resulting from added clauses).
This method sets its result to false if the current propagation must be stopped for the solver to backtrack.
| [in] | control | the target |
| [out] | result | result indicating whether propagation has to be stopped |
| CLINGO_VISIBILITY_DEFAULT void clingo_propagate_control_remove_watch | ( | clingo_propagate_control_t * | control, |
| clingo_literal_t | literal | ||
| ) |
Removes the watch (if any) for the given solver literal.
| [in] | control | the target |
| [in] | literal | the literal to remove |
| CLINGO_VISIBILITY_DEFAULT clingo_id_t clingo_propagate_control_thread_id | ( | clingo_propagate_control_t const * | control | ) |
Get the id of the underlying solver thread.
Thread ids are consecutive numbers starting with zero.
| [in] | control | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_clause | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t const * | clause, | ||
| size_t | size, | ||
| bool * | result | ||
| ) |
Add the given clause to the solver.
| [in] | init | the target |
| [in] | clause | the clause to add |
| [in] | size | the size of the clause |
| [out] | result | result indicating whether the problem became unsatisfiable |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_literal | ( | clingo_propagate_init_t * | init, |
| bool | freeze, | ||
| clingo_literal_t * | result | ||
| ) |
Add a literal to the solver.
To be able to use the variable in clauses during propagation or add watches to it, it has to be frozen. Otherwise, it might be removed during preprocessing.
| [in] | init | the target |
| [in] | freeze | whether to freeze the literal |
| [out] | result | the added literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_minimize | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | literal, | ||
| clingo_weight_t | weight, | ||
| clingo_weight_t | priority | ||
| ) |
Add the given literal to minimize to the solver.
This corresponds to a weak constraint of form :~ literal. [weight@priority]
.
| [in] | init | the target |
| [in] | literal | the literal to minimize |
| [in] | weight | the weight of the literal |
| [in] | priority | the priority of the literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_watch | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | solver_literal | ||
| ) |
Add a watch for the solver literal in the given phase.
| [in] | init | the target |
| [in] | solver_literal | the solver literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_watch_to_thread | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | solver_literal, | ||
| clingo_id_t | thread_id | ||
| ) |
Add a watch for the solver literal in the given phase to the given solver thread.
| [in] | init | the target |
| [in] | solver_literal | the solver literal |
| [in] | thread_id | the id of the solver thread |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_add_weight_constraint | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | literal, | ||
| clingo_weighted_literal_t const * | literals, | ||
| size_t | size, | ||
| clingo_weight_t | bound, | ||
| clingo_weight_constraint_type_t | type, | ||
| bool | compare_equal, | ||
| bool * | result | ||
| ) |
Add the given weight constraint to the solver.
This function adds a constraint of form literal <=> { lit=weight | (lit, weight) in literals } >= bound
to the solver. Depending on the type the <=>
connective can be either a left implication, right implication, or equivalence.
| [in] | init | the target |
| [in] | literal | the literal of the constraint |
| [in] | literals | the weighted literals |
| [in] | size | the number of weighted literals |
| [in] | bound | the bound of the constraint |
| [in] | type | the type of the weight constraint |
| [in] | compare_equal | if true compare equal instead of less than equal |
| [out] | result | result indicating whether the problem became unsatisfiable |
| CLINGO_VISIBILITY_DEFAULT clingo_assignment_t const* clingo_propagate_init_assignment | ( | clingo_propagate_init_t const * | init | ) |
Get the top level assignment solver.
| [in] | init | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_freeze_literal | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | solver_literal | ||
| ) |
Freeze the given solver literal.
Any solver literal that is not frozen is subject to simplification and might be removed in a preprocessing step after propagator initialization. A propagator should freeze all literals over which it might add clauses during propagation. Note that any watched literal is automatically frozen and that it does not matter which phase of the literal is frozen.
| [in] | init | the target |
| [in] | solver_literal | the solver literal |
| CLINGO_VISIBILITY_DEFAULT clingo_propagator_check_mode_t clingo_propagate_init_get_check_mode | ( | clingo_propagate_init_t const * | init | ) |
Get the current check mode of the propagator.
| [in] | init | the target |
| CLINGO_VISIBILITY_DEFAULT int clingo_propagate_init_number_of_threads | ( | clingo_propagate_init_t const * | init | ) |
Get the number of threads used in subsequent solving.
| [in] | init | the target |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_propagate | ( | clingo_propagate_init_t * | init, |
| bool * | result | ||
| ) |
Propagates consequences of the underlying problem excluding registered propagators.
| [in] | init | the target |
| [out] | result | result indicating whether the problem became unsatisfiable |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_remove_watch | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | solver_literal | ||
| ) |
Remove the watch for the solver literal in the given phase.
| [in] | init | the target |
| [in] | solver_literal | the solver literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_remove_watch_from_thread | ( | clingo_propagate_init_t * | init, |
| clingo_literal_t | solver_literal, | ||
| uint32_t | thread_id | ||
| ) |
Remove the watch for the solver literal in the given phase from the given solver thread.
| [in] | init | the target |
| [in] | solver_literal | the solver literal |
| [in] | thread_id | the id of the solver thread |
| CLINGO_VISIBILITY_DEFAULT void clingo_propagate_init_set_check_mode | ( | clingo_propagate_init_t * | init, |
| clingo_propagator_check_mode_t | mode | ||
| ) |
Configure when to call the check method of the propagator.
| [in] | init | the target |
| [in] | mode | bitmask when to call the propagator |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_solver_literal | ( | clingo_propagate_init_t const * | init, |
| clingo_literal_t | aspif_literal, | ||
| clingo_literal_t * | solver_literal | ||
| ) |
Map the given program literal or condition id to its solver literal.
| [in] | init | the target |
| [in] | aspif_literal | the aspif literal to map |
| [out] | solver_literal | the resulting solver literal |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_symbolic_atoms | ( | clingo_propagate_init_t const * | init, |
| clingo_symbolic_atoms_t const ** | atoms | ||
| ) |
Get an object to inspect the symbolic atoms.
| [in] | init | the target |
| [out] | atoms | the resulting object |
| CLINGO_VISIBILITY_DEFAULT bool clingo_propagate_init_theory_atoms | ( | clingo_propagate_init_t const * | init, |
| clingo_theory_atoms_t const ** | atoms | ||
| ) |
Get an object to inspect the theory atoms.
| [in] | init | the target |
| [out] | atoms | the resulting object |


{{reward.points}} HackZurichPoints have been collected!
{{reward.withFocus}}km have been driven with focus.
{{reward.withoutFocus}}km have been driven without focus.
{{reward.totalDistance}} have been drived with the app.


Arrow container class.
FontAwesome icon name for open list button.
FontAwesome icon name for close list button.
FontAwesome icon size for open/close list buttons.
If true to select component will be added button which clear input.
Close datetime on select?
Close on tab?
Date format.
Date component class.
Disable on clck outside?
Help message.
Component id.
Is input allowed?
Input component props.
Component label.
Date/time locale.
If true, select component can contains several selected items.
Function which call when component lost focus.
Function which call when component value changed.
Function which call when component focused.
Is open on startup?
Placeholder text.
If true to select component will be added ability to search needed value.
Select class.
Values for select component.
Strict parsing?
Time format.
Field group component type/
Use utc time?
Timeout for showing failed validation message after user start input something.
Validation message.
Validation state
Select value.
Generated using TypeDoc
Combined props.


About
I am MK Hamid, titled LinuxBieKaisar at marketplace, a motivated and dedicated Linux Monster, working for installing and maintaining Linux servers, improving the server security, and providing technical assistance to clients.
Technology Stack
- Linux, Ubuntu, CentOS
- Git, GitHub, GitLab
- AWS, DigitalOcean, Linode
- Rails, Python, Ruby on Rails
- Linux Security
- Ticket Selling Software
- Online Food Ordering System
- PHP Wallet Setup
- Network Traffic scanner
- Video Conferencing Software Installation
Jobs History
I have completed different project and made business relations with different client from different countries. This section shows my project, client and working ratio.
Happy Clients
Projects
Hours Of Support
Hard Workers
Skills
I got different trainning on Linux, Linux Security and Technical Assistant. This trainning improve my skill and working performance
Portfolio
I have included real screenshots of different project after getting installed in my Linux distro and gather knowledge and professionalism in the said arenas.
- All
- App
- DB
- Web
Services
SMS Gateway
I will do SMS gateway gateway setup in any Linux for sending or receiving Short Message Service or Multimedia Messaging Service transmissions to or from a telecommunications network.
Crytocurrency
I will do install different software related with Cryptocurrency exchanges platform for buying and trading cryptocurrencies.
Wordpress Development
I will do wordpress setup in any Linux for developing wordpress website in connection with your virual presence.
Network Security
I will install different Network Monitoring Software in any Linux distro for you in connection with monitoring your network as well as identify threads.
Restaurant Management System
I will do Restaurant Ordering System setup in any Linux for accepting orders from customers. With the rise in online orders.
Database Setup
I will do different database setup in any Linux in connection with the installation for building modern application and for the cloud era.
Clients Review
Sidoniela
United State
I highly recommend his service. Very professional, extremely knowledgeable and easy to work with. We will use him again for more projects.
James L.
Quebec, Canada
Excellent
Ben M.
Polokwane, South Africa
Excellent Service
Contact
Location:
Middle Kadhurkhill, Boalkhali, Chattogram
Email:
<EMAIL_ADDRESS>Call:
+8801842 03 59 53


I am originally from the suburbs of Indianapolis. I love trying new things, home brewing, rooting for the Packers and the Colts, reading, baking, barbequing, and most importantly learning.
I firmly believe the best thing a person can do is to never stop learning. If you want to work with a Software Engineer/Product Manager that has a deep passion for learning, enjoys working with others, driven to be the best Ruby on Rails developer, and lives to share knowledge with others then I'm your guy. Please take a look at my skill sets, projects or feel free to contact me.
I enrolled in a Udacity nanodegree program focused on Product Management. For this program I was tasked with building out the structure to take to market an Amazon feature on self published videos. I have broken out the work that I completed during that nanodegree program into sections:
Mocks
I used Figma to mock up the project and utilizied Material design tools.
Prototypes
These are prototypes from Figma that I then used to interview potential users.
PRDs
There are three separate PRDs with the versioning that shows the progression of the coursework.
Presentations
The presentation pieces are what was turned in for the coursework and contains links to other aspects of the course work as well along with research that took place.


Lu Rou Fan (Braised pork rice) @ Seah Im Food Centre
This was one of my favourite lunches in Singapore. I would have it almost every day while I was on my 2-month internship near Harbourfront centre. The portions are very generous, the price is super affordable and the braised pork practically melts in your mouth! TIP: The queue would always be really long and the food runs out really quickly, so be sure to get there early!
Historical market of Lau Pa Sat @ Telok Ayer market on the Raffles Quay
This amazing market dating back to the 19th century is for a me a key landmark of singapore. There you have many options but you should try the Hainanese Chicken Rice, Fish Ball Soup and the Wonton Soup but also the Dim Sum and Dumplings. TIP: ask the locals what they recommend always good way to experience Singapore from the inside.
Gardens by the Bay
There are so many beautiful flowers near the area and it's always a favourite past time of me and my friends to visit the domes because they're so pretty.
The Chinese Quarter
It is a beautiful neighbourhood where it feels like time has stopped. It is full of restaurants and little souvenir shops but also medicine shops. I really enjoyed walking around the colourful houses with the nice Chinese lanterns above my head. The temple, in the middle of is a key place of the neighbourhood. Its architecture is very impressive but the place is very peaceful with its very big prayer wheel. And don’t forget the rooftop the view over the neighbourhood is worthy the couple stairs.


-
MAYDAY.US: Democracy needs an upgrade. Act now.
mayday.us
Money has corrupted politics. Join MAYDAY.US - the movement to end this corruption.
-
Twitter / Recherche - #worldcup
twitter.com
Le meilleur des derniers Tweets à propos de #worldcup. Lisez ce que les gens disent et rejoignez la conversation.
-
Coursera
www.coursera.org
Take free online classes from 80+ top universities and organizations. Coursera is a social entrepreneurship company partnering with Stanford ...
-
Google Discussiegroepen
groups.google.com
Met Google Discussiegroepen kun je online forums en e-mailgroepen maken en eraan deelnemen. Bovendien profiteer je van uitgebreide ...
-
Progress Report: Continued Product Focus
yahoo.tumblr.com
By Jay Rossiter, SVP, Cloud Platform Group At Yahoo, focus is an important part of accomplishing our mission: to make the world’s daily habits more ...
-
Google Play Help
support.google.com
To help us address your issue as quickly as possible, please sign in to your Google Account.
-
Video: https://www.youtube.com/watch?v=LaxbdIyBkL0 Presented at at the ...
speakerdeck.com
JavaScript Memory Management Masterclass
-
This is why your Internet is slow. And it’ll get worse. Unless you take 1 ...
www.battleforthenet.com
You’re our only hope.
-
Bill Gates ALS Ice Bucket Challenge
www.youtube.com
Bill Gates accepts Mark Zuckerberg’s ALS Ice Bucket Challenge and nominates Elon Musk, Ryan Seacrest and Chris Anderson from TED to participate and ...
-
Vagina selfie for 3D printers lands Japanese artist in trouble
www.theguardian.com
Megumi Igarashi, aka Rokudenashiko, is arrested for emailing digital template of her own genitalia to supporters of her vagina art ventures
-
How Burrowing Owls Lead To Vomiting Anarchists (Or SF’s Housing Crisis ...
techcrunch.com
Today, the tech industry is apparently on track to destroy one of the world's most valuable cultural treasures, San Francisco, by pushing out the ...
-
Microsoft account
login.live.com
Microsoft account requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked. To find out ...
-
Build software better, together
github.com
GitHub is the best place to build software together. Over 4 million people use GitHub to share code.
-
The Megalomaniac Bore: Write your own Virtual CPU in C++ (4001 CPU)
megalomaniacbore.blogspot.com
A blog about my rantings, including Games, Game Development, Gaming, Consoles, PC Gaming, Role Playing Games, People, Gaming tips & cheats, Game ...
-
New to Google Play? Learn the basics - Google Play Help
support.google.com
You can enjoy your favorite apps and digital content on
-
Music won't start playing - Google Play Help
support.google.com
If you’re having trouble playing music on Google Play, here are some troubleshooting steps. Troubleshooting Check your Internet connection You may ...
-
Google - Cloud Print
www.google.com
Google Cloud Print is a technology that allows you to print over the web from anywhere, including your phone, to any printer.
-
Getting Started with SOA using SwitchYard
www.slideshare.net
This lecture will give an introduction of SOA, giving an background of history and an overview of its specifications. How does Service Component ...
-
Release Notes - ASF JIRA
issues.apache.org
The text area below allows the project release notes to be edited and copied to another document.
-
Shellshock: All you need to know about the Bash Bug vulnerability
www.symantec.com
Web servers at risk as new vulnerability potentially affects most versions of Linux and Unix, as well as Mac OS X.
-
Chrome Web Store
chrome.google.com
Discover great apps, games, extensions and themes for Google Chrome.
-
comic books - Boeken op Google Play
play.google.com
Winkel bij Google Play op internet. Doe aankopen en gebruik deze direct op uw Android-telefoon of -tablet zonder te synchroniseren.
-
5 Seconds Of Summer: Amnesia - Music on Google Play
play.google.com
Shop Google Play on the web. Purchase and enjoy instantly on your Android phone or tablet without the hassle of syncing.


 To purchase a home and fill it with your wellbeing? We can help you get settled and get past through the tedious implications regarding taxes! Here are three ways you can save money with the homeowner tax deductions other personal finance tips:
As for your personal property, some states require you pay personal property taxes and for some an annual property tax. Learn more about personal property tax here:
An important factor in buying a home is the down payment which is NOT tax-deductible item. However, if you cash out a retirement plan to fund your down payment, let the plan administrator know that this is the purpose of the distribution. You can avoid the early withdrawal penalty if under age 59 1/2 if you are a first time home buyer and the funds are used for acquisition, which includes buying, building or rebuilding a first home. Closing costs are not deductible as well. However, there are some deductible items such as property taxes and loan origination fees.
Source: http://www.foxbusiness.com/personal-finance/2014/04/17/tax-implications-buying-home/


Dan Bucholtz | @danbucholtz
Ionic is a team of 25ish in Madison, WI
Founded in 2012
Make a popular tool for building software called Ionic Framework
We're well funded financially and will be around for many years to come
Two versions, V1 and V2
Ionic Framework is a free, open source solution to build Android and iOS "Hybrid" applications
Look and feel of a "native" app, but one code set for both platforms
Unlock the full functionality of the device using Cordova (Phone Gap)
Ionic uses Sass for "better css"
Sass is easier to customize to fit your brand
Built on top of AngularJS
Great performance
"If you can make a website, you can make an app"!
Next-gen of Ionic is even simpler!
~2.5M apps have been created
Top 30ish most popular open source project
100+ Meetup groups around the world
Several top apps are built on Ionic
Used by Fortune 50 to start-ups
Developers love it
Rave about it's simplicity
Huge, awesome community
Ionic V1 was built in 2012, so getting a little long in the tooth
New "Mobile first" frameworks promise much better performance
Silky smooth 60FPS is the new standard
With Angular 2 being a major reboot, we decided to do a major reboot too
Ionic V2 is built from the ground up
Took all of the feedback and lessons learned from V1
Built hand-in-hand with the Angular 2 team at Google
Much better architecture, much better performance
The feedback on V2 has been amazing!
More components, better quality components
Dramatically improved/simplified developer experience
Ionic was always fast, but now it flies
No Ionic V2 benchmarks yet
Angular 2 is ~5x faster in typical real world use cases
Laser focused on 60 FPS on mobile
Ionic V1 supports Android and iOS
Ionic V2 expands this to include several more platforms
Windows Universal (Traditional Windows, Phone)
Desktop Apps (Electron)
Mobile Web, Traditional Web
Ionic V2 dramatically simplies theming
Full Material Design support for Android
Matches iOS 9 look and feel, will be updated for iOS 10
Full Windows Universal theme support
Easy to customize
iOS, Material Design, Windows Universal
Enterprise users wanted better tooling
As maintainers, we did too :)
Typescript instead of Javascript
First class support for automated testing
We have been dogfooding Ionic V2 and Typescript for months now
We have noticed a huge improvement in code quality, maintainability, etc.
Ionic V1 apps ~500-1000K
Fine for "Hybrid" app use case, bad for mobile web
Angular 2 to the Rescue
Blazing fast first load due to Angular Universal
Aiming for 60-80KB for good sized app, can be lazy loaded
Designed for the mobile web in places where 2G and 3G is still prominent
Set of tools to make life easier for enterprise
Rapid prototype with Ionic Creator
Beta testing with Ionic View
Push Notifications
Authenication
Build support
Much more coming soon!
Enterprise level support available
Trusted Partner Program
Program is early, but growing rapidly
</html>


|
My Project
|
Inherits MonoBehaviour.
Public Member Functions | |
| Vector3 | GetForce (Node n) |
| float | UpdateVis () |
| Vector3 | GetEulerAnglesQ (Vector3 v) |
Public Attributes | |
| Node | n1 |
| Node | n2 |
| Transform | t |
| LineRenderer | lr |
Static Public Attributes | |
| static float | idealLen |
| static float | idealLen2 |
| static Gradient | g |
| static int | colorFactor |
| static float | avLen |
Represents an edge between two nodes in our graph Can return the force it applies on its nodes
| Vector3 Edge.GetEulerAnglesQ | ( | Vector3 | v | ) |
Calculates the correct rotation for the edge, given the direction of the edge Given a directional vector for the x direction Returns a Vector3 for local Euler, via Quaternion.LookRotation
Currently unused, since LineRenderers don't need it.
| v | Vector defining the direction of the edge (n1.pos-n2.pos) |
| Vector3 Edge.GetForce | ( | Node | n | ) |
Returns a Vector3 that represents the force applied on a node
| n | Which node we want the force for. If it doesn't belong to this edge, a zero force is returned |
| float Edge.UpdateVis | ( | ) |
Updates the visual position, length, rotation, and color of the edge if either node of the edge is not simulating, the edge is moved far away and hidden
|
static |
Last calculated average edge length. Set in Controller.
|
static |
Shifts the scaling of how our gradient is mapped to edge lengths
|
static |
Gradient that colors our edges
|
static |
Ideal length for the edges
|
static |
Ideal length for the edges squared
| LineRenderer Edge.lr |
The visual line renderer for this edge.
| Node Edge.n1 |
First node that comprises this edge
| Node Edge.n2 |
Second node that comprises this edge
| Transform Edge.t |
The transform of this edge (at the midpoint)


This analysis is a placeholder with a sample set. If you want to contribute new analyses for the site, contact Disaster Area on Discord.
- Swords Dance
- Soft-Boiled
- Earthquake
- Rock Slide / Body Slam / Hyper Beam
This analysis is a placeholder with a sample set. If you want to contribute new analyses for the site, contact Disaster Area on Discord.
- Dream Eater
- Psychic
- Toxic / Explosion
- Soft-Boiled / Explosion
This analysis is a placeholder with a sample set. If you want to contribute new analyses for the site, contact Disaster Area on Discord.
- Solar Beam
- Soft-Boiled
- Psychic
- Reflect
This analysis is a placeholder with a sample set. If you want to contribute new analyses for the site, contact Disaster Area on Discord.
- Swords Dance
- Earthquake
- Rock Slide / Body Slam
- Hyper Beam
Swords Dance + Reflect + Soft-Boiled + Body Slam, Thunder Wave, Transform, Solar Beam + Soft-Boiled + Psychic + Fire Blast / Explosion, Counter, Blizzard, Ice Beam, Submission, Tri Attack, Mega Drain
This analysis is a placeholder with a sample set. If you want to contribute new analyses for the site, contact Disaster Area on Discord.
Author: Disaster Area
Publish Date: 5th July 2020


A formal privacy policy does not yet exist. But, we won't know anything about you except for basic account info, and what's on your current shopping lists.
Most stuff on your lists will probably be personal shorthand - "coffee", "cereal", "milk", etc, so it probably wouldn't have much value if we tried to sell it.
Plus, everything is open source, so you can poke through the source code to see if doing something nasty. The worst currently is using Google Analytics to get basic anonymous/aggregated usage statistics from folks without adblockers.


Document version: $Revision: 1.3 $ $Date: 2002/12/06 23:24:08 $
Chapter Descriptions. Roles of Berkeley, Middleware Groups, and Document.
Detailed description of the demo scenario, including what entities are present and how they behave. Also define high-level architecture decisions such as global/local coordinate systems, global/local time, etc.
Informal, linguistic description of the philosophies used to construct each component
Berkeley's role
Middleware groups' role
Challenge Architecture Document goals
To start the game, the motes comprising the sensor network are deployed onto the playing field in a sleep state. An external node broadcasts a begin signal to the sensor network to indicate the start of global time. The pursuers and evaders then enter the playing field and remain within the field for the duration of the game. The sensor network provides a variety of services to both pursuers and other sensor motes: time synchronization, localization, critter (moving object: pursuer or evader) estimation, etc. For the purpose of the game, the sole goal of these services is to produce estimates on the positions, velocity, and identity of critters in the playing field. This information is time stamped and routed to all pursuers in the playing field. The pursuers have onboard computation facilities comparable to a laptop computer and may optionally communicate through a separate robust channel to coordinate to capture the evader. When all evaders are captured (a capture occurs when a pursuer is "close enough" to it), the game ends. A base station is outside the playing area and provides logging and visualization services.
Pursuers
Mote Sensors
Evaders
The architecture defines a set of components which may implement algorithms and may behave as services. The architecture further defines the input and output structures and protocols accepted and emitted by components, implicit or explicit constraints and behaviors pertinent to the components, and interrelationships between components.
In this chapter, we first define just the subset of the architecture seen from the application layer: the pursuit-evasion game demo. From there, we iteratively extend that architecture with likely supporting components up-to and including top-level TinyOS components. As this document evolves, we will keep an eye toward abstraction and generality; ideally creating a refactored specification with broader application than just the game demo.
Prototypes are the essence of the architecture. Prototypes define the minimal interface provided by components. The goal is to create an architecture in which dissimilar implementations of components are interchangeable if they provide equivalent facilities, while at the same time not imposing unnecessary constraints on the underlying algorithms.
These Prototypes formally describe the API that certain classes of components and algorithms must adhere to. Concrete implementations of these prototypes provide at least the described interfaces, but may include additional interfaces specific to the algorithm at hand, such as Sensor's and Actuator's. Concrete implementations that wish to be used in the demo must fully specify themselves in the context of this document. That is, they must clearly define their abstract, formal, NesC, and graphical architectures. These concrete specifications will be wholly included in the architecture document.
Each service is implemented as a separate component. We intend a coordination component that provides scheduling of other components and management of shared resources. Each component is initialized in turn, during which it is responsible for registering itself with the coordination component. Each component registers how often it should be executed (time-triggered) and which events it should receive (messages, sensor readings, etc). The coordination component is responsible for meeting these demands of the components.
To filter data or calibrate a sensor or actuator, we intend to create components that both provide and use the interface they are filtering/calibrating. This allows us to chain any number of filters or calibrations transparently.
By default, we are not providing a resource sharing infrastructure beyond the sharing of the CPU and RF channel via the service coordination component. That is, we are assuming that in any particular configuration, no more than one component will want to use, say, the sounder. Creating a configuration in which more than one component needs access to the same resource is considered malformed. If this becomes a problem in practice, we will work to develop a resource sharing scheme. We are deferring that solution until we see conflicts arise in practice. That way, we can develop something well-suited for the problem (instead something ill-suited).
Sensors readings (input) are event driven. Processing dependent on sensor readings are also events, say for filtering data. And, it cascades all the way up; events are fired for both estimating position and initiating the broadcast of those estimates. Actuation (output) is command driven; that includes both movement and outgoing communication.
We want to abstract from byte-packed messages used for radio communication. Each component that communicates via messages to other components (either on the local mote or remote motes) operates in the context of a structure containing native types. We package all relevant information in a single structure. This reduces the need to redefine interfaces when/if we adjust only the particular data passed between components. This also results in a one-to-one correspondence between message interfaces and message structures.
This component aggregates sensor readings among a group of motes. The protocol for data measurement and aggregation is application-specific and transparent to the rest of demo code. If a target is detected, the component fires a TargetPosition event on the motes attached to the pursuers. The event passes the address of a target and a target identifier. The protocol will attempt to use the same identifier consistently to refer to the same target. This is accomplished with the help of the group management component described in Section 4. A higher-level protocol can be used to compile a list of all identified targets and their current locations.
Estimate Target depends on the PacketRouting component. Especially, it will need to use the RouteMobile interface to deliver the target information to the pursuers. The target estimation component also interacts with the location service. It needs the location information to calculate the position of the target using the positions of the detecting motes.
module PrototypeEstimateTargetM { provides { interface TargetPosition; } uses { interface ReceiveMsg; interface SendMobile; } }
interface TargetPosition { event result_t TargetPosition( location_t position; char target_id ); }
Below is a preliminary API for group management services in NEST (MIT, OSU, UVa).
The whole picture of definition is
module GroupManagementM { provides { interface StdControl; interface GroupManagementGlobal as GMGlobal; interface GroupManagementNeighbor as GMNeighbor; interface GroupManagementTracking as GMTracking; } uses { .; } }
The group management component produces a suite of services with three different functionalities, described below.
This service exports these calls:
Interface GroupManagementGlobal {
command result_t multicast(
uint8_t type,
char *msg
);
event result_t receiveMulticast(
uint8_t type,
char *msg
);
event result_t leader(
uint8_t type,
uint8_t on_off
);
}
The multicast primitive communicates a message efficiently to all destinations within the given radius configured into the service or indicated in the message header. The type parameter is used to distinguish different types of multicast services described in this document. This service has type LOCATION. The implementation transparently uses the MIT's location-dependent group formation protocol. receiveMulticast is an event raised to inform an application that a multicast message has been received. The underlying routing scheme uses a leader election protocol. The nodes that are elected leaders are notified using the leader event when they become and when cease to be leaders in this protocol. The application can ignore that event or utilize it for application-level functions that need to be performed at selected nodes in the network. Check MITs group formation documentation for more info on how leaders are elected and what properties they have.
interface GroupManagementNeighbor {
command result_t getNeighborhoodInfo();
}
The main call expored is getNeighborhoodInfo().
It returns a data structure with information regarding neighborhood health.
Berkeley reports that the "raw" connectivity information in motes network may not necessarily be suitable for routing and other reliable communication and infrastructure tasks:
create Neighborhood Maintenance Component that depending on the application gives an "improved" neighborhood information. This "improved" information preserves the cardinal features of "raw" info such as connectivity.
notice that it is not necessarily immediate neighborhood but possibly extended to 2-3 hops from a node.
OSU has a few schemes how this can be done efficiently, locally and with great degree of fault tolerance.
no, multiple reasons:
Interface Specification
The interface is:
interface GroupManagementTracking {
command result_t join(
uint8_t target_signature
);
command result_t leave(
uint8_t target_signature
);
command result_t setState(
char state
);
command result_t getState(
char state
);
event result_t leader(
uint8_t type,
uint8_t on_off
);
}
The main abstraction exported by the service is that of tracking groups. A tracking group is formed among all nodes sensing the target, as defined by a given sensory signature. The unique group name unambiguously labels each target. As the target moves, the membership of the group changes, but group identity remains the same. Hence, proximity-based groups will help identify and track different evaders. The main API is:
command result_t join( uint8_t target_signature )
The call specifies the detected target signature. The call is executed when a node senses a target of that particular signature. The call returns a group id specifying which target of that signature is currently in the proximity of the joining node as maintained by the group management service. Hence, a node's code might like something like:
if( target_signature is detected ){ target_id = join( target_signature ) tell pursuer that I see target_id at my_location. }
Observe that in the absence of tracking groups the node would not be able to immediately identify which target it is seeing (e.g., whether it is seeing the evader or one of the pursuers. Identifying the target locally is the main advantage of tracking groups. Other API calls are:
command result_t leave( target_signature )
The leave call specifies that the target can no longer be locally sensed by this node. The service also supports the calls:
event result_t leader( type, on_off ) command result_t setState( state ) command result_t getState( state )
As before, the leader call notifies the application when its node becomes or ceases to be leader, except that when type=TRACKING, the event refers to the leader of the tracking group. This leader changes as the group migrates. The invariants maintained are the group id and the fact that the leader is always within sensory horizon from the target tracked by this specific group. setState and getState is used to save and restore state that the algorithm maintains persistently across different leaders. Hence, when a node becomes leader is can getState and resume computation from where the last leader left it. The node would periodically checkpoint the computation using setState.
We break localization into four sub-systems:
This breakdown gives us modularity and interchangeability because each sub-system has its own API.
First, we describe each sub-system and a few important points about them. Then, we write down the APIs for each sub-system. Finally, we make a few concluding remarks about protocols, incremental development, non-homogenous networks, and data representation.
The sensing/actuation sub-system gives you ranging and/or angle data (with which you would later do multi-lateration and/or triangulation, respectively). This sub-system should be broken into at least two components: sensor and actuator. This allows non-homogenous networks, e.g. an infrastructure might always transmit localization beacons while the network always senses or vice versa. We can have a homogenous network by simply installing both components on every mote.
This subsystem has three top interfaces with which it
It also has a lower interface to interact with whatever actuator or sensor.
The data sub-system holds ranging/angle/location data of all important neighbors. This subsystem is not just a passive data structure, it is actually quite active. Let.s say, for instance, that my localization algorithm works best with 8 neighbors. If I have more than 8 neighbors, I need to know which neighbors to ignore (perhaps those with the noisiest ranging estimates or perhaps those with short distances). I also have to know when data becomes old and invalid, etc. Every implementation of this sub-system will have to make all of these decisions based on the type of ranging being used and the type of localization algorithm begin used.
This sub-system has a bottom interface with which it receives new data. It also has a top interface with which it gives data and a top interface with which it can be commanded to start and stop (starting and stopping here might not be well defined).
The computational level is where we do triangulation, multilateration, or whatever. This is what most people think of when they hear .localization. but it is really the easiest part to write for an embedded system like TinyOS.
This sub-system has a bottom interface with which it requests data from the data management sub-system. It also has a top interface with which it gives new location estimates and a top interface with which is can be commanded to start or stop.
This sub-system controls all the other sub-systems. This should be separate from the other systems because its functionality is completely defined by the application. For example, in a static environment we may only want to localize once in the beginning of the application and then never again. If something walks into the room we might want all nodes near the moving node to help it localize. In a completely dynamic environment we might want all nodes localizing by following some scheduling algorithm, which would be implemented here. Sometimes, we may want very frequent ranging estimates but only infrequent location estimates, etc. etc.
This sub-system has a bottom interfaces with which it controls all lower sub-systems. It also has a top interface with it is told to start and stop.
module PrototypeLocalizationActuatorM { provides { interface StdControl; interface LocalizationActuator; } uses { interface Actuator; } }
module PrototypeLocalizationSensorM { provides { interface StdControl; interface LocalizationSensor; } uses { interface Sensor; } }
module PrototypeLocalizationDataManagerM { provides { interface StdControl; interface LocalizationData; } uses { interface LocalizationSensor; } }
module PrototypeLocalizationComputationM { provides { interface StdControl; interface LocalizationCompute; interface LocalizationSensor; } uses { interface LocalizationData; } }
module PrototypeLocalizationControlM { provides { interface StdControl; } uses { interface StdControl as LocalizationSensorControl; interface StdControl as LocalizationActuatorControl; interface StdControl as LocalizationDataControl; interface StdControl as LocalizationComputationControl; interface LocalizationActuator; interface LocalizationCompute; } }
interface LocalizationActuator {
command result_t Actuate(
uint16_t actuationDestinationAddress,
uint16_t dataDestinationAddress
);
}
interface LocalizationSensor { event result_t DataSensed( localization_t newData ); }
interface LocalizationData {
command result_t GetLocalizationInfo(
uint16_t moteID
);
}
interface LocalizationCompute {
command result_t Localize();
}
typedef struct { uint16_t moteID; distance_t* distanceFromMe; angle_t* distanceFromMe; location_t* distanceStdv; } localization_t;
typedef struct {
uint16_t EstimatedXCoord; //or theta angle for spherical coords
uint16_t XCoordStdv;
uint16_t EstimatedYCoord; //or phi angle
uint16_t YCoordStdv;
uint16_t EstimatedZCoord; //or r value
uint16_t ZCoordStdv;
uint16_t CoordinateSystemID;
} location_t;
typedef struct {
uint16_t DistanceFromMe;
uint16_t DistanceStdv;
} ranging_t;
typedef struct {
uint16_t phiAngleRelativeToMe;
uint16_t phiAngleStdv;
uint16_t thetaAngleRelativeToMe;
uint16_t thetaAngleStdv;
} angle_t;
Note that these interfaces are really simple and don.t support any protocols. However, you can always wrap any sub-system in a component that gives you a more sophisticated interface to support your protocol. For example, you may want an interface that allows you to request N chirps at frequency F. This can be done with a wrapper class around your LocalizationActuator component. You might also have motes that want to ask other motes for their locations. You can do this by wrapping your LocalizationData component in a wrapper component that interprets packet commands. By not including these things in the interfaces above, we are separating the functionality from the protocol, thereby allowing us to interchange protocols.
Given the above about protocols, we do not have to make any assumption that each mote has all four sub-systems (i.e. a homogenous assumption). For example, system control might be contained in a single "leader" mote or all computational sub-system might be implemented centrally on a PC. In my particular case, for example, all I have is a sensor/actuator system that sends time of flight chirps and makes ranging estimates. I could wrap it in a wrapper component that chirps when it receives my command packet and sends me back the data in a data packet. Then, data management, computation, and chirp scheduling is done centrally in Matlab. This is good for incremental development.
Notice that we have a huge problem with data representation. If the above localization_t data structure is not sufficient for all or most localization applications, there is little hope of interchanging components. I note three main problems here: units, coordinate systems, and error terms.
Do we store every distance estimate with its units (i.e. cm or meters or hop-counts) or do we just use the convention that all distances are in centimeters. What about systems with relative distances that don.t know the units of their ranging estimates? In the above localization_t data structure I assumed we would use the convention that all distance estimates are in centimeters and all rho/theta estimates are in degrees.
Are all of our positions stored with their coordinate systems, eg. if this position is in GPS coordinates it should say so? What about relative coordinate systems? Do we need a LocalizationCoordinateSystem component to bootstrap a coordinate system? How do we identify the units of a relative coordinate system? How do we identify the identity of a relative coordinate system, i.e. when two networks that have different relative coordinate systems meet, how do we resolve them? What about networks that have two overlaid coordinate systems, i.e. it has some GPS nodes and some nodes on a relative coordinate system or room-based coordinate system. In the above localization_t data structure I assumed that we could identify each coordinate system with the ID of the leader or creator of that coordinate system. However, I have not defined a coordinateSystem component.
Quite often your ranging or angle estimations or location estimations come with error terms. How do we represent this? With a canonical probability distribution? We could assume Gaussian noise on everything and always couple every estimate with a standard deviation. Is that sufficient for everybody? In the above localization_t data structure I assumed that it is.
We propose the following tentative module for power management in NEST challenge application on Berkeley OEP. The module provides interfaces for implementing both centralized and decentralized power state control algorithms of wireless sensors.
The centralized version contains TurnOn and TurnOff interfaces for a sentry to control the power states of each individual sensor in its group. If a sentry needs to turn a particular sensor off, it broadcasts a remote_turn_off message with the sensor ID and the period in which the sensor wakes up and checks for remote_turn_on messages; If such a message is detected, that sensor stays on, otherwise, goes back off. The sentry knows when to send out remote_turn_on or new remote_turn_off messages to a sensor because it knows when that sensor wakes up to check for messages.
In the decentralized version, each non-sentry sensor decides locally on the power state transitions. This approach uses PowerMangementAlgorithm interface to control the power state transitions. The algorithm interface, based on current length of idle time, decides whether the sensor turns off or stays on, and when is the next control epoch. Before the sensor turns off, it sends out a off_notification message to notify the sentry that it is going to wake up and check for messages at the next control epoch; The sentry can then use remote_turn_on message to wake up the sensor if it needs to do that at that time.
module PowerManagement { // module Sentry; // module NonSentry; provides { interface TurnOff; interface TurnOn; } uses { interface PowerMangementAlgorithm; } }
module Sentry { provides { interface TurnOff; interface TurnOn; interface OffNotified; } uses { command remoteTurnOff; command remoteTurnOn; } }
module NonSentry { provides { interface LocalTurnOff; interface LocalTurnOn; } uses { interface OffNotifying; interface PowerManagementAlgorithm; } }
interface TurnOff { command result_t remoteTurnOff( remote_turn_off* msg ); }
interface TurnOn { command result_t remoteTurnOn( remote_turn_on* msg ); }
interface OffNotified { event result_t offNotification( off_notification* msg ); }
interface LocalTurnOff { event result_t localTurnOff( boolean remote_or_local, remote_turn_off* msg, power_state_control* action ); }
Interface LocalTurnOn { event result_t localTurnOn( boolean remote_or_local, remote_turn_on* msg, power_state-control* action ); }
interface OffNotifying { command result_t offNotifying( off_notification* msg ); }
interface PowerManagementAlgorithm { command result_t powerMangementAlgorithm( unsigned int idle_time_length, power_state_control* action ); }
typedef struct {
unsigned int moteID;
unsigned int waking_up_period;
} remote_turn_off;
typedef struct {
unsigned int moteID;
unsigned int current_time;
} remote_turn_on;
typedef struct {
unsigned int moteID;
unsigned int expected_wake_up_time;
} off_notification;
typedef struct {
boolean on_or_off;
unsigned int next_control_epoch;
} power_state_control;
We consider routing as passing a message of arbitrary size (with some upper limit defined by length type) from a source to one or a set of destinations anywhere in the entire network. There are two functions for the routing components: one is to segment data into packets at the source and reassemble at the destinations, and the other is to choose one or a set of next hops for passing the packets to their destinations.
There are various ways to specify message destinations and preferable routes. In this architecture, we present some commonly used ones, although it is subject to extensions. We intend to only make common routing interfaces, rather than common routing algorithms and component implementations. Applications should be able to switch between different routing components that provide the same set of interfaces. In addition to message sending interfaces, there is a routing interface that signals the message arrival event, which can be wired to upper-layer components. Each routing component will be required to implement this capability.
The following diagram shows how the routing components will be composed in the context of TinyOS. Routing components, e.g. ROUTE-1 or ROUTE-2, will be on top of AM_STANDARD component. AM_STANDARD demultiplexes incoming requests to the appropriate routing component. Each routing component will be used by one or more high-level application components. In the following diagram, ROUTE-1 is used by COM-11 and COM-12, and ROUTE-2 by COM-21 and COM-22.
All communication goes through AM_STANDARD, which defines the top of the shared network stack. The routing components implement the same generic interface. That is, the interface between COM-11 and ROUTE-1, the interface COM-21 and ROUTE-2 is the same regardless of the routing algorithm. This makes it easier to .wire together. components in TinyOS.
By sharing the same interface, we can easily add new components in the communication stack whenever necessary. For example, we can add the SECURITY_COM component, which can be used by more than one routing components like the following. Here, ROUTE-1 and ROUTE-2 use the SECURITY_COM whereas ROUTE-3 does not.
interface ReceiveRoutingMsg {
/**
Receive message done signal <p>
@param length The length of the message
@param msg The message just sent out
*/
event result_t receive(
uint8_t length,
char* msg
);
}
This interface provides a message arrival signal, indicating a message arrived to one of its destinations. In addition to the message itself, the length of the message is provided. All routing modules have to provide the above interface. In addition, routing modules may also provide some of the following interfaces.
interface GetRoutingMsgSource {
/**
Get the source of the last message received <p>
*/
command uint16_t get();
}
interface GetRoutingMsgHopCount {
/**
Get the hop count of the last message received <p>
*/
command uint8_t get();
}
interface GetRoutingMsgTimeStamp {
/**
Get the time stamp of last message received <p>
*/
command uint8_t get();
}
interface SendRoutingMsg { /** Send a message out to one or more remote motes <p> @param dest The destination( s ) @param length The length of the message @param msg The array of bytes need to send out @return SUCCESS if successful */ command result_t send( destination_t dest, uint8_t length, char* msg ); /** Send message done signal <p> @param msg The message just sent out @param success If the send is done successfully */ event result_t sendDone( char* msg, result_t success ); }
This is a general interface for all routing components. We have identified a number of specific routing techniques that can be implemented using this interface. Here the destination is a union of all the types used for these techniques. This is a parameterized interface where the type of destinations shall be associated with send when the actual wire takes place. The union type is defined now as:
typedef union { uint8_t hops; uint16_t address; location_t *location; CBR_t *dest; } destination_t;
where CBR_t is
typedef struct { routing_t type; constraints_t *dest; constraints_t *rout; objectives_t *objs; } CBR_t;
In the following sections, we specify separate interfaces that may be used to wrap the generic interface for specific routing techniques.
interface SendMsgByBct {
/**
Send a message out <p>
@param hops The number of hops to the source
@param length The length of the message
@param msg The array of bytes need to send out
@return SUCCESS if successful
*/
command result_t send(
uint8_t hops,
uint8_t length,
char* msg
);
/**
Send message done signal <p>
@param msg The message just sent out
@param success If the send is done successfully
*/
event result_t sendDone(
char* msg,
result_t success
);
}
This interface specifies a local broadcast function of routing, i.e., send the given message to all nodes within the number of hops.
interface SendMsgByID {
/**
Send a message out <p>
@param address The ID of a remote mote
@param length The length of the message
@param msg The array of bytes need to send out
@return SUCCESS if successful
*/
command result_t send(
uint16_t address,
uint8_t length,
char* msg
);
/**
Send message done signal <p>
@param msg The message just sent out
@param success If the send is done successfully
*/
event result_t sendDone(
char* msg,
result_t success
);
}
This is the simplest interface where node ID/address is specified for destination.
interface SendMsgByGeo { /** Send a message out to location( s )<p> @param location The pointer to a location structure representing a remote mote or motes @param length The length of the message @param msg The array of bytes need to send out @return SUCCESS if successful */ command result_t send( location_t *location, uint8_t length, char* msg ); /** Send message done signal <p> @param msg The message just sent out @param success If the send is done successfully */ event result_t sendDone( char* msg, result_t success ); }
This interface is for sending an array of bytes to one or all nodes defined by geographical locations. Locations are described by
typedef struct {
routing_t type; //one or all
int16_t xCenter;
int16_t yCenter;
uint16_t range;
} location_t;
The same interface can be used for position-based as well as direction-based locations. For direction-based routing, x and y are interpreted as directions.
interface SendMsgByCBR { /** Send a message out to a remote motes satisfying a set of constraints while choosing a route that is optimal and satisfying route constraints <p> @param type one or all @param dest destination constraints @param rout route constraints @param objs objectives @param length message length @param msg array of bytes need to send out @return SUCCESS if successful */ command result_t send( routing_t type, constraints_t *dest, constraints_t *rout, objectives_t *objs, uint8_t length, char* msg ); /** Send message done signal <p> @param msg The message just sent out @param success If the send is done successfully */ event result_t sendDone( char* msg, result_t success ); }
In this interface, destinations are specified by constraints, each of which is a range of attribute values. Attributes can be constant (ID, energy cost, etc.) or be variables (sensor readings, battery level, time, etc).
The attribute interface in TinyOS-1.x will be used. In addition to destinations, this interface can also specify route constraints and objectives, where objectives are represented as minimizing or maximizing some attribute values over the overall routing path. The types of constraints and objectives are defined as follows.
typedef struct {
uint8_t id; //attribute id
int16_t lower;
int16_t upper;
} constraint_t;
typedef struct {
uint8_t id; //attribute id
uint8_t type; //maximize or minimize
} objective_t;
typedef struct { constraint_t *cons; uint8_t num; } constraints_t;
typedef struct { objective_t *objs; uint8_t num; } objectives_t;
interface LocalLookup {
/**
lookup remote attributes by name<p>
@param address The ID of the remote mote
@param name The name of the attribute
@param result The result of the lookup
@return SUCCESS if attribute exist otherwise FAIL
*/
command result_t lookupByName(
uint16_t address,
char *name,
char *result
);
/**
lookup remote attributes by attribute ID<p>
@param address The ID of the remote mote
@param id The id of the attribute
@param result The result of the lookup
@return SUCCESS if attribute exist otherwise FAIL
*/
command result_t lookupByID(
uint16_t address,
uint8_t id,
char *result
);
}
Some routing components may be able to provide some local information for remote nodes, such as the estimated number of hops, etc. This interface provides a generic way of accessing such information, and assuming such information would be stored in the form of attributes (provided by the attribute interface in TinyOS-1.x)
Given the above set of interfaces, there will be the component implementations by various groups participating in routing. One can implement a single module that provides all the interfaces, or implement a set of modules, each of which provide a subset of interfaces. Applications should be able to switch from one set of implementations to another set of implementations. Implementations from different groups are not required to be compatible to be compiled and linked into one application, beyond the compatibility of the common interface. Here we just gave one example of the skeleton of the implementation. Note that SendRoutingMsg is a parameterized interface with type specified as:
typedef enum {
tSEND_BY_BROADCAST = 0,
tSEND_BY_ID = 1,
tSEND_BY_LOCATION = 2,
tSEND_BY_DIRECTION = 3,
tSEND_BY_CBR = 4
} routing_service_t;
module ParcRoutingM { provides { interface SendMsgByID; interface SendMsgByGeo as SendMsgByLoc; interface SendMsgByGeo as SendMsgByDir; interface SendMsgByBct; interface SendMsgByCBR; interface SendRoutingMsg[uint8_t type]; interface ReceiveRoutingMsg; interface GetRoutingMsgSource; interface LocalLookup; interface StdControl; } uses { interface Leds; interface SendMsg as SendMsgGenericComm; interface ReceiveMsg as ReceiveMsgGenericComm; interface StdControl as StdControlGenericComm; } }
Three types of functions will be supported in the TTF_Coordinator component.
Clocks are well synchronized among motes.
module Coordinator { provides { interface TTF_Coordinator; } uses { } }
interface TTF_Coordinator { /* to register a TT function with the coordinator */ command INDEX RegisterTTF( TTFRequest * ); /* to invoke a service function */ command void InvokeSvF( SvFRequest * ); /* to update t he execution schedule based on existing registered TTFs */ command void UpdateExecSchedule(); /* to dispatch next ready function in the execution engine */ command FuncType* DispatchNextFunc(); /* to retrieve a timing error report */ command TimingErrorRept * RetrieveNextErrorRept(); }
TTF_Coordinator component contains data structures which maintain timing requirements for TT functions, the execution schedule, and possible error records, and provides several APIs for manipulat ion of those data structures. Application designers will provide bodies of Time -triggered (TT) functions in application components and will register them to TTF_Coordinator along with relevant timing requirements and interrupt enabling/disabling options. TTF_Coordinator is responsible for maintaining the execution schedule by reflecting the timing requirements of registered TTFs and the SvF requests generated. The function of main() will dispatch TTFs and SvFs according to the Execution Schedule and execute them with interrupts enabled and disabled as specified. Possible error conditions, such as deadline violation, can be detected/reported either by TTF_Coordinator or by main(), and error records will be stored in TTF_Coordinator. Application components may retrieve the error records later and take appropriate actions.
/* function pointer type for all TTFs and SvFs */ typedef void( *FuncPtr )( void* );
/* an index to a registered TT function, used for future unregistration */
typedef int INDEX;
typedef int MicroSec;
/* indicating the type of execution errors, such as deadline violation */
typedef int ERR_CODE;
typedef struct { /*the time when a TT function will be ready to be scheduled */ MicroSec LoopStartTime; /* the time when a TT function will be deleted from the TT scheduler */ MicroSec LoopEndTime; /*LoopStartTime+( i-1 )*IterationInterval is the time the i-th TT function will be scheduled / executed */ MicroSec IterationInterval; /*The earliest time at which a TT function may start in each cycle */ MicroSec EST; /*The latest time at which a TT function may star */ MicroSec LST; /*LoopStartTime +( i-1 )*IterationInterval +GCT is the time by which the i-th TT function should finish its execution */ MicroSec GCT; } AAC;
typedef struct { /* function pointer to TT function */ TTFunc ptr_to_ttf; /* input parameters for TT function */ void * parameter; /* timing requirements */ AAC aac; /* indicating whether enabling/disabling certain interrupts during a TTF execution */ int interrupt_vector; } TTFRequest;
typedef struct { /* function pointer to SvF */ TTFunc ptr_to_svf; /* input parameters for SvF */ void * parameter; /* timing requirements */ MicroSec MED; /* indicating whether enabling/disabling certain interrupts during a SvF execution */ int interrupt_vector; } SvFRequest;
typedef struct { /* indicating the type of the error detected, e.g., deadline violation */ ERR_CODE err_code; /* indicating the reporter of the error, e.g., main()or timer interrupt handler ? */ int reporter_id; /* indicating the time of error detection */ MicroSec timestamp; } TimingErrorRept;
typedef struct { /* indicating whether it is a TTF or a SvF */ int func_type; /* function pointer to a TTF or a SvF */ FuncPtr ptr_to_func; /* pointer to the input parameter of a TTF or a SvF */ void * parameter; /* start time window of a TTF */ MicroSec EST, LST; /* for a TTF, it represents GCT; for a SvF it represents MED */ MicroSec GCT_or_MED; / * interrupt enabling/disabling options */ int interrupt_vector; } FuncInfo;
Prepared 17 October 2002 by Ted Herman, University of Iowa (OSU group).
The pursuer-evader scenarios for the NEST Challenge, including near-term experiments, the midterm demo, and later demonstrations, require that motes have a synchronized time-base. Time synchronization is needed for mote location determination (localization), position and velocity estimation of evaders, and real-time calculations for pursuer strategies. These several needs for time synchronization have slightly different requirements for accuracy and tolerate differing interfaces for how the time bases of distinct motes can be compared. Accordingly, we suggest an API with various time services.
Accurate localization may require time synchronization within about 10 microseconds; evader velocity estimation could be calculated to sufficient accuracy with time synchronized to within about 300 microseconds. For localization, it may be that differential calculations between pairs of motes separated by a few meters is sufficient; for the planning of multiple pursuers, a real-time calculation involving distant motes (tens of meters) may be needed.
Time synchronization requires communication; localization requires time synchronization; the speci- fication of communication services proposed by UVA (Routing, Estimation, and Group Management APIs) depends on localization. These dependencies need not be circular, since one of the communication services (SendLocal) is little more than a TOS local broadcast. Nevertheless, we prefer to use some "communication services" outside of the current set of proposed interfaces; these are documented below (they could well be implemented within the TimeSync component, but we have a hunch that they may be useful elsewhere).
Note: UVA looked at these communication services and is agreeable to considering some support for them in the routing component; we'll wait until specifications are finalized and we also have more precise ideas about implementation to nail down these communication service specifications.
module PrototypeTimeSyncM { provides { interface Time; } uses { interface bdNeighbors; interface receiveMsg as ReceiveStampedMsg; interface sendLocal as sendNeighbors; interface sendByID; } }
Perhaps not the best choice, we bundle the commands into one interface (we could change this later).
interface Time { command result_t getLocalTime( time_t* time ); command result_t getGlobalTime( time_t* time ); command result_t xlatTime( time_t* ourtime, mote_id m, time_t* othertime ); }
getLocalTime is used to obtain the high-accuracy form of time, which has a local time-base. Think of it intuitively as every mote having its own "time zone". Such time is consistent for local real-time calculations. We imagine that this command fails if the clocks have not yet been synchronized (eg, the getLocalTime command is invoked too early in the initialization phase of system startup).
xlatTime is used to convert local time to the time-base of some other mote in the near vicinity (as mentioned above, this has to do with having a beacon in common to the two motes). There are two failure modes for this command: it fails if invoked before TimeSync initialization is completed; and it fails if attempting a conversion outside of common beacon vicinity (these should be distinct failure indications). Should applications need high-accuracy conversion between arbitrary motes -- not residing in a common beacon area -- we can also imagine adding another command for such a conversion. However, this would be a more expensive call, and it would be asynchronous (only later delivering the result via an event).
getGlobalTime obtains the lower accuracy form of time, which is common (plus or minus an error tolerance) to all motes in the system. Again, this command fails if invoked too early in system startup.
Robert Szewczyk suggest that we should use 48 bit counters (at the granularity of 32 KHz, or 31.25 microsec) for planning beyond the challenge to other applications.
typedef uint48_t time_t;
We don't yet have a spec for the message format(s), frame definitions and other things internal.


Code Kata #4 - Data Munging Part One
Overview
The fourth Code Kata in Dave Thomas’ Code Kata blog asks you to do the following:
write a program to output the day number (column one) with the smallest temperature spread (the maximum temperature is the second column, the minimum the third column).
He provides a weather.dat file for you to download and which you will parse through in order to obtain the solution. In this post, I will only cover the first part of the code kata. I completed the first part of the kata over the course of 3 days working up to 4 hours on one day and thinking about the problem when not in front of the computer screen. Let’s take a look at a solution I developed.
The Completed Code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
TDD is Software Improv
It is unfortunate that I didn’t capture the dynamic interplay between writing/rewriting the tests and writing/rewriting the code in this example. I think I originally heard it from David Chelimsky at SCNA 2011 who said that Test Driven Development is Software Improv. TDD is a sweeping movement involving writing your tests, writing code to pass your tests, refactoring your code, refactoring your tests, critiquing your code to determine how you should write your next test, and critiquing your tests to inform the design of your code. TDD truly is an art form.
Even as I write this post, I understand how difficult it is to capture the TDD process in writing. Have you ever seen Live Improv as a series of photos? For one thing, you won’t catch the humor in the dialogue. You might laugh at the pictures, but you won’t get the jokes unless you had understood the context in which they were delivered; that’s where the dialogue is important. But listening to the dialogue alone isn’t enough. You wouldn’t be able to capture the subtle nuances in the gestures of the performers. The photos wouldn’t capture that because they are minutes, even seconds apart. Now what happens if you see Live Improv as an audience member? You finally get it. In the same way, TDD cannot be expressed as a static blog post. I do not do it justice by simply talking about it; however, I will do my best to inform you what happens in the process of doing TDD.
Debrief
How’d you get there?
At the beginning, I started writing very trivial test cases that would check for the return type of the read
method. It would check to make sure that the return values were not nil. Of course, you don’t see these test cases in the final product. That’s because those tests acted like scaffolding that I temporarily used to get me started. After I build the right structure in my program, I wrote other tests that rendered that scaffolding test code obsolete.
TDD is an incremental process. You should only be writing the minimal amount of code to make your tests pass. I think this is where I didn’t do as great a job executing TDD. Once I understood the pattern of the code I needed to write, I went ahead and wrote that as production code. In the real world, the patterns won’t be as obvious and it will take having to write code for every case until you see an overarching picture of the kind of code that would cover the general case.
The example I will cite here is when I test a single line of data to determine if I get the right value for the spread of the maximum and minimum temperature. The next thing I do is write the code that does that for every line of code. Probably the way I should have gone about that was to write a regular expression that was hardcoded to that particular string. Then I should have thrown in another case where there is an asterisk next to the maximum or minimum temperature as is true for day 9 or day 26 in the weather.dat file. When you work on a larger project, it may not be obvious how you can generalize the production code you need to write. Thus, it is a good habit to build your program incrementally when you do TDD.
Programming With Lambdas
Recently, I have been making more of an effort to introduce lambdas in my code. Lambdas and Procs were one of the most nebulous ideas for me when I first started programming in Ruby. Only recently did I start playing with passing lambdas as arguments to methods. Originally, the no_data
method wasn’t in my code. It came about during the refactoring phase when I wanted to make the read method more concise (and curiously also wanted to see if I could extract the code block into something more meaningful). The code had read like so:
1 2 3 4 5 |
|
Now, there’s nothing wrong with that. However, if I were another programmer trying to read this code, I would be asking myself, “What are you matching against?” So I decided to write this instead:
1 2 3 |
|
To me that reads more clearly than the first example. It may be a little difficult for newer programmers to understand what the syntax is doing. But it is clear that I am rejecting data from the lines of the file I read. Here is the code for the no_data
method.
1 2 3 |
|
The name of the method communicates its function. It defines what data is not; however, I probably could have written a different name for regex
. Looking at it right now it doesn’t communicate its intent. Perhaps, I should have written something like this:
1 2 3 |
|
That would have been more helpful to someone who is trying to find out how the no_data
method works.
Being Expressive with Regular Expressions
If that same programmer wanted to see what regex
would look like, they would see this:
1 2 3 4 5 6 7 8 9 |
|
Originally, I had written down this expression:
1 2 3 |
|
What is that expression supposed to be doing? It is capturing three groups of numbers that are separated by spaces. But those numbers don’t have any meaning at all! That’s when I decided to use the ‘x’ option to allow spaces in my regular expression. I went ahead and added named subroutines in order to layer the regular expression with meaning. Notice that I named the groups as <day>
,<max>
,<min>
—all names that are relevant to the problem at hand. Unfortunately, those names alone don’t provide much meaning to the problem, I probably should have been a bit more descriptive with the names: “Maximum of what?”, “Minimum of what?” “Are we talking about heights? weights? distances?” A better implementation would have been:
1 2 3 4 5 6 7 8 9 |
|
The reason why I didn’t add the names max_temperature
, and min_temperature
, was because of the way I implemented the temperature
method in my program.
Something Smells
Take a look at the following code:
1 2 3 4 5 6 7 8 9 |
|
Had I changed the names in my regular expressions, I would have had to change the above code to this:
1 2 3 4 5 6 7 8 9 |
|
Why is temperature mentioned twice in a method call? It is adding too much noise. I should have just gotten rid of the temperature
method and attempted a better implementation like so:
1 2 3 4 5 6 7 8 9 10 11 |
|
Even the above implementation is too long to read, but it communicates its intent better than the method I had written.
Take Aways
When doing TDD, you always need to keep in mind the other programmer who will be reading your code. It is not enough to make the program work; it needs to be readable and easy to understand for the rest of your team.
There are other things I didn’t get a chance to cover in this post that would have made it too long: one of those things included the implementation of finding the smallest spread and the date for that spread. I’d like to see your implementation of this code kata. Perhaps there is some other way of implementing this that had not occurred to me. I welcome your insight. I invite you to provide any feedback in the comments below.


Assignment 6
Section Index
Synchronous solution
An asynchronous attempt
Event handlers
Event listeners
Promise nesting
Promise chaining
Async/await


Please fill out this form in order to provide us with your feedback. If you have any questions, feel free to contact Adam Noelting via email at<EMAIL_ADDRESS>Thank you for your time, and assistance with the development of our updated Projects Website and Database.


WITNESS LIST Criminal Jurisprudence Committee May 17, 2005-2:00P SB 251 For: Hampton, Keith S. (Texas Criminal Defense Lawyers Association) On: Edmonds, Shannon (Texas District and County Attorneys Association) SB 304 For: Schaeffer, Brian D. (Texas Association of Campground Owners) SB 309 On: McCleskey, Gene (Office of the Attorney General) Millholland, Herman (Office of the Attorney General) Rocha, Felipe (Texas Department of State Health Services) SB 394 On: McCleskey, Gene (Office of the Attorney General) SB 395 On: Marsh, Andrea (ACLU of Texas) SB 615 For: Crook, Bret (Woodway Public Safety Department) Roberts, Douglas (United States Secret Service) SB 837 For: Brady, Denise (Mental Health Association in Texas) Keating, Kevin (Harris County District Attorney's Office) Starnes, Jane (Self and Williamson County District Attorney) On: Lopez, Chris (Department of State Health Services) SB 905 For: McDaniel, Breck (Houston Police Department) SB 1265 For: Gerlich, Stan (Self and One Source Toxicology) Laurel, Romeo F. (Self and One Source Toxicology) York, Kevin F. (Self) Against: Baird, Gary (Compliance Consortium Corporation) Gibbs, Bill (Self) Pichinson, Michael (Texas Conference of Urban Counties) On: Cahill, Melissa (Collin Co. CSCD, Collin County District Judges, Texas Probation Association) Hendrick, Dana J. (Self) SB 1275 For: Fuller, Darla (Self and Travis County Sheriff's Law Enforcement Association / Fraternal Order of Police Lodge #912) Geerhart, Connie (Self) SB 1507 For: Hampton, Keith S. (Texas Criminal Defense Lawyers Association)