Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: Teensy 3.6 UAS Flight Software, RAPTRS

  1. #1
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370

    Teensy 3.6 UAS Flight Software, RAPTRS

    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

  2. #2
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    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.

  3. #3
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    I have an initial attempt at sensor config messages up on github:
    https://github.com/bolderflight/RAPT...mon/messages.h

    Any feedback is appreciated!

  4. #4
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    Added comments clarifying the messages and also took an initial hack at data messages:
    https://github.com/bolderflight/RAPT...mon/messages.h

  5. #5
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,842
    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

  6. #6
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    Quote Originally Posted by mjs513 View Post
    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)

  7. #7
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,842
    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
    Last edited by mjs513; 08-15-2018 at 03:33 PM.

  8. #8
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    Quote Originally Posted by mjs513 View Post
    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.

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,842
    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.

  10. #10
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    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

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,842
    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:

    Code:
    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

  12. #12
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    Quote Originally Posted by mjs513 View Post
    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:

    Code:
    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?

  13. #13
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    370
    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.

  14. #14
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,842
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •