Minutes20101110

Gumstix OS

Options
  • use something prebuilt
    • ROS (Willow Garage)
      • Lots of pre-written controllers, sensor interfaces, etc
        • Provides API for drivers, implementation already exists in specific lanuages
        • Code in python, C++, etc (flexible)
      • Ex
        • Sonar Node: responsible for moving the sonar around, collecting sonar data - makes the data available to other nodes via interface
      • Need to code drivers for the different sensors
      • Cons
    • Other pre-built solutions
      • Examples?
  • roll your own Colonix
    • assumption is "we'll understand it better"
    • buggier, takes a long time to develop
    • faster to get stuff running
core os up & running (openembedded linux)
ROS up and running (compile it)
actually writing drivers between ROS and hardware
Applications
  • compile on Gumstix OR computer?
repository structure for all the compiled binaries (version, compatibility, etc)
  • dependencies

AVR & Gumstix

  • comms library to ARM9
  • Bottleneck
    • timing for all the sensors
    • speed for the comms link
    • If no bottleneck exists, just send everything all the time
  • what is transfer rate of UART?
  • maximum input rate from wireless, sensors, how much data (bits & frequency)
    *acks?
    • on AVR side, single data register for send/receive
    • handling collisions?
*sonar
  • define modes for scanning patterns (timing to complete a sweep)
    • speed tied mode (automatically) to determine number of scan points
    • manual control (useful for mapping or tracking obstacles, etc)
  • cliff sensors
    • very high priority (not sure how this works in ROS)
  • watchdog timer?
LIKEY!
*priority queue publishing of sensor data
  • high priority can get bumped to the top
  • packet structure
    • definition of bytes that get sent between the procs
    • msg type, length/payload type, timestamp, probably don't need CRC
  • timestamped sensor data (ex. tying sonar to location that the ARM9 knows)
    • syncing the time between the 2 procs (handle that at startup?)
      • take into account comms latency?
  • making the beginning of a packet special
    • 9 bit address
    • byte stuffing
*toggle a flag for sending over UART, Wireless, or both..
  • how stale are values going to be if we shuffle values to the ARM and back to the wireless...

AVR

  • Scheduler or timer interrupts
    • Hierarchy (again, priority arbitration)
    • at least be able to queue functions to run
      • variable priority for accessory pins?
      • spacing for other priorities? so you can insert your accessory between "anything"

accumulating packets on the AVR
buffer then send chunks to the ARM

porting existing wireless on the AVR
overhead for AVR -

No bugs in planner! Or else...
  • thinking about escape manuevers for cliff sensors, etc
  • taking control over motors, what if you are doing mapping
    • since planner is in control, and we are still integrating position data from encoders, gyro, etc, we will still know where we are

Dev camp 1 : DEBUGGING AVR
small wrapper functions for reading sonar, etc
no utility functions (no high level)
get stuff working, see the robot working

Dev camp 2 : GETTING ROS WORKING

pdeo@
jdcooper@