RIG InMoov Project
|
This is the official documentation for the Conestoga Robotics Innovation Group's InMoov project. It is not meant to be read linearly or all at once. Rather, readers should skim relevant pages and skip information that requires more context. More in depth information is provided for those that wish to modify the source code. Examples are provided when possible for quick reference and experimentation. Note that colored phrases are links for both html and pdf. This project has a git repository located here. You can download the project with the following command after installing git on your system.
The embedded system (servo and flex sensor glove code) currently depends on Python and pyserial (for an example script), Arduino for the actual code, Doxygen and texlive (if you wish to remake the documentation), Make (if you wish to build the project), and ROS/LibSerial for the simulation.
To quickly upload to the right hand without using make, do the following. Copy the arduino/sketch/servo folder to your Arduino sketchbook folder or any new folder. Copy servo/settings/servo_rhand.h to servo/settings.h in the sketch directory. Open the Arduino software. Select your board and the port it is connected to. Open (File>Open) servo.ino, and hit upload. Other Arduino files on the bot can be built in a similar way, or the make system command can be used. See Installation for using make.
To transmit commands to the board, run this from the command line.
You can now run commands defined in servo_demo.
See servo_demo.connect to connect to the board.
To demo some movements, run this.
Note that some movements require input before continuing (press enter).
See servo_demo.cmd for sending any movement commands. Send strings of bytes as defined in Arduiono and Examples.
The example script can also be used to calibrate the motors. Read the servo_demo documentation for more.
To run the 3D simulation of the project, please refer to Simulation.
You can build this documentation with the command
from the root directory. To upload the documentation, run
and enter a commit message when prompted.
To upload the right hand servo code to the connected Arduino, run
Assuming the board is the arduino nano. For the arduino uno, BOARD would be uno and PORT would be /dev/ttyACM0. If multiple boards are connected, or if a board connects and disconnects quickly, the port number may increment. For example, /dev/ttyUSB1. If you wish to modify Makefile, please refer to the make manual.
This also requires that the latest version of Arduino is installed. Some systems don't have a package for the latest version, such as Ubuntu. The previous version of Arduino does not have command line capabilities and cannot be automated. Fortunately, the build system creates a valid arduino directory structure that we can open in the graphical Arduino IDE. In this case, you can run
And Arduino will open. Open a project and navigate to rig-inmoov/build/servo and open the servo.ino file inside.
The Arduino IDE abstracts many tools for working with Arduino hardware. We choose to use it because of its ease of use and cross system compatibility. However, the Arduino IDE only recently started coming with control tools for the command line (a process which make uses to compile and upload the project). Some versions of Linux do not come with the newest version of Arduino. Replicating the process performed by the Arduino IDE requires complex tools not appropriate for this project.
What follows is a description of what make performs to build and upload the embedded code (as defined in Makefile) for those not able to use the newest version of Arduino.
To share code among certain boards, general code is kept in subdirectories under rig-inmoov/arduino/sketch. Inside each subdirectory is an .ino file of the same name, which is the source for the sketch. There is also a settings folder in which various headers are kept. These headers are to be moved to settings.h inside the sketch folder. For example, code to be shared among servos is kept in arduino/sketch/servo/servo.ino, the configuration for the right hand is kept in arduino/sketch/servo/settings/servo_rhand.h, and you would move it to arduino/sketch/servo/settings.h (or another folder which you moved servo.ino into) to use it. You would then open servo.ino in the Arduino IDE.
Some sketches require shared code that use Arduino libraries, which means that they need to be contained in .ino files. Arduino includes any .ino files inside a sketch subdirectory. We keep such files in arduino/lib.
The reason that we do not use .ino files for settings files is that .ino files do not have a guaranteed order of inclusion.
The Arduinos controlling the various parts of the bot communicate over their serial ports. All information is sent and recieved using 8 bit unsigned raw integers instead of text. This allows extremely fast and simple code, but limits programs to 255 signals, identifiers, and values.
The Arduino servo boards only have one function; to pass commands to their servos.
All boards accept some pre-defined signals that break the default flow. It can receive these signals at any time and will terminate its current servo command. In addition, the board may print some signals to output. Both kinds of signals, incoming and outgoing, are assigned starting from 255 and going down. In the arduino code, incoming signals are denoted by *_SIGNAL, and the outgoing signals are denoted by *_RESPONSE. We will use this convention.
This signal exists to cancel all pending input and syncronize the host and master. If a host connects to an Arduino and does not know its current state, it can send this signal and know that the board is waiting on a servo ID.
This response indicates that the board has no bytes left to read and is ready for input. A host does not need to wait for this response, but it may want to if it is experiencing difficulties or the board may have crashed.
These responses mark the beginning and end of a reply to some signal.
This signal makes the board return various information about itself and its servos. As of writing, it returns START_RESPONSE, an ID, its number of servos, the IDs of each servo followed by the value last sent to that servo, and END_RESPONSE. If a serial connection has access to other boards and is able to send them commands, it may send more servo IDs and servo positions before END_RESPONSE. Board IDs start from 181 and go up. It is recommended that if we build more modular bots such as this one in the future using the same protocol, they recieve unique board identifiers. The response is likely to change in the near future as we add sensors and other types of devices. Be sure to regularly check this document.
This would send the servo with ID 0 a value of 180, servo 1 135, and servo 2 90. The board would then respond with WAIT_RESPONSE.
This would send the servo with ID 0 a value of 180, servo 1 135, begin to read a command for servo 22 but cancel, then send 45 to servo 4.
On a board with ID BOARD_ID and 5 servos identified as 0-4, this would return the response
If this stream of bytes were sent instantly, it would essentially move servo 0 directly to 180 degrees (if it was a positional servo) because of the speed of the commands. However, if we inserted a slight delay, we could slowly move the servo from its starting position to its ending position.
This would move servo 0 and servo 1 from their start to end positions. If we were to send these bytes immediately, they would essentially both move instantaneously to 180 degrees (if they were positional servos). However, if we were to insert a delay, they would both appear to move together slowly to their end location despite the delay between commands. Putting this functionality on the Arduino boards themselves would cause the boards to lock and use up resources, but formulating commands like this allows computation to occur on other systems.
Right hand servo board | 181 |
Right hand flex sensor board | 182 |
Right hand wrist | 0 |
Right hand thumb | 1 |
Right hand index finger | 2 |
Right hand middle finger | 3 |
Right hand ring finger | 4 |
Right hand pinky finger | 5 |
CANCEL_SIGNAL | 255 |
WAIT_RESPONSE | 254 |
DUMP_SIGNAL | 253 |
START_RESPONSE | 252 |
END_RESPONSE | 251 |