quest-fw / quest-fw Goto Github PK

This project forked from nasa/fprime

License: Apache License 2.0

Shell 0.54% HTML 12.83% CSS 0.13% JavaScript 0.86% Makefile 1.91% TeX 1.59% Roff 1.82% XSLT 0.01% Java 0.59% Python 9.80% C++ 58.70% C 4.07% Perl 0.12% CMake 0.85% EmberScript 0.02% Assembly 0.18% Batchfile 0.02% Rich Text Format 5.96% Awk 0.01% Dockerfile 0.01%

quest-fw's Introduction

QUEST

One-time setup:

You'll need the submodules and dependencies, so clone like so:

git clone --recurse-submodules REPO_ADDRESS

Or, after cloning, run:

git submodule update --init --recursive

To get the F’ dependencies on Ubuntu:

sudo apt-get install pkg-config g++ python-pip python-lxml python-tk python-dev

To get F’ dependencies on Mac:

brew install tcl-tk libxml2

On all platforms (modify the pip command if you don’t want a global install)

sudo -H pip install -r Gse/bin/required.txt

Using with ROS (needed for `SIMREF` and `SDREF`)

Dependencies:

ros-VERSION-trac-ik
ros-VERSION-orocos-kdl

For Ubuntu 16.04 with Kinetic, or Ubuntu 18.04 with Melodic, there are pre-written mod.mk files here: https://github.com/genemerewether/quest-fw/blob/quest-master/ROS/fprime_modmk_linux_kinetic https://github.com/genemerewether/quest-fw/blob/quest-master/ROS/fprime_modmk_linux_melodic

Then, go to the ROS/fprime_ws folder, and build the workspace with your ROS environment sourced (tested with catkin):

catkin init
ROS_LANG_DISABLE=genfprime catkin build

(omit the ROS_LANG_DISABLE if you want to generate F' ports / serializables from a new ROS package with messages and/or services)

If you autogenerated the mod.mk file, then double-check that genfprime didn't overwrite any files in the ROS/Gen folder using git status.

Using without ROS

From the top directory of the repo, run:

touch ROS/fprime_ws/src/fprime/mod.mk

Installing command dictionaries

For a particular deployment (e.g. SDREF, HEXREF), go to that folder and run make dict_install

Then, run touch Gse/generated/DEPLOYMENT/serializable/ROS/__init__.py See #3

`SDREF`: High-level processor deployment

Acts as a shim to transport data to and from low-level processor
Interfaces with ROS and F' ground station
On Snapdragon Flight, loads HEXREF onto DSP and interfaces with that code
On any Linux environment, interfaces to low-level processor over two UARTS (one data and one debug)

To set up a new installation, download Flight_3.1.3_qrlSDK.tgz from Intrinsyc and qualcomm_hexagon_sdk_lnx_3_0_eval.bin from Qualcomm, and place in cross_toolchain/downloads.

Run ./bootstrap.bash from the top level of the repository. This will set up the Hexagon toolchain using install.sh from cross_toolchain, install all required dependencies, create a Linaro Indigo ARM sysroot and install ROS in it using proot for later cross-compilation include and link steps.

`R5REF`: TI TMS570 deployment

Tested on Linux and Mac with TI Code Composer Studio version 8.1.0, with ARM compiler version 18.1.2

`SIMREF`: Simulation deployment (works with RotorS from ETH)

To build the simulation example, go to the SIMREF folder, and run the following:

make gen_make
make

Then, you can run the executable like so (after starting ROS master):

ROS_NAMESPACE=firefly ./linux-linux-x86-debug-gnu-bin/SIMREF

When you start the RotorS (https://github.com/ethz-asl/rotors_simulator) firefly example, SIMREF will use the /clock message to carry out control cycles. This parallels what happens on hardware targets, where the IMU data-ready interrupt triggers the estimation and control loops.

Works out of the box with https://github.com/genemerewether/ethzasl_sensor_fusion for testing high-level filter updates, but can be easily adapted to simulated sensors in Gazebo. Just run additional ROS nodes as necessary, and remap the pose or position sensor topics of the sensor fusion packages. Or, publish the mav_msgs/ImuStateUpdate message (see the mav_msgs submodule of this repo) from an appropriate filter.

Snapdragon build:

To build for the 801, clean the entire repo or start with a fresh copy and make sure the correct environment variable is present:

echo "export TARGET_8074=1" >> ~/.bashrc
. ~/.bashrc

Supported Hardware:

ATI Netbox force-torque sensor
MPU9250
Garmin LidarLite v3
SimonK ESC firmware over I2C, two different protocols: https://github.com/genemerewether/tgy

F Prime: A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework

F Prime (FÊ¹) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications. Originally developed at the Jet Propulsion Laboratory, F Prime has been successfully deployed on several space applications. It is tailored, but not limited, to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments.

F Prime comprises several elements:

An architecture that decomposes flight software into discrete components with well-defined interfaces
A C++ framework that provides core capabilities such as message queues and threads
Modeling tools for specifying components and connections and automatically generating code
A growing collection of ready-to-use components
Testing tools for testing flight software at the unit and integration levels.

F Prime has the following key features:

Reusability

F Primeâ€™s component-based architecture enables a high degree of modularity and software reuse.

Rapid Deployment

F Prime provides a complete development ecosystem, including modeling tools, testing tools, and a ground data system. Developers use the modeling tools to write high-level specifications, automatically generate implementations in C++, and fill in the implementations with domain-specific code. The framework and the code generators provide all the boilerplate code required in an F Prime deployment, including code for thread management, code for communication between components, and code for handling commands, telemetry, and parameters. The testing tools and the ground data system simplify software testing, both on workstations and on flight hardware in the lab.

Portability

F Prime runs on a wide range of processors, from microcontrollers to multicore computers, and on several operating systems. Porting F Prime to new operating systems is straightforward.

High Performance

F Prime utilizes a point-to-point architecture. The architecture minimizes the use of computational resources and is well suited for smaller processors.

Adaptability

F Prime is tailored to the level of complexity required for small missions. This makes it accessible and easy to use, while still supporting a wide variety of missions.

Analyzability

The typed port connections provide strong compile-time guarantees of correctness.

F Prime Resources

The Reference application is shipped as part of F'. Documentation for this reference application can be found here.

The full F' User's guide can be found here. In addition, the F' architectural overview can be found here.

Continuous Integration

The continous integration system performs builds and unit-test check on any pull-requests created on the F´ core. Thus ensuring that F´ core is stable and well maintained.

F Prime Release Notes

Release 1.0:

This is the initial release of the software to open source. See the license file for terms of use.

Release 1.01

Updated contributor list. No code changes.

Release 1.1

Created a Raspberry Pi demo. Read about it here.
Added a tutorial here.
Updated Svc/BufferManager with bug fix
Fixed a bunch of shell permissions

Release 1.2

Better MagicDraw Plugin
Prototype CMake build system. See: CMake Readme
Mars Helicopter Project fixes migrated in
Python 3 support added
Gse refactored and renamed to Gds
Wx frontend to Gds
UdpSender and UdpReceiver components added
Purged inaccurate ITAR and Copyright notices
Misc. bug fixes

quest-fw's People

Contributors

Stargazers

Watchers

Forkers

sunggoojung kyle-weng arghyachatterjee

quest-fw's Issues

building C++ ARM with C DSPAL

This is only loosely related to quest-fw.

The F' build system is rather difficult to parse. I can successfully build a C ARM / C DSPAL project using qurt_bundle. I would like to build a C++ ARM / C DSPAL project (like BlspI2CDriver).

Questions:

Is DspRelay/CMakeLists.txt being used? It's the only place where qurt_bundle is being used, but it seems like it is missing many of the *_relay.c drivers.
Where are SRC_DSPAL and SRC_SDFLIGHT used? From a find all, it looks like they are only defined -- I'm guessing there is a script somewhere that uses these to automatically detect new targets?

Check that all params are valid in MVVislam and MVDFS before initialization

Remove makefile pre/post lib list var duplicate functionality

$(LINK_BIN_PRE_LIB_FLAGS) same as $(LIBS_START)

On your paper IROS 2019 paper

Hi,

Thanks for sharing this awesome package. I was wondering if this is the software framework used in the your paper titled "An Autonomous Quadrotor System for Robust High-Speed Flight Through Cluttered Environments Without GPS". If it is (or even if it is not) , what hardware setup and what steps would you recommend to speed-up my learning curve with quest-fw? I am primarily interested in testing position/orientation control loops for high speed flight, and it seems that quest-fw is a nice framework for experimenting with multi copters.

I am interested in using it for my research, primarily since the claimed 1khz feedback control loop and its relevance in high speed flight.

Thank you very much!

HEXREF invokes PassiveTextLogger from multiple threads

Switch to ActiveTextLogger for thread safety

Add param-unset EVRs to GNC components

make thrust in TorqueThrust a float?

quest-fw/mav_comm#1

Add Gse autocoder support for nested serializables

In the meantime, just create an empty file at REPO_TOP_LEVEL/Gse/generated/DEPLOYMENT/serializable/ROS/__init__.py after running make dict_install

parameterize mvvislam and mvdfs

Snapdragon Flight 801 bootstrap fails because of ROS - dpkg interaction

On 801 native, and in qemu with proot, dpkg fails to install some ROS packages due to a known dependency on a newer dpkg version.

The solution is to manually upgrade dpkg using the following deb packages (renamed to .txt to upload). NOTE - you REALLY should not use these files directly for security reasons, but full name and contents are provided here to make sure you get the right version

dpkg_1.17.5ubuntu5.8_armhf.txt
libbz2-dev_1.0.6-5_armhf.txt
libdpkg-dev_1.17.5ubuntu5.8_armhf.txt
liblzma-dev_5.1.1alpha+20120614-2ubuntu2_armhf.txt

Modify MPU9250 driver to use eventcapture from STIM; add eventcapture equivalent for Hexagon

FastRPC clarification - HexRouter vs KraitRouter

It seems that KraitRouterImpl.cpp runs on the Hexagon/aDSP and that HexRouterImpl.cpp runs on the Krait/CPU. Is that correct?

Also, I found your QDN forum question about FastRPC and UART. I am hoping to stream high-rate sensor data (MAVLink messages from ROSflight) from the autopilot on the aDSP to the MAVLink<-->ROS parser (think mavros) on the CPU. Have you had any practical (i.e., bandwidth, latency) limitations with running HEXREF and using FastRPC?

My understanding is that by using rpcmem_* in combination with the standard FastRPC/idl method of calling methods on the DSP allows for zero-copy transfer.

List common gotchas

When using IPC components / queues, make sure /proc/sys/fs/mqueue/msg_max is big enough
When using TaskRoot.cpp, need to run as root
Hexagon DSPAL library size - mmap failed
prepend_instance_name in Topo keeps command names consistent when going from one to many instances of component
if changing commands / EVRs / channels, go to Top and clean, then rebuild
Debugging on Mac with ROS: DYLD_LIBRARY_PATH=/opt/ros/ROS_DISTRO/lib /Applications/Xcode.app/Contents/Developer/usr/bin/lldb PATH_TO_BINARY
if MVVislam or MVDFS are causing crashes, make sure parameters are loaded correctly

SIMREF invokes Gnc other threads

Use QueuedDecoupler like in BLIMPREF

Switch MVCam, HiresCam, LLRouter, LinuxSerialDriver to use new fixed-size-buffer-manager

Create new fixed-size buffer manager that is order-agnostic. Have it use Fw::MemAllocator

ActiveDecoupler should take latest commands

Is this possible using existing thread-safe queue mechanisms?

Check time instead of cycle count in MPU9250 init

Finish LinuxSerialDriver implementation on DSPAL

Need read side. Sched triggered or threaded?

Re-namespace R5/TimeForward to Svc

Add tinyseqgen support for multiple dictionaries

For use with multiple CmdDispatchers - one per topo. Current workaround is to split sequences when they use multiple deployments

for image hosting

Call all output actuators ports of BasicMixer

Will be used once QualcommESC is done

Add NHET I2C driver for TIR5 for motor control interface

Probably easier than setting up DMA with multiple I2C slaves

Create param macros in MVCam, StereoCam, MVVislam, and MVDFS

Improve readability / verification in the parameterUpdated methods in these components

Flight Pro 820 - I2C pins

I am working with the Snapdragon Flight Pro 820 board.

I have been able to successfully compile the DSPRELAY target and the BlspI2CDriver target. When I run them (I just randomly chose I2C 1 and address 0x11), I see the following:

/eng/load # ./i2c_test_ut 
Usage: ./i2c_test_ut <i2c idx> <slave addr> <bytes to read>
/eng/load # ./i2c_test_ut 1 0x11 1
Testing I2C 1 WriteRead to slave 0
WRITE: 0x00 0x00 
READ: 0xA5

From the DSP console, I see:

[08500/02]  54:17.570  Verification skipped, no function specified!!  0495  map_object.c
[08500/02]  54:17.570  uimg not supported  0529  map_object.c
[08500/03]  54:17.585  __cxa_finalize weak ref not found, return _rtld_sym_zero@_rtld_objmain  0295  symbol.c
[08500/03]  54:17.585  __cxa_finalize weak ref not found, return _rtld_sym_zero@_rtld_objmain  0295  symbol.c
[08500/02]  54:17.590  Opening I2C device /dev/iic_ssc-1   0053  i2c_relay.c
[08500/02]  54:17.590  device open entered, device path: /dev/iic_ssc-1  0054  dev_fs.c
[08500/02]  54:17.590  Successfully opened I2C device /dev/iic_ssc-1 fd 268435455   0059  i2c_relay.c
[08500/02]  54:17.596  I2C fd 268435455 freq 400000, slave 0x  0144  i2c_relay.c
[08500/02]  54:17.602  Write 2 bytes, read 1 bytes to I2C  0116  i2c_relay.c
[08500/02]  54:17.603  Batch transfer failed: 0x100000d0  0467  i2c_ssc.c
[08500/02]  54:17.603  I2C 268435455 read/write error 1 vs -1 actual! 0: no error  0124  i2c_relay.c
[08500/02]  54:17.610  Closing I2C device 268435455  0151  i2c_relay.c

So it seems that things are working. However, I am having trouble deciphering the appropriate I2C device / pins.

Based on the Board Pin Out page, it seems like I would want to use J12, which connects to BLSP12_I2C_SDA and BLSP12_I2C_SCL (since this is a BLSP driver).

However, since this is the 820, it actually seems like I would want to use the SSC pins, listed in the schematic as SSC_1 to SSC_4

And then the other issue is how to use the BLSP-SSC MUX?

Common issues when building a deployment

Troubleshooting while building:

Commands to begin build process are:

make gen_make
make

These should be ran in the deployment directory

Error: Unable to find mav_msgs header files, as seen below:

In file included from /home/vagrant/quest-fw/CARREF/Top/Components.hpp:14:0,
                  from /home/vagrant/quest-fw/CARREF/Top/Topology.cpp:1:
/home/vagrant/quest-fw/Gnc/Est/FilterIface/FilterIfaceComponentImpl.hpp:27:37: fatal error: mav_msgs/ImuStateUpdate.h: No such file or directory
 #include "mav_msgs/ImuStateUpdate.h"
                                     ^
compilation terminated.
/home/vagrant/quest-fw/mk/makefiles/bin_targets.mk:27818: recipe for target '/home/vagrant/quest-fw/CARREF/Top/linux-linaro-cross-arm-opt-gnu-bin/Topology.o' failed
make[1]: *** [/home/vagrant/quest-fw/CARREF/Top/linux-linaro-cross-arm-opt-gnu-bin/Topology.o] Error 1
make[1]: Leaving directory '/home/vagrant/quest-fw/CARREF'
Command exited with non-zero status 2
Build Time: 0:02.86
/home/vagrant/quest-fw/mk/makefiles/deployment_makefile.mk:61: recipe for target 'SDFLIGHT_opt' failed
make: *** [SDFLIGHT_opt] Error 2

This error is because the Catkin workspace has not been built, so in order to build go to the Catkin workspace in: quest-fw/ROS/fprime_ws and enter the command catkin build

You should also check that all submodule dependancies were correctly added:
git submodule init then git submodule update

Error: Unable to find ROS

> `In file included from /home/vagrant/quest-fw/CARREF/Top/Components.hpp:14:0,
>                  from /home/vagrant/quest-fw/CARREF/Top/Topology.cpp:1:
> /home/vagrant/quest-fw/Gnc/Est/FilterIface/FilterIfaceComponentImpl.hpp:25:21: fatal error: ros/ros.h: No such file or directory
>  #include "ros/ros.h"
>                      ^
> compilation terminated.

This occurs because there is no mod.mk file in the ROS/fprime_ws/src/fprime directory. If you don't actually need ROS, then you can just touch a file in this directory with the name mod.mk
If you need ROS, follow:
For Ubuntu 16.04 with Kinetic, or Ubuntu 18.04 with Melodic, there are pre-written mod.mk files here: https://github.com/genemerewether/quest-fw/blob/quest-master/ROS/fprime_modmk_linux_kinetic https://github.com/genemerewether/quest-fw/blob/quest-master/ROS/fprime_modmk_linux_melodic

Copy the appropriate file to ROS/fprime_ws/src/fprime/mod.mk. If you have some other system not listed above, then you need to enable generation of the mod.mk file, so remove the CATKIN_IGNORE file from ROS/fprime_ws/src/fprime and ROS/fprime_ws/src/genfprime.
Then, go to the ROS/fprime_ws folder, and build the workspace with your ROS environment sourced (tested with catkin):

catkin init
ROS_LANG_DISABLE=genfprime catkin build