Please read this manual carefully before starting to work with the high level processor (HLP) of the AscTec AutoPilot.
The AscTec SDK 3.0 is a toolkit to get your own programming algorithms on the onboard microprocessor of your AscTec UAV. You can write your C-code in the given structure of the SDK and flash it on the HLP via a JTAG or serial connection.
The basic concept of the AscTec AutoPilot is to have two processors: The low level processor (LLP) and the high level processor (HLP). While the LLP handles all hardware communication, a proven flight controller and the data fusion, the HLP is free for custom code. And as a safety backup you can always switch back to the LLP in case of an emergency situation.
After installing the AscTec SDK, you can open the project AscTec_SDK_v3.0 in Eclipse. Please make sure to close all other AscTec SDK projects, before working with the AscTec SDK.
Hint: if you want to run different SDK projects, just choose a different workspace for each SDK project.
The easiest way to get your code on the high level processor is to use the JTAG-adapter. For that we offer a JTAG adapter, which can be plugged to your PC via mini-USB cable.
Flashing the high level processor
The easiest way to get your code on the high level processor is to use the JTAG-adapter. After connecting your JTAG to your PC and the device,
it needs three steps to get your code on the high level processor.
- Build your code (Build Project)
- Connect your JTAG adapter and start the JTAG connection (Run OpenOCD Asctec-JTAG)
- Flash the processor (Run Asctec JTAG Debug)
If you are using the AscTec SDK without the AscTec Simulink Toolkit choose the build configuration AscTec SDK. If you are using the Simulink Toolkit choose the build configuration AscTec Simulink Toolkit.
In the menu Run -> External Tools -> External Tools Configuration... you will find OpenOCD Asctec-JTAG.
It is a known Eclipse bug, that this never works on the first try, so please run OpenOCD Asctec-JTAG twice after starting Eclipse for the first time.
If the JTAG connection was activated correctly, the console will show only the following line:
Info: openocd.c:92 main(): Open On-Chip Debugger (2007-08-10 22:30 CEST)
Hint: Do not launch more than ONE JTAG-connection at the same time! So after something went wrong, first close all open connections and try again.
In the menu Run -> Debug Configurations... you will find Asctec JTAG Debug. If the code was successfully flashed on the processor, the program will switch to the Debug window.
If you want to flash the high level processor using a serial interface (AscTec USB adapter) and bootloader software like Flash Magic ( http://www.flashmagictool.com/ ) you can find the main.hex in your workspace folder.
A description how this is done can be found here.
Please also have a look at the examples in sdk.c, which show you the options how to send commands to the vehicle.
Testing your code
After uploading your code to the UAV, please be careful testing it. The ARM7 offers online debugging. That can be used to test the motor commands, which are sent to the LLP, without turning on the motors. As long as the serial interface is deactivated (channel 5 in OFF position), the commands from the HLP are ignored by the LLP. If you use our standard RC Futaba FF7, the black marked switch on the right hand side needs to be pulled towards the pilot to enable the serial interface.
The ARM7 supports ONE hardware breakpoint. You can monitor the CPU-load by looking at RO_ALL_Data.HL_cpu_load. As long as this value is below 1 your code in SDK_mainloop() is executed at 1 kHz. For example: 0.021 means the HL code uses 21% of the available capacity.
While testing your code with running motors make sure a safety pilot is always able to stop the serial interface and control the UAV manually to avoid any unexpected behavior of the UAV. Before you test your algorithms in the air, it 's good to test them while holding the UAV on the ground. If you do that, make sure to wear protective gloves to avoid any accidentally harm by the UAV.
While testing your code in the air, make sure you have enough space to avoid collisions with surrounding objects. We recommend to launch the UAV manually and first give the control to the HL-code (channel 5 in ON position), when you are in a safe airspace. The safety pilot has always the possibility to stop the control of the vehicle by the HL-code and can control the UAV manually. The more room the UAV has, the easier it is for the safety pilot to take over.
To test if the flashing of the HLP worked and how to enable the serial interface, you can run the example turn motors on and off every 2 seconds in the SDK_mainloop.
If your project needs communication via HL serial 0 port, the easiest way is to use the AscTec Communication Interface or you can directly program the serial port. An example is given in main.c near line 284, which started with the commented string:
To use this SDK in combination with the AscTec Simulink Toolkit you need to change the Build Configuration. Click on Project - Build Configuration - Set Active - AscTec Simulink Toolkit in the menu bar. Please carefully follow the complete instructions of the Simulink Toolkit manual before flashing your HLP.
You have to go through all steps until you can receive any data with the UART_Communication model.
If you want to combine the automatically generated C-code from the Simulink Toolkit with additional C-code, please put the additional C-code into SDK_matlabMainLoop().
Now you can set the Emergency Modes directly from the HLP. For more information about the Emergency Modes, please have a look at Emergency Mode. Please set an emergency mode according to the flight path of your flight mission with SDK_SetEmergencyMode(). If non was set, Direct Landing is activated.
The coordinate system of accelerations, angular rates and angles as well as control inputs has been changed to comply with air norm DIN 9300. The ZYX convention is used to describe the vehicles pose in Roll, Pitch and Yaw (RPY).
Consequently, please rotate your control in- and outputs to comply with this coordinate frame.
Additional control modes have been added. With older SDK versions, direct motor control commands were either mapped to each of the motors individually, or mapped to all motors as pitch/roll/yaw/thrust commands without any controller active. Since SDK version 2.0 the user can select by an additional flight mode flag, which of the modes above they require. In addition, a possibility to send GPS waypoints to the LL processor directly from the HLP without the need of a serial cable connection between the processors was added.
Please refer to the code samples in sdk.c to see, how to work with the different control levels!
The following control modes are available:
Direct individual motor control: individual commands for motors 0..3 (AscTec Hummingbird, AscTec Pelican) or 0..5 (AscTec FireFly)
Direct motor control using standard output mapping: commands are interpreted as pitch, roll, yaw and thrust inputs for all motors; no attitude controller active.
Attitude and thrust control: commands are interpreted as remote control stick inputs and therefore used as inputs for standard attitude controller: desired angle pitch, desired angle roll, desired yaw rate and thrust.
GPS waypoint navigation. When in GPS mode the vehicle will fly to the desired waypoints.
For a better usability, the data structure RO_ALL_Data was added in sdk.h to read all available data from. The data in the struct RO_ALL_DATA is automatically filled with sensor data and data fusion outputs from the LLP at a
rate of 1 kHz (angles and angular velocities) or 333Hz (accelerations, magnetic field measurements, height and climb/sink rate).
The data in the structure is updated before your SDK_mainloop() function is triggered (at 1 kHz). You should not change any of the code in LL_HL_comm.c/.h in order to keep the communication operational.
The GPS module is directly connected to the HLP, hence the GPS data is directly available on the HLP with a frequency of approx. 5 times per second.
There are six types of data struct defined for sending or getting variables:
All definitions of these structs, you can find in sdk.h, where all variables are documented. For a quick overview of all available variables please have a look in the ACI Wiki.