sim_motor_nims.h from EmStar at Krugle
Show sim_motor_nims.h syntax highlighted
/*
*
* Copyright (c) 2003 The Regents of the University of California. All
* rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Neither the name of the University nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS''
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
* PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
/*
* *** This is a device interface header file. ***
*
* (This comment describes what that means)
*
* Emstar device interfaces are always associated with a header file
* that defines the interface. These _interface_ headers are normally
* placed in the include directory, while implementation-specific
* headers (that clients don't need to see to use the device) are
* placed in the same directory as the source code.
*
* The interface header typically includes three things:
*
* + #defines that define the string names of the devices that make up
* the interface. We always wrap these strings with the sim_path()
* macro. This is a bit of magic that makes simulation work.
*
* In some cases these string names are parameterized with printf
* directives like %d, for example if there is an index number as
* part of the device name. In such cases, it is usually helpful
* to include an API function that constructs these names for you.
* When implementing such a function, you should use
* DECLARE_STATIC_BUF_RING in libmisc/include/misc_string.h
*
* + Structures that define the binary outputs associated with the
* devices. A client that reads the device as binary will need
* this structure in order to correctly interpret the device output.
*
* + Prototypes of API functions that are part of the library.
* These should be C-accessible functions that help the client
* connect to and use the device. In some cases, nothing is needed,
* in other cases, there can be a substantial amount of client-side
* code needed to use the device. Many devices supply "event
* constructors" that make it easy to handle events on the device.
*
* NOTE: if the API functions introduce a lot of header dependencies
* it is sometimes better to separate the API prototypes out from
* the strings and structs. We usually do this by creating a
* separate XXX_structs.h header for the strings and structs,
* that is included by the "main" header.
*
*/
/*
* Motor controller device interface file.
*
* By opening the device and writing in a command (in the form of an
* ascii string), a client can request the motor to move to an arbitrary
* position.
*
* The command syntax is
* move:x=<x>:y=<y>
* where <x> is x coordinate, <y> is y coordinate.
*
* In addition, the opened device will become readable immediately upon
* open, and again whenever the current position changes. Reading the
* device will report the current position.
*
*/
#ifndef __MOTOR_NIMS_H__
#define __MOTOR_NIMS_H__
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include "libmisc/misc.h"
#include "libdev/status_dev.h"
#include "libdev/include/query_dev.h"
#include "link/link.h"
#include "emrun/emrun.h"
#define NIMS_MOTOR_CONTROLLER_DEV sim_path("/dev/motor/command_motor")
typedef struct motor_nims_pos {
float cx; /* current position */
float cy;
float v; /* current est. velocity */
float tx; /* target position */
float ty;
int busy:1; /*??not sure if this field is useful*/
} motor_nims_pos_t;
/*
** Typically we put all our global state into a single structure.
** this makes our life a lot easier if we ever need "more than one".
**
** Most emstar libraries and callbacks can accept a void pointer to
** a state block like this. However, if you're feeling lazy you can
** always just declare it as a global...
**/
typedef struct motor_nims_state {
status_context_t *status_ref; /* a reference to our status device */
/* most recent motor state */
motor_nims_pos_t pos; /* position and velocity */
struct timeval report_time; /* time of last report for computing vel */
//not sure whether this field is useful, since vel is set in the beginning
//when get chance to change velocity?? * /
struct timeval start_time; /* time when the motor started to move */
g_event_t *report_timer;
g_event_t *motor_timer;
int binary_mode_;
} motor_nims_state_t;
//flags used to parse motor command
typedef enum parse_state_type {
PS_INVALID =0,
PS_BEGIN,
PS_MIDDLE,
PS_END
} parse_state_type_t;
typedef enum return_state {
SUCCESS,
FAIL,
MOTOR_POS_SUC
} return_state_t;
typedef struct motor_cmd_return_state {
return_state_t state;
float cx;
float cy;
} motor_cmd_return_state_t;
typedef enum motor_command {
MOTOR_MOVE,
MOTOR_POS
} motor_command_t;
#define BUFSIZE 256
typedef char STRING[BUFSIZE];
long usec_diff( struct timeval * t1, struct timeval * t2);
int motor_process(query_context_t *q, char *command, size_t size, buf_t *print, buf_t *bin);
void motor_usage(query_context_t *q, buf_t *buf);
int motor_dev_init(int argc, char *argv[], motor_nims_state_t *mcs);
#endif
See more files for this project here
EmStar is a software system for developing and deploying wireless sensor networks involving Linux-based platforms. As the wireless sensor network community has attempted to deploy more complex designs---large-scale, long-lived systems that need self-organization and adaptivity---a number of difficult software design issues have arisen. Advances in software design have not kept pace with the capabilities of hardware. This is because designing for an adaptive, efficient, and useful sensor network has turned out to be surprisingly complex and difficult. EmStar is a Linux-based software framework, whose goal is to dramatically reduce this complexity, enabling work to be shared and reused, and simplifying and speeding the design of new sensor network applications.
Project homepage:
http://cvs.cens.ucla.edu/emstar/
Programming language(s): C,Shell Script
License: other
README
data_replay.c
data_replay_misc.cc
mote_packet.c
motor_command.c
motor_sensor_dev.c
sim_motor_nims.h
sim_sensor_nims.h