firmware to use in a Matek F-765-wing.

[OwenN]

I have one of these, and I want to use it in a "dumb" mode.
I don't think I need Betaflight , INAV, or arducopter,
as it is just running my s-bus receiver and providing a 5v power supply, and passing TX channels to an Arduino Zero.
Is there any other basic firmware I can use?
the gyro will be attached to the Arduino Zero.
-I want to try some experimental stuff, and the arduino is easier to use.

 

[LitterBug]

Not much else for it other than those. I personally use Ardupilot. You can set up passthrough for all the channels and "manual" flight mode. Seems like a real waste of hardware.

 

[JasonK]

your ardunio zero runs on 3.3v not 5, which might be an issue for talking to and powering your servos/etc.

you can probably just run the S-Bus directly directly to your Arduino Zero and have it handle the signal. if your passing PWM to your Ardunio, you should just use a PWM reciever and not use the FC board at all.

 

[OwenN]

your ardunio zero runs on 3.3v not 5, which might be an issue for talking to and powering your servos/etc.

you can probably just run the S-Bus directly directly to your Arduino Zero and have it handle the signal. if your passing PWM to your Ardunio, you should just use a PWM reciever and not use the FC board at all.

I would have to get s-bus software for the Zero.- I can see if someone has done this.
I haven't tried to use the solutions library yet.

It would be nice if there were adapter files for Arduino on the Matek hardware, then I could use the superior unit for the job.
I will ask on the Ardupilot Discuss forum.

I don't want a straight passthrough, if I can get a better comms protcol going.
One really good thing about the Matek is the dedicated 5v supply board.- that is mainly what I want.
You cannot just buy those off the shelf.- not producing that many amps, anyway.

 

[JasonK]

yes you can get BECs at what ever current rating you need 'off the shelf'
how many amps are you looking for?
here is a 7 amp one: https://store.flitetest.com/flite-test-7-amp-ubec/
and 15 amps: https://store.flitetest.com/flite-test-15-amp-ubec/
fairly sure those are both more then the matek

 

[clolsonus]

This is probably not what you are looking for, but I've been working on some "simpler" (sorta?) firmware built on top of the ardupilot library/hal. I've only tested on a pixracer, but it should work on any ardupilot supported device. My firmware can do straight pass through to the servo outputs, it can do onboard mixing, it can do onboard gyro stabalization (prior to mixing, so works with vtails and elevons, etc.) It can output the pilot stick inputs via a simple serial protocol to a host (or companion) computer like the arduino. It is a work in progress, the code is currently going through some transition as I restructure some tihngs (in the telem branch), I've been developing and flying on this code since the mid-2000's. Happy to answer questions if anyone is interested. I'm sure if you ask on the ardupilot forum, ardupilot itself can also do all these things if you dig into the details.

Here's my flight controller firmware code:

https://github.com/RiceCreekUAS/rc-fmu-ap/tree/main

The communication protocol is kinda like a mavlink-lite (conceptually) without needing code for 100's of fancy packet types. You can define the packets you want to use with a simple json file, and then a script autogenerates a C++ header and also a python module so you can easily (and efficiently) pack/unpack messages. Coding communication by hand is not difficult, but it is tedious and brittle to changes, so this helps me a ton:

https://github.com/RiceCreekUAS/rc-messages

And one more important bit. The code is structured around sharing all the important data/state within the program using something called a property tree -- which is a 1-to-1 match with json, but provided via a convenient interface in C and python. There is even a way to write hybrid python/C++ apps that share data through a common property tree. I like developing around this design style, but for sure there are many other good ways to do things.

https://github.com/RiceCreekUAS/props2

And to make communication slightly easier, if you pick message field names that match the field names in the property tree (by agreeing with yourself to develop your code this way) then the messaging system can generate code to pack a message directly from the property tree, or unpack a message into the property tree. So the nice thing about that is you can receive and unpack a message in like 4 lines of code, and then data is there for the rest of your app to use.

The property tree is not thread safe (or ISR safe) so keep that in mind if you try it out in your code. I'm a big fan of a single main loop style of coding to keep thing as simple and understandable as I can.

On the subject of sbus vs. arduino. Sbus uses an inverted serial protocol (100,000 baud.) Arduino can support 100k baud, but you'll need a logical inverter on the signal line. You can get these for a couple $ -- at least before all the supply chain disruptions -- and it just plugs inline with RC style connectors. Otherwise if you pick a teensy instead of an arduino, these support inverted serial directly so you can plug your sbus right in.

Here is the arduino sbus library I was flying with for a few years (prior to porting all my stuff over top of ardupilot's library/hal layer and using their rcin library.)

https://github.com/RiceCreekUAS/rc-fmu-arduino/tree/master/src/sensors/sbus

Sorry for such a huge data dump all at once, I know it's a lot, but if any of this looks interesting, please feel free to ask questions. I'm happy to share whatever I know...

Random closing thought:

I ended up using the ardupilot library/hal like a fancy arduino development environment that already had support for all the interesting flight controllers and devices. It would be some extra work up front to get up to speed with their build system and api's, but you could do the same thing and not even need the external arduino board. There are always many many good ways to do things, so please carry on with what makes the most sense to you, just thinking out loud here ...

Good luck, these sorts of projects provide tremendous unbounded learning experiences, but be careful ... it's easy to get obsessed with it all!

Curt.

 

[JasonK]

from here: <https://github.com/bolderflight/SBUS>

The SBUS protocol uses an inverted serial logic with a baud rate of 100000, 8 data bits, even parity, and 2 stop bits. The SBUS packet is 25 bytes long consisting of:

• Byte[0]: SBUS header, 0x0F
• Byte[1 -22]: 16 servo channels, 11 bits each
• Byte[23]
  • Bit 7: channel 17 (0x80)
  • Bit 6: channel 18 (0x40)
  • Bit 5: frame lost (0x20)
  • Bit 4: failsafe activated (0x10)
• Byte[24]: SBUS footer

looks like that wouldn't be to hard to setup code to receive it.

 

[clolsonus]

from here: <https://github.com/bolderflight/SBUS>

The SBUS protocol uses an inverted serial logic with a baud rate of 100000, 8 data bits, even parity, and 2 stop bits. The SBUS packet is 25 bytes long consisting of:

• Byte[0]: SBUS header, 0x0F
• Byte[1 -22]: 16 servo channels, 11 bits each
• Byte[23]
  • Bit 7: channel 17 (0x80)
  • Bit 6: channel 18 (0x40)
  • Bit 5: frame lost (0x20)
  • Bit 4: failsafe activated (0x10)
• Byte[24]: SBUS footer

looks like that wouldn't be to hard to setup code to receive it.

+1 on the bolderflight sbus code.

I used to work across the cubical aisle from the CEO of Bolder Flight and he does super solid amazing work all around. (But just know that code is designed to work with a teensy, so if you are running the code on an arduino style chipset, you'll most likely still need the hardware signal inverter on the sbus signal line.)

 

[JasonK]

+1 on the bolderflight sbus code.

I used to work across the cubical aisle from the CEO of Bolder Flight and he does super solid amazing work all around. (But just know that code is designed to work with a teensy, so if you are running the code on an arduino style chipset, you'll most likely still need the hardware signal inverter on the sbus signal line.)

yup, I was more grabbing the api definition stuff and seeing that it was rather simple. Does make me wonder why sbus is inverted... seems to be causing more problems then solving.

And yah, it does seem that a teensy is a better choice if doing this type of stuff as it has better hardware support for the things needing to be done.

 

[clolsonus]

I first saw sbus in the context of futaba and the equipment was always super expensive, so maybe inverting the signal line was a quick/simple attempt to obfuscate the protocol without going down the cryptography rabbit hole and needing more expensive mcpu's and adding latency and such? I am just totally guessing though. There is always that tension between people wanting to make money and people wanting to save money.

 

[clolsonus]

Going back to my previous thought. Ardupilot lays out it's libraries very much in the arduino style, and most of their library modules have a simple example app to show how to load and use the module (or just run a simple test of your hardware and prove you can read the device or do the thing the module is supposed to do.)

You can practically think of the matek board as a really fast/powerful arduino with all the useful sensors already attached (and connectors for all the things you want like gps, rc receiver, etc.) and library modules already available to read all those sensors.

In addition, they've done tons of work for you. So if you use their rc-in library, you can plug in just about any receiver including sbus and it just works, and all you have to do is use their common rc-in library module. You can use their rc-out library to drive the servos directly from the matek board. And then you can write the code in between to do straight passthrough ... or add some gyro stability ... or add fancy mixing modes ... or pretty much anything you can imagine.

If you are making your own high level app (even just modeled off one of their super simple examples) you can add any of your own code, much like arduino ... they even carry forward the setup() and loop() functions so it should all look pretty familiar.

So that said, there may be reasons a person wants to use the arduino paired with a flight controller, or write an sbus parsing function, and that's a great learning experience too ... so just depends what longer term trajectory you are eyeing ...

Curt.

 

[JasonK]

it is also a bi-directional bus, so sometimes things are ran with a pull up resistor and pull down only outputs, but it could also be the other way around. There could have been a technical choice or it could have been a 'we did what we did' choice that just makes life sad until MCUs started supporting inverted serial on the pins.

given that TTL serial has 'high' as the default, perhapse it has a 'pull low' resistor and a transister to pull up in the default config (which would make it inverted serial). This also matches the PWM signal of low being idle and high being 'on', which might have had some technical value early on if they wanted to be able to use the same port for PWM or SBUS depending on a configuration setting.

 

[OwenN]

yes you can get BECs at what ever current rating you need 'off the shelf'
how many amps are you looking for?
here is a 7 amp one: https://store.flitetest.com/flite-test-7-amp-ubec/
and 15 amps: https://store.flitetest.com/flite-test-15-amp-ubec/
fairly sure those are both more then the matek

Thank you. - I was using the incorrect Google search terms. (dc voltage converter, not BEC)

 

[OwenN]

This is probably not what you are looking for, but I've been working on some "simpler" (sorta?) firmware built on top of the ardupilot library/hal. I've only tested on a pixracer, but it should work on any ardupilot supported device. My firmware can do straight pass through to the servo outputs, it can do onboard mixing, it can do onboard gyro stabalization (prior to mixing, so works with vtails and elevons, etc.) It can output the pilot stick inputs via a simple serial protocol to a host (or companion) computer like the arduino. It is a work in progress, the code is currently going through some transition as I restructure some tihngs (in the telem branch), I've been developing and flying on this code since the mid-2000's. Happy to answer questions if anyone is interested. I'm sure if you ask on the ardupilot forum, ardupilot itself can also do all these things if you dig into the details.

Here's my flight controller firmware code:

https://github.com/RiceCreekUAS/rc-fmu-ap/tree/main

The communication protocol is kinda like a mavlink-lite (conceptually) without needing code for 100's of fancy packet types. You can define the packets you want to use with a simple json file, and then a script autogenerates a C++ header and also a python module so you can easily (and efficiently) pack/unpack messages. Coding communication by hand is not difficult, but it is tedious and brittle to changes, so this helps me a ton:

https://github.com/RiceCreekUAS/rc-messages

And one more important bit. The code is structured around sharing all the important data/state within the program using something called a property tree -- which is a 1-to-1 match with json, but provided via a convenient interface in C and python. There is even a way to write hybrid python/C++ apps that share data through a common property tree. I like developing around this design style, but for sure there are many other good ways to do things.

https://github.com/RiceCreekUAS/props2

And to make communication slightly easier, if you pick message field names that match the field names in the property tree (by agreeing with yourself to develop your code this way) then the messaging system can generate code to pack a message directly from the property tree, or unpack a message into the property tree. So the nice thing about that is you can receive and unpack a message in like 4 lines of code, and then data is there for the rest of your app to use.

The property tree is not thread safe (or ISR safe) so keep that in mind if you try it out in your code. I'm a big fan of a single main loop style of coding to keep thing as simple and understandable as I can.

On the subject of sbus vs. arduino. Sbus uses an inverted serial protocol (100,000 baud.) Arduino can support 100k baud, but you'll need a logical inverter on the signal line. You can get these for a couple $ -- at least before all the supply chain disruptions -- and it just plugs inline with RC style connectors. Otherwise if you pick a teensy instead of an arduino, these support inverted serial directly so you can plug your sbus right in.

Here is the arduino sbus library I was flying with for a few years (prior to porting all my stuff over top of ardupilot's library/hal layer and using their rcin library.)

https://github.com/RiceCreekUAS/rc-fmu-arduino/tree/master/src/sensors/sbus

Sorry for such a huge data dump all at once, I know it's a lot, but if any of this looks interesting, please feel free to ask questions. I'm happy to share whatever I know...

Random closing thought:

I ended up using the ardupilot library/hal like a fancy arduino development environment that already had support for all the interesting flight controllers and devices. It would be some extra work up front to get up to speed with their build system and api's, but you could do the same thing and not even need the external arduino board. There are always many many good ways to do things, so please carry on with what makes the most sense to you, just thinking out loud here ...

Good luck, these sorts of projects provide tremendous unbounded learning experiences, but be careful ... it's easy to get obsessed with it all!

Curt.

good. I got all of that.
I am trying to get something together is a simple style that I can learn and comprehend quickly.
This "sensor tree" and "property tree" etc. stuff may be a bit advanced for me.
I will google "Arduino solutions library" and see where that leads.