mirror of
https://github.com/OpenSolo/OpenSolo.git
synced 2025-04-29 22:24:32 +02:00
DOC: Detailed Artoo readme
New detailed Artoo readme, replacing most older versions.
This commit is contained in:
Matt Lawrence
Matt
parent
62225f70b6
commit
ccae7d9bd7
@ -1,65 +1,60 @@
|
||||
WARNING - WORK IN PROGRESS
|
||||
# ARTOO STM32 FIRMWARE #
|
||||
|
||||
```
|
||||
This code is known to be high risk , but also early-adopter friendly.
|
||||
The controller's STM32 is the hardware behind the buttons, sticks, and display. It is a separate piece of hardware from the IMX linux computers. When the solo-builder runs to compile the full copter and controller images, this Artoo STM32 firmware is included. You can aso run the Artoo STM32 builder here separately if you only want to make changes to it. It is fast and simple compared to the entire copter and controller builds.
|
||||
|
||||
We will remove this warning from the repository when it is no longer required.
|
||||
```
|
||||
Some compiled versions of the Artoo STM32 firmware can be found in the [/Firmware/Artoo STM32](/Firmware/Artoo%20STM32) directory.
|
||||
|
||||
***
|
||||
|
||||
# artoo
|
||||
## Building the Artoo STM32 Firmware ##
|
||||
|
||||
firmware for Artoo, the Solo controller
|
||||
To build the Artoo STM32 firmware, you must use the vagrant virtual machine, which will have everything configured by script. We can assure with 100% confidence that trying to run the builder natively on your own linux machine will not work. The vagrant VM is configured to have all required packages, and uses Ubuntu 14.04. Nothing newer will work. Do not attempt to upgrade the Vagrant VM, even if it suggests you do so. Everything will explode.
|
||||
|
||||
### requirements
|
||||
_The vagrant VM used for Artoo is also used for solo-builder. So if you already installed and setup the VM for solo-builder, you can skip right to executing the build._
|
||||
|
||||
* ARM GCC Embedded - toolchain to build firmware. https://launchpad.net/gcc-arm-embedded
|
||||
* tup - build tool. http://gittup.org/tup/ (install via homebrew on OS X)
|
||||
* fuse-dev is required as a prerequisite to set up tup on Ubuntu (install via `apt-get install libfuse-dev`)
|
||||
* pillow - image manipulation in tools/image-codegen.py. http://python-pillow.github.io (install via `pip install pillow` or similar for your env)
|
||||
* note - you'll also need libfreetype installed *before* installing pillow. (`brew install freetype` on OS X)
|
||||
* on at least one Ubuntu 14.04 image, `apt-get install python-pillow` was required, rather than `pip install pillow`
|
||||
* on at least one other Ubuntu 14.04 image, `pip install --upgrade pillow' was required, to force getting pillow 2.7.0 rather than using Ubuntu's 2.3.0
|
||||
* pymavlink - only required when running tools/slip-mavlink.py. http://qgroundcontrol.org/mavlink/pymavlink (install via `pip install pymavlink` or similar for your env)
|
||||
### Initial Vagrant VM Setup ###
|
||||
|
||||
To build with tup, simply invoke it at the root of the project directory:
|
||||
Visit the [Open Solo Vagrant VM readme](/vagrant_readme.md) for first time installation and initialization of the Vagrant VM.
|
||||
|
||||
$ tup
|
||||
### Executing Build ###
|
||||
|
||||
# to build inside vagrant:
|
||||
cd OpenSolo/artoo
|
||||
vagrant up
|
||||
vagrant ssh
|
||||
cd /vagrant
|
||||
tup
|
||||
1. `vagrant up` from the root of root of the OpenSolo repo directory (windows command prompt or ubuntu terminal) starts the VM
|
||||
|
||||
2. `vagrant ssh` connects you to the vagrant VM, where you will do all the building
|
||||
FYI `vagrant@vagrant-ubuntu-trusty-64:~$` is what the prompt will look like once you're connected. You will land in the home directory (`~/`)
|
||||
FYI `/vagrant` within the vagrant VM is symlink to the root of the OpenSolo repo outside the vagrant VM.
|
||||
|
||||
3. `$ cd /vagrant/artoo` changes to the artoo directory
|
||||
|
||||
### dev environment
|
||||
4. `$ ./tup` executes the build.
|
||||
|
||||
I'm primarily using Qt Creator (https://qt-project.org/downloads) for editing, which is tracked in the following project files: artoo.{config, creator, files, includes}
|
||||
#### Completed files ####
|
||||
|
||||
The build produces `artoo.bin` which is deposited in the /artoo directory. You can use it as is, or you can rename it. If you rename the file, it must always begin with `artoo_` and must have a `.bin` extension.
|
||||
|
||||
Any editor you like should be fine, though.
|
||||
***
|
||||
|
||||
I've been using a Black Magic Probe for debug, the easiest way to setup is to copy the sample gdbinit file:
|
||||
## Install Artoo STM32 Firmware On Controller ##
|
||||
|
||||
cp gdbinit.sample .gdbinit
|
||||
_BELOW NEEDS UPDATING_
|
||||
|
||||
Start a debug session:
|
||||
[How to flash the stm32 firmware](/artoo/flash-custom-firmware.md)
|
||||
|
||||
$ arm-none-eabi-gdb artoo.elf
|
||||
$ ... GDB startup ...
|
||||
$ (gdb) load
|
||||
$ (gdb) run
|
||||
[How to customise start/shutdown image](/artoo/customisation/custom-boot-screen.md)
|
||||
|
||||
If you get super hosed, you may need to execute `mon connect_srst enable`, possibly with the reset button held, in order to recover.
|
||||
***
|
||||
|
||||
#### stick calibration
|
||||
## Stick Calibration ##
|
||||
|
||||
--THIS NEEDS TO BE UPDATED--
|
||||
Stick calibration data (along with other params) are stored in the STM32's MCU flash. There exists as GUI to calibrate them as part of the manufacturing process, but if you're interested in calibrating an existing Artoo, use `tools/stick-cal.py` as follows:
|
||||
|
||||
* copy both `tools/slip.py` and `tools/stick-cal.py` to the iMX6 board in your Artoo unit, via `scp` or similar
|
||||
* `ssh` into the iMX6, and run `python stick-cal.py`, move the sticks and camera controls to their extremes, then press `ctrl-C` to complete the calibration
|
||||
|
||||
#### test against simulation
|
||||
***
|
||||
|
||||
## Using with ArduPilot SITL ##
|
||||
|
||||
It is possible to do some basic testing against a simulated vehicle with the SITL environment provided by ardupilot. http://dev.ardupilot.com/wiki/setting-up-sitl-on-linux should get you set up to run it.
|
||||
|
||||
@ -76,13 +71,3 @@ From within the ardupilot project folder, start up SITL and then :
|
||||
$ ... SITL starts up ...
|
||||
|
||||
Now, stick values and mavlink data are sent bidirectionally between artoo<->SITL, and you should be able to fly as normal.
|
||||
|
||||
#### semihosting
|
||||
|
||||
For print/log-based debugging, semihosting support is available (i've only tested this with Black Magic Probe, though hopefully openocd supports it as well).
|
||||
|
||||
In the top level Tupfile, uncomment `SEMIHOSTING := yes` and rebuild. You can now use the `DBG_LOG()` macro in the same way that you'd use `printf()` (it's aliased directly to printf when semihosting is enabled) and you should see the output in your gdb session.
|
||||
|
||||
Code should not be checked in with semihosting enabled, since we don't want to link against those libraries in a production build.
|
||||
|
||||
|
||||
|
||||
@ -1,8 +0,0 @@
|
||||
# Artoo Documentation
|
||||
This folder contains all of the documentation for artoo. It's fairly empty at the moment but expect more stuff shortly.
|
||||
|
||||
#### [How to build the artoo firmware](https://github.com/OpenSolo/documentation/blob/master/artoo/build-artoo-firmware.md)
|
||||
#### [How to flash the artoo firmware](https://github.com/OpenSolo/documentation/blob/master/artoo/flash-custom-firmware.md)
|
||||
#### [How to recover (soft) bricked artoo](https://github.com/OpenSolo/documentation/blob/master/artoo/flash-custom-firmware.md#bricked-artoo)
|
||||
> There *has not* been any reports of a hard bricked unit but it's always possible so be careful!
|
||||
#### [How to customise startup/shutdown screen](https://github.com/OpenSolo/documentation/blob/master/artoo/customisation/custom-boot-screen.md)
|
||||
Binary file not shown.
@ -1,36 +0,0 @@
|
||||
# Building artoo's firmware
|
||||
This guide gets you up to speed with how to compile and flash your own firmware for artoo's stm32 chip. This chip does all the hardware interfacing like processing inputs and drives the LCD screen. This means you can customise graphics, text and even add new features.
|
||||
|
||||
## Requirements
|
||||
* Currently ubuntu 17.04 is the only supported/tested operating system.
|
||||
* At a minimum tup should be installed ([see here](http://gittup.org/tup/))
|
||||
|
||||
## Let's Start
|
||||
First, clone the repository containing the artoo firmware:
|
||||
```
|
||||
git clone https://github.com/OpenSolo/artoo.git
|
||||
```
|
||||
Navigate into the directory:
|
||||
```
|
||||
cd artoo
|
||||
```
|
||||
Start the build process:
|
||||
```
|
||||
sudo tup
|
||||
```
|
||||
A successfull build should end with something like this:
|
||||
```
|
||||
67) [0.015s] arm-none-eabi-objcopy -O binary artoo.elf artoo.bin
|
||||
68) [0.019s] arm-none-eabi-objcopy -O ihex artoo.elf artoo.hex
|
||||
[ ETA=<1s Remaining=0 Active=0 ] 100%
|
||||
[ tup ] [10.613s] Updated.
|
||||
```
|
||||
### Next steps
|
||||
Now see [how to flash a custom firmware to artoo](https://github.com/OpenSolo/documentation/blob/master/artoo/flash-custom-firmware.md).
|
||||
|
||||
## Troubleshooting
|
||||
If tup complains about not finding a tupfile double check the folder you are in. It should be the root directory clone from git.
|
||||
|
||||
If you get other random issues try running tup as root.
|
||||
|
||||
If you get complaints about images being to large or having to many colours, reclone the repo and try again. Read the customisation instructions *carefully*.
|
||||
Loading…
x
Reference in New Issue
Block a user