Teensy 3.6 UAS Flight Software, RAPTRS

[brtaylor]

Hi all,

I just wanted to start a thread for rolling commentary and feedback as we work on developing v2.x.x of RAPTRS. RAPTRS is my startup's flight software focused on data quality, scalability, low-latency, and determinism. It's designed to run on a network of Flight Management Units (FMU) and sensor and actuator nodes (Node). This network allows the flight system to scale depending on the aircraft and research needs for sensing and actuation. The FMU and Nodes are Teensy 3.6's and a BeagleBone Black is available for running research and higher level software.

The repository for RAPTRS is located here:
https://github.com/bolderflight/RAPTRS

I also have a RAPTRS landing page and will be posting some technical articles and writing users and developers manuals.

I welcome anyone to contribute code and ideas to the project. Also feel free to ask any questions that you might have.

Best,
Brian

[brtaylor]

Currently, the repo has a lot of utility functions: sensor drivers, polynomial fitting and evaluation functions, checksum functions, and statistics functions. These are located in embedded/common since they are intended to be used for both the FMU and Node software.

I'm working on adding message definitions and conversion functions. I'm planning on having unique messages for configuring each sensor and actuator (i.e. an MPU-9250 specific configuration message) with generic data messages (i.e. an IMU data message that all IMU's will use). In v1.x.x of the software, I feel like we get really good quality data because we're careful about setting up our sensors. We would lose that capability moving to generic configuration messages. On the other hand, we wouldn't lose capability with generic data messages and gain the ability for sensor processing and control software to work on data of a given type, regardless of what sensor generated it.

[brtaylor]

I have an initial attempt at sensor config messages up on github:
https://github.com/bolderflight/RAPT...mon/messages.h

Any feedback is appreciated!

[brtaylor]

Added comments clarifying the messages and also took an initial hack at data messages:
https://github.com/bolderflight/RAPT...mon/messages.h

[mjs513]

Hi Brian

Took a look at the messages and your project page. Nice. Just a couple of questions for understanding.

When you say nodes you are referring to each sensor input that is connected to a single Raven Sensor and Actuator Node, I think. Guess with the stuff I have been testing (playing with) using UAVcan you really don't need nodes assigned to each sensor. The node ide is basically the Raven Sensor and Actuator Node. All the data from that node is transmitted using standard or even custom messages similar to what you have using a publish(broadcast) command. A node is basically a sensor or group of sensors attached to a single mcu. So the sensor mcu is the node.

You may want to take a look at this site for some ideas: http://www.olliw.eu/2017/uavcan-for-hobbyists/

You may want to look at how they do it UAVcan messages and message header. Since the header contains a bunch of other data like time sent and NodeID (MCU ID). A custom message is also fairy straight forward that even I figured out how to use. Don't think you can use it directly since you have the sensor board connected directly to your FMU bus.

EDIT: Been mulling around that if I ever want to build a UAV I would use something like this for the CAN/3.2 piece of the puzzle: https://oshpark.com/shared_projects/MemVgGXH

[brtaylor]

Hi Brian

Took a look at the messages and your project page. Nice. Just a couple of questions for understanding.

When you say nodes you are referring to each sensor input that is connected to a single Raven Sensor and Actuator Node, I think. Guess with the stuff I have been testing (playing with) using UAVcan you really don't need nodes assigned to each sensor. The node ide is basically the Raven Sensor and Actuator Node. All the data from that node is transmitted using standard or even custom messages similar to what you have using a publish(broadcast) command. A node is basically a sensor or group of sensors attached to a single mcu. So the sensor mcu is the node.

You may want to take a look at this site for some ideas: http://www.olliw.eu/2017/uavcan-for-hobbyists/

You may want to look at how they do it UAVcan messages and message header. Since the header contains a bunch of other data like time sent and NodeID (MCU ID). A custom message is also fairy straight forward that even I figured out how to use. Don't think you can use it directly since you have the sensor board connected directly to your FMU bus.




Mike

Hi Mike, thanks! When I say "Nodes", I'm referring to the Raven Sensor and Actuator Node, not individual sensors. Unimaginatively, we refer to the bus connecting the Flight Management Unit and Raven Sensor and Actuator Nodes as the BFS Bus (Bolder Flight Systems Bus). It's dedicated for that network. The BFS Bus is a 6 wire bus consisting of: ground, 5V power (clean, up to 2A total available), I2C signals, and two digital lines. One digital line is used for synchronizing data collection (rising edge) and servo commands (falling edge) across the network. The second digital line is available, but unused so far. An "unlimited" number of Raven Nodes can be connected to the FMU to expand the sensing and actuation as needed. We overclock the I2C for the BFS Bus.

Separate buses are available for the sensors connected to the FMU and Raven Nodes. The FMU has one I2C, two UARTs, one SPI, SBUS TX/RX, two GPIO, and eight PWM available. The Raven Node has two I2C, two UARTS, SBUS TX/RX, eight PWM, eight analog, and four digital available.

I'll take a look at that link! Some of the inspiration to use generic data packets came from reading up on UAV CAN. Our v1.x.x software uses specific data packets for each sensor. We currently use a lightweight message structure; I've been thinking of expanding on it for version 2.x.x to look like:
2 byte header
4 byte hash (identifies the component (i.e. the specific sensor or control law, it's a hash derived from a string name given during configuration)
1 byte message ID
1 byte message length
message payload (the structs defined in messages.h)
2 byte message checksum (fletcher 16 checksum)

[mjs513]

Thanks for the added info Brian.

The message header looks interesting. Getting similar to UAVcan.

You raven sensor board is giving me some ideas. The price for that board a little too much just for me to experiment with .


BTW was looking at the schematic. Looks easy enough to hook up a CAN transceiver to it since the pins ae broken to one of the PWM connectors anyway in case you want to try it

[brtaylor]

Thanks for the added info Brian.

The message header looks interesting. Getting similar to UAVcan.

You raven sensor board is giving me some ideas. The price for that board a little too much just for me to experiment with .


BTW was looking at the schematic. Looks easy enough to hook up a CAN transceiver to it since the pins ae broken to one of the PWM connectors anyway in case you want to try it

Hi Mike, the Raven is typically only used in research labs and businesses, so they are priced accordingly, I'll shoot you a PM and we can talk hobby prices for the Raven.

I actually set aside room and pins to add CAN on a future revision of the FMU and Nodes and I have some MCP2561's sitting on my desk waiting to be breadboarded. Not sure when I'll get around to it though.

[mjs513]

actually set aside room and pins to add CAN on a future revision of the FMU and Nodes and I have some MCP2561's sitting on my desk waiting to be breadboarded. Not sure when I'll get around to it though.

That will be a nice addition to the board in case any one wants to use UAVcan in the future. I have tested the lib on a 3.6 and seems to work no issue. There is only one problem that is flexcan library related.

[brtaylor]

I added unpacked sensor configuration and data structures to be used in within the software:
https://github.com/bolderflight/RAPT.../global_defs.h

They're in global_defs because they'll be used globally whereas the packed structures are only used for transferring the data over the buses. I also added functions to convert between the packed and unpacked structures to (hopefully) make it fool proof in the rest of the code:
https://github.com/bolderflight/RAPT...mon/messages.c

[mjs513]

Hi Brian

Sorry it so long to get back to you on what I have been up to with the Raven board. Was busy working with @tonton81's new CANquitto library (uses his IFCT CAN library). It allows you to send up to max of 8k bytes of data in one message. It automatically breaks it into smaller 8byte packets and then does the reassembly. Took a while Just ask tonton81.

Anyway I have a BME280 and BNO055 attached to the Raven. Each is running in its own thread without a problem. Its sending the CAN packet back to a T3.6 where it reassembles the packets I am sending from each sensor. All is working well with the changes with the CAN transceiver on the Raven. Here is a snapshot of the data from the Raven on the T3.6:

IMU Sensor (roll, pitch, yaw, rotx, roty, rotz): 
-1.31, 0.31, 225.25, 0.13, 0.06, 0.00, 
Millis(): 802463

Press Sensor (temp, press, alt, hum): 
24.16, 1017.15, -32.39, 0.00, 
Millis(): 802465

IMU Sensor (roll, pitch, yaw, rotx, roty, rotz): 
-1.31, 0.31, 225.25, -0.06, 0.06, 0.00, 
Millis(): 802586

Press Sensor (temp, press, alt, hum): 
24.15, 1017.16, -32.52, 0.00, 
Millis(): 802589

One of these days I will load up UAVcan on just as a test. But I am sure that will work as well. If you want me to try anything let me know.

Thanks
Mike

[brtaylor]

Hi Brian

Sorry it so long to get back to you on what I have been up to with the Raven board. Was busy working with @tonton81's new CANquitto library (uses his IFCT CAN library). It allows you to send up to max of 8k bytes of data in one message. It automatically breaks it into smaller 8byte packets and then does the reassembly. Took a while Just ask tonton81.

Anyway I have a BME280 and BNO055 attached to the Raven. Each is running in its own thread without a problem. Its sending the CAN packet back to a T3.6 where it reassembles the packets I am sending from each sensor. All is working well with the changes with the CAN transceiver on the Raven. Here is a snapshot of the data from the Raven on the T3.6:

IMU Sensor (roll, pitch, yaw, rotx, roty, rotz): 
-1.31, 0.31, 225.25, 0.13, 0.06, 0.00, 
Millis(): 802463

Press Sensor (temp, press, alt, hum): 
24.16, 1017.15, -32.39, 0.00, 
Millis(): 802465

IMU Sensor (roll, pitch, yaw, rotx, roty, rotz): 
-1.31, 0.31, 225.25, -0.06, 0.06, 0.00, 
Millis(): 802586

Press Sensor (temp, press, alt, hum): 
24.15, 1017.16, -32.52, 0.00, 
Millis(): 802589

One of these days I will load up UAVcan on just as a test. But I am sure that will work as well. If you want me to try anything let me know.

Thanks
Mike

Hi Mike, great news! Looks like I'll update the hardware to v1.6 for the Raven nodes now that yours is tested working well.

BTW, how do you like the BNO055? Does it have good library support? Good performance and low drift?

[brtaylor]

As a software update for RAPTRS, instead of breaking from the v1.x software, I've merged the v1.x software into the RAPTRS repo and am pulling it through updates to v2.x. It's a bit messier and was a hassle to get the build system updated, but this way our bug fixes found against the v1.x software currently flying will migrate into the v2.x software. Plus we'll be pulling in these changes more often, which should mean they'll get incrementally flight tested as they're ready instead of waiting for the whole release. We're using GitHub's project pages to document our progress, but I'll continue here with short updates when we reach major milestones. Currently, working on migrating messaging to the new system.

[mjs513]

BTW, how do you like the BNO055? Does it have good library support? Good performance and low drift?

I rather like the it for a lot of my robotics projects. I get mine from Adafruit and it has great library support. Been using it for years. Seems to be decent drift - to be honest though never really tested. Guess now that you ask I will have to

Ran out of cables so I just order a few more 4 pin and some six pin cables. Want to test a GPS as well but I am sure it will work.

EDIT: Good luck with RAPTRS.

[zchklq]

Hi Brian
I want to use calibate surf,but I donot know how to use it.
I saw the code that must be have inclinometer,but inclinometer's data and flight control system how to communication？do you have calbrate diagram，let me to understand it。

[zchklq]

As a software update for RAPTRS, instead of breaking from the v1.x software, I've merged the v1.x software into the RAPTRS repo and am pulling it through updates to v2.x. It's a bit messier and was a hassle to get the build system updated, but this way our bug fixes found against the v1.x software currently flying will migrate into the v2.x software. Plus we'll be pulling in these changes more often, which should mean they'll get incrementally flight tested as they're ready instead of waiting for the whole release. We're using GitHub's project pages to document our progress, but I'll continue here with short updates when we reach major milestones. Currently, working on migrating messaging to the new system.

Hi Brian
I want to use calibate surf,but I donot know how to use it.
I saw the code that must be have inclinometer,but inclinometer's data and flight control system how to communication？do you have calbrate diagram，let me to understand it。

[brtaylor]

One of the things that I did with UMN is migrate some of the RAPTRS v2 changes into v1. So, what you see online at https://github.com/bolderflight/RAPTRS is actually v1 with a bunch of improvements. I need to find a home for v2, which is at an alpha state right now and rapidly moving toward a beta.

All of this is to say that calibrate-surf will not be moving to v2. It's a UMN specific function where the flight computer talks with an inclinometer to estimate the calibration coefficients between surface position commands to PWM or SBUS commands.

[Camel]

Hi,

Cool project. I used a Teensy for a flight controller a few years ago, it's a solid unit.

I had a look through your githut & saw commits by Curtis L. Olsen. I guess you are using FlightGear for SIL/HIL testing?

I'm trying to get my head around your code. Are you running PID loops? Is there a kalman filter?

What GCS software are you using?

[brtaylor]

Ha, Curt works at the UAS Lab. We're actually using JSBSim at the moment - in the past we've used an in house Simulink based simulation and we may move back to an in house sim at some point in the future.

Yes, we use a 15 state EKF INS and PID loops. In the v1 software, the FMU (Teensy 3.6) only has a manual control law for reversionary modes and the SOC (BeagleBone Black) runs the EKF and PID Loops. In v2, all baseline software including the EKF and PID Loops are moving to the FMU with the SOC only hosting research software and an application interface to add functionality onto the core flight code.

[Camel]

How have you been finding the beagle bone with it's non-guaranteed responsiveness? I toyed with a raspberry pi for flight stabilization and found it missed intervals by up to 600ms at times. Probably OK during cruise but not ideal during critical phases of flight (like bungee launching).
Is that why you are moving the EKF and loops to the FMU?

You didn't tell me about your GCS Are you using an existing GCS or rolling your own?

[brtaylor]

Our timing is good and we haven't had issues missing frames. I'm moving baseline components to the FMU because:
1. If a research software component completely locks up the processor, we still have auto control laws to bring the aircraft back to a landing rather than having to revert all the way back to a manual mode. At some point, I'd like the FMU to be able to completely fly the UAS autonomously and have automated switches monitoring safety of flight parameters (attitude angles, speeds, etc) to automatically revert from research to baseline when needed and fly the UAS back for a landing. Skilled pilots are hard to find and sometimes the research software goes bad fast enough that the aircraft ends up in a bad attitude before we are able to visually detect it and revert to manual mode.
2. I'd like businesses to be able to use a purpose built FMU for commercial products. This would mean using our flight system for fast prototyping on the SOC before bundling everything into an MK66FX1M0 based flight control system for their commercial product. This would lower their BOM cost and reduce complexity.

We're using two GCS's at the moment, neither are perfect. We're using an old GCS from the UMN UAS Lab (https://conservancy.umn.edu/handle/11299/163643) and a GCS that Curt developed (https://github.com/AuraUAS/aura-gcs). They're both stop-gaps until we develop a new GCS next year along with a GUI configurator.

[Camel]

Nice.
I'm developing a GCS at work at the moment. Not sure what I could publicly say about it, other than it's designed by UAS operators for UAS operators (as opposed to autopilot developers who tend to make a GCS that is better suited for their autopilot development needs rather than for conducting ops). It has some similarities to aura-gcs by the looks. The GCS system consists of a server, PC and mobile apps. One key feature is that it allows multiple operators (including virtual operators) to connect to the aircraft and there are handover procedures so it's always clear who has command. Human operators would connect via a GUI, virtual operators need to implement some sort of interface & we've developed one that will allow certain military systems (like insane freaky deaky AI based planners) to fly our aircraft via this GCS. I'm sure we'll be looking to integrate with other autopilot systems soon, so if you're interested PM me.

[zchklq]

thank you！Brian
you mean we must be have an inclinometer，and must be conect to flight control system。Do you have a picture about your calibrate-surf or give me some instruction document.

[zchklq]

i want to buy flight control system,but i don not know how to buy it?

[brtaylor]

i want to buy flight control system,but i don not know how to buy it?

Send us an email at info@bolderflight.com!