|
CORC Project
CANOpen Robot Controller Software Documentation
|
|
CORC Project
CANOpen Robot Controller Software Documentation
|
CORC is a free and open source robotic development software stack, written in C++.
The project has been under development at the University of Melbourne in partnership with Fourier Intelligence. The project was developed to run on an X2 Exoskeleton powered by a Beaglebone Black, however, the software is designed to be extensible to any embedded Linux and CANopen enabled Robotic platform.
Note (12/5/2020): At this stage, this software has not been tested on physical hardware due to lab access limitations due to COVID-19.
The code is structured into 3 levels:
Whilst the code can be modified at any level, this structure is designed to provide a degree of modularity. The CANopen Communications level should not need to be changed. The Robot level should only change with respect if the robot to be controlled changes. This is loosely enforced by the source code folder structure - the files which should not need modification are placed in the src/libs folder, and the remainder are placed in the src/apps folder. Due to this, thus there are base classes in the libs folder which are derived in the apps folder.
The following instructions detail the building and testing of a simple test state machine for the X2 Exoskeleton (ExoTestMachine.cpp). This state machine simply simulates an exoskeleton which can move between sitting and standing postures, running in position control, triggered by keyboard events.
These instructions assume that you have a suitable test platform (i.e. a Target), and a workbench environment (i.e. a Host).
Specifically, the target that these instructions have been written for (and tested on) is a BeagleBone Black running Debian Stretch 9.5 Firmware. Theoretically, this can be built on other distributions and Linux platforms as well, but they have not yet been tested.
These instructions have been tested on a number of different host workbench build environments, but instructions on setting these up can be found here. We recommend trying option A if possible.
On the host, clone the project from git repository:
This repository includes all the sources files required for this example.
On the host, build the executable:
Note: there are also some additional build rules to build additional tests, which are still to be completed
The makefile is configured to compile an executable EXO_ROBOT_2020 using the arm-linux-gnueabihf-g++ compiler. Note that this requires an appropriately configured workbench environment (see "Before you start").
The recommended method of transferring files to the BeagleBone is FTP.
Using an FTP Client on the Host (if you do not have one - or a preferred client, FileZilla is reasonable), connect to the target (the BeagleBone). By default, when the BeagleBone is connected to a computer using USB, it is configured to:
On the host, using the FTP client, transfer the build executable in build/EXO_ROBOT_2020, along with the contents of the initRobot folder, to the Beaglebone.
Note: The
initRobotfolder contains scripts for setting up the CAN interfaces that CORC uses for communication
To run the ExoTestMachine, open your preferred terminal window and SSH into the the BeagleBone (tutorial). This will provide terminal access to the target, on the host. This can be done using the same username and password, e.g:
At this point, you will need to change the permissions of the executables to executable. You can do this using the the chmod +x command on the target. e.g.
This must be repeated for the .sh scripts as well.
Initialize the Virtual CAN device to set up, bind to and run candump (candump manpage) on the VCAN interface.
This initialises a virtual CAN interface, and prints the contents of the bus to the terminal window.
Note: This can be changed to use a non-virtual CAN interface, but this requires some minor changes to the code before compilation, and the use of the
X2_startCAN.shscript instead.
SSH into the BeagleBone in a second terminal window to launch the application:
Note: Superuser privileges (
sudo) are required due to the use of real time threads in the application.
The first terminal one should display CAN messages on VCAN from the EXO_APP_2020 application output. On startup init PDO messaging should be sent and appear as follows:
Follow terminal instructions using your keyboard in the second terminal instance to run through test stateMachine.
The first terminal instance (running candump) should display PDO messages corresponding to changes to the commanded motor positions as follows:
Note these TPDO messages are configured in the Object Dictionary, with configuration SDOs to be sent during the Robot Initialisation stage. Details for the default set of PDOs can be found in the drive.h source files.
As the simulated device is in position control, these messages should print whenever the system moves from sit to stand or stand to sit, with no messages transmitted whilst the device is stationary. CORC has provisions for velocity and torque control, but these are not included in this example for ease of simulation.
Feel free to contact fong.j[at]unimelb.edu.au with questions or suggestions for continuing development.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. This program is distributed in the hope that it will be us
1.8.11
