Giter Club home page Giter Club logo

labsight's Introduction

LabSight

A collection of code for controlling motors, intended for probe drives. Includes an Arduino sketch, a Python control library and a GUI for using all of it.

Files

The current goal for these files is that they allow you to control motors, in a manner similar to NI MAX. Functionality for dataruns will be added later.

Any planned functions will be added to these files as is seen fit.

File List:

  • child.ino

    • Supports every Arduino command of the protocol as outlined in the Google doc
  • controller.py

    • Based off of the current Controller.py
    • Conducts the serial communications, and contains the base functionality for all of the various protocol commands related to the controller
    • Communicates with the arduino for the GUI
  • application.py

    • The first program that is run when the GUI is started.
    • Coordinates all actions of the GUI
  • window.py

    • Some utility functions that allow the GUI to exist, and set up everything for the rest of the GUI files
  • main.css

    • CSS styling for the GUI
  • MotorControl.py, MotorList.py, WelcomeView.py

    • Welcome view is what is diaplayed upon opening the application for the first time, when no Arduinos are connected
    • Motor list is the menu shown for listing each motor
    • Motor control is the view that can be accessed for each motor from the motor list, allowing you to move the and configue the motors in various ways
  • CalibrateDialog.py and NewMotorDialog.py

    • Calibrate dialog is used for inputting conversions between degrees/centimetres and steps
    • New motor dialog is used for giving the motor a name, and setting its axis and movement type
      • Functionality is minimal at this point for these configuration settings
  • config.py

    • Various global infos for the GUI
  • labsight-control

    • A bash file for starting the GUI
  • ModeButton.py

    • A widget for changing between steps and the appropriate unit, while in the motor control view
  • datarun.py

    • A placeholder file for our later datarun functionality
  • init.py

    • Various files necessary for the creation of a Python library
    • Adds certain features that ease accessing functions from within the library

Protocol

  • Every message has three parts (symbol, command, data)
    • Symbol indicates the how the action is performed
      • Symbols are always 1 character
    • Command indicates the specific action
    • Data consists of the arguments or output for the action (this depends on the symbol used)
  • Controller initiates all contact and child always responds with something
  • Send underscore _ when there is no data to send
  • Symbols
    • Used by Controller:
      • Questions, like a get function (?)
      • Commands, like a set function (!)
    • Used by Arduino:
      • Responses from Arduino ($)
      • Stream (>)
      • Errors (@)
  • Motor Index
    • Specifies which of the up to two motors per Arduino you would like to apply the given command to
    • It is zero-indexed
  • Commands
    • init - A function that starts the streaming of encoder data. It was implemented so that when the Python library checks for the version and id, it is not immediately overwhelemed by frivolous encoder readings
    • version - Returns the protocol version upploaded to the arduino, for compatibility reasons
    • id - Allows the getting and setting a string to identify the arduino by
    • step - Enables one to get the current position in steps, as well as to set the current step, AKA moving the motor
    • style - Used for the changing of stepping style between "single", "double", "interleave", and "microstep"
    • kill - Kill the motor, allowing the axle to be turned freely
    • halt - Stops the motor's movement immediately, but does not release it

Arduino Pins:

This pin scheme is meant for the Arduino Uno, though it may work on other boards. The only pins used are digital, so everybody listed below is assumed to be digital.

  • Pin 0 and 1:
    • Not used because let's not mess with serial communication pins
  • Pins 2 and 3:
    • Pin 2 is attached as an interrupt to update the encoder position
      • The Arduino's loop function was not fast enough to read the encoder positions at the appropriate rate, so we have an ISR for updating the encoder position attached to this pin
    • A 5 kHz square wave from pin 8 triggers this interrupt
    • Pin 3 is not used currently, because interrupt pins are precious on the Uno
  • Pins 4 and 5:
    • Read the waveforms for the two channels of encoder 0 (which is attached to motor 0)
  • Pins 6 and 7:
    • Do the same thing as pins 4 and 5 for encoder 1
  • Pin 8:
    • Emits a 5 kHz square wave to trigger the ISR at pin 2
  • Pins 9, 10, 11, and 12:
    • Kill switches (2 per motor for each end of the motor's axis) are attached here
    • See the note below for more details
  • Pin 13:
    • Not used because we'd rather not mess with the LED if we don't have to

A note about kill switches: The pins for the kill switches use a pullup resistor that sets them at HIGH. Therefore, if a kill switch is not connected, the Arduino will fail-safe, and believe it is being killed. Not only is this terrifying and misleading message of imminent demise endangering the Arduino's mental health, it also prevents the motor from being moved. Make sure to have all 4 kill switches attached, or else none of the motors will be able to move!

Original Objectives for the GUI:

  • A GUI class that communicates with controller.py, and provides NI-MAX functionality
  • It will ultimately manifest itself as a sidebar, but for now it will probably be the only GUI we have.
  • Features:
    • Motor Dashboard that indicates for each motor (in no particular order):
      • Has it been killed?
      • Is it moving?
      • Is it ready?
      • Has an error occurred?
    • Movement (which can be converted between centimeters or steps)
      • Relative motion
      • Absolute motion
    • Setting the origin
    • Changing the motor's speed
    • Ability to change between motors

labsight's People

Contributors

sbuckleybonanno avatar sgpthomas avatar

Watchers

 avatar  avatar  avatar  avatar

labsight's Issues

Reloading is slightly broken and needs to be improved

The current way of reloading only creates the ListBoxRows after the entire loading process is done. I would like it to generate the Rows as it finds new motors. This might require a change to the library. The getAttachedSerials() might need to take an optional callback argument to do this. Also, we only want to create new ListBoxRows when a motor doesn't already exist. Currently, we can get duplicate ListBoxRows

How to halt?

How we can have the halt feature, in order of my preference for each:

  1. The motor can only move one step at a time, and must be told to move by command from the computer for each step
    Pros:
    Fairly limited use of serial communications (though much more than the current setup)
    Halting is as simple as not sending any more move messages
    Cons:
    I don't know how we would get the encoder to work under this setup
    Movement is reliant on the serial working, and can only go as fast as the serial
  2. Have the Arduino send a signal for every step like it already does, but the Arduino does not move again until a confirmation message is sent by the computer to the Arduino. This confirmation message can halt the movement if necessary.
    Pros:
    Encoders would be easy to implement using this, as the data could just be sent by the Arduino each time it gets a turn to send a message
    Halting is about as easy as above.
    Cons:
    This is quite taxing on the serial link
    Movement would be even slower than above, as there wold be twice the number of messages
  3. Keep the Arduino as it is, but have a kill switch hooked up to an interrupt.
    Pros:
    Very easy to implement
    Limited amount of serial communication (the same amount as our current setup)
    The encoder would be functional, as it would communicate using the serial
    Cons:
    The computer won't be able to halt

As a general recommendation for anything involving looped serial communications, we may be required to send messages with a length less than the standard 3 arguments. This entirely depends on the capability of the hardware, which we can test.

Hopefully, the hardware will permit the second option, as it is the only one that has all the necessary features.

Support for Multiple Motors attached to one arduino

I'm not quite sure how we want to do this in the protocol. If it's only possible to move two motors, we might want to just have two separate commands for moving the motors. Either step0 or step1. Another option would be to include a motor number with the symbol. So it would be !0 step n or !1 step n. I personally like the separate step commands better because I think it's slightly more consistent with our current protocol. Note that this would also require a change in how the library works because you would still want one motor object connected to one physical motor. If you didn't change anything, on python 'Motor' would actually represent on physical arduino

Optimize Serial

  1. Up the Baud rate
  2. Shorten the data packets as much as possible
  3. There are probably other things to do

New calibration dialog for Linear Motors

Would walk you through this process:

  • Mark where the motor is now.
    • Press 'start' to continue
  • Move the motor 200 steps
  • How far did the probe move?
    • Box to enter distance
    • Button to confirm
    • Button to move further

Reload Button

Add a reload Button to the MotorList. This would call the start_load function. During the loading process, it would show a progress bar while it was loading. I think that we could somewhat accurately fill it up based on the numbers of ports detected. I think that the communication process with the arduinos takes a pretty consistent amount of time.

Kill button

Figure out where to put the button to kill the motor

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.