Thread Tools
Sep 17, 2020, 02:23 PM
Registered User
Quote:
Originally Posted by rcjetflyer2
First tutorial video showing the recommended default hardware setup, hopefully this gets some of you started with your build as parts start arriving:
Just in time! The Teensy boards (no pins) showed up a few days ago. The IMU and headers showed up yesterday. I should have an Orange RX 617 RX tomorrow. (small PPM output only RX for DSMX).

Might be able to have it flying in a quad this weekend.
Bob
Sign up now
to remove ads between posts
Sep 17, 2020, 11:28 PM
Registered User
RCvertt's Avatar
Quote:
Originally Posted by rcjetflyer2
First tutorial video...
Nice video. You mention 6 motors and 7 servos. Is that adjustable without getting to crazy with code changes? Say 4 motors and 9 servos or 2 motors and 11 servos? Curious because I currently have 4 motors and 8 servos available on Joops YMFC. I'd be a bit out of luck on my current project if 7 servos were my limit. Joop uses timers for other stuff so I can't go above 8 servos even if I drop a motor or two if I'm not mistaken. Wonder if this build has similar timer constraints preventing more servos?
Sep 18, 2020, 12:19 AM
Registered User
Quote:
Originally Posted by RCvertt
Nice video. You mention 6 motors and 7 servos. Is that adjustable without getting to crazy with code changes? Say 4 motors and 9 servos or 2 motors and 11 servos? Curious because I currently have 4 motors and 8 servos available on Joops YMFC. I'd be a bit out of luck on my current project if 7 servos were my limit. Joop uses timers for other stuff so I can't go above 8 servos even if I drop a motor or two if I'm not mistaken. Wonder if this build has similar timer constraints preventing more servos?
There is quite a bit of flexibility. I am new at this, so not 100% familiar with the details, but, to me it looks like:

There are a total of 13 output pins along one edge of the board, and it is easy to wire them up as outputs so that is what is shown. You can easily make those either OS125 ESC outputs or 50Hz PWM servo outputs. The default is 6 ESC and 7 servo, but that is pretty easy to change. Very obvious in the code.

On the other edge of the board, there are 14 pins total, 5 pins are used for power, ground, and the IMU connection, and cannot be changed.. One is used for PPM input. If you use the single wire PPM input instead of the 6 PWM inputs, that frees up the PWM in pins to be outputs instead. Any of them could be used for OS125 outputs. 2 of them could be used for PWM servo output. There are also 2 currently unused pins that could be either. Total on that edge, up to 8 OS125, and up to 4 servo.

That gives a total of 21 output pins. Any of them could be OneShot 125, and 17 could be servo.

On the bottom of the board, there are 10 more output pads. Any could be a OS125, 5 could be servo.

If you really got desperate, you could go to the Teensy 4.1 board, it has a few more outputs available.

At some point, there will be limits due to the processor, but, my GUESS is that it can handle a lot more outputs than the default is right now. The servo outputs are done mostly in hardware, so no problem there. The OS125 is done in software. It can probably handle quite a few more outputs before there is a timing issue.

In the past, I have done some airplanes that had to use 2 KK2 boards with OAV to get enough outputs (8 per board). Any of those planes could easily have been done with one Teensy 4.0. Much nicer!

Bob
Sep 18, 2020, 12:27 AM
Registered User
RCvertt's Avatar
Thanks for the info parky. Sounds very promising. I've done the dual FC option before, on a build pre MultiWii, not to show my age too much haha, but would rather not so this sounds good.
Sep 18, 2020, 01:22 AM
MultiWiiHead
Centurian's Avatar

mixed feelings...


This is a really cool project, but I feel like I'd be giving up too much in the name of simplicity. I have the components in a shopping cart but can 't seem to click buy now to build what is essentially a higher horsepower version of early MultiWii that I built years back.

I like the integrated FC's we have now with OSD, current sensors, altimeters, etc. They are lacking on the quantity of outputs generally but that seems a easier fix than starting over. INAV's next release will solve the same issues while maintaining OSD & GPS navigation. There will be support for an I2C pwm breakout and the logical conditions/global variables section is being greatly expanded to accomplish the same end goal as this project. I think if one's clever enough the changes are already avaialble.

What would be really cool would be to support INAV's efforts to push forward to bringing a hugely powerful configurable mixer that presents all the variables for manipulation. Something like an OpenTX(dRehmFlight) mixer integrating sensor & RX data to generate output. Maybe it's not possible add the level of dRehm flight flexibility to be "configurable" but rather plunk a dRehm flight mixer code section into an INAV fork.

I'm already seeing a fair amount of effort invested by some talented individuals here... Most of the code level stuff is beyond me and I have huge appreciation for what the opensource community has accomplished. I just hate to see starting over with the latest greatest engine when there's already an awesome formula car available that just needs a little work on the transmission....
Sep 18, 2020, 03:11 AM
Registered User
RCvertt's Avatar
Quote:
Originally Posted by Centurian
...What would be really cool would be to support INAV's efforts to push forward to bringing a hugely powerful configurable mixer that presents all the variables for manipulation...
I'm all for using a GUI instead of messing with code. I like what they are doing with the INAV mixer but it looks years away from the functionality I need. In the mean time I need easy to read code.
Sep 18, 2020, 10:49 AM
Certified Nerd
Thread OP
Quote:
Originally Posted by RCvertt
Nice video. You mention 6 motors and 7 servos. Is that adjustable without getting to crazy with code changes? Say 4 motors and 9 servos or 2 motors and 11 servos? Curious because I currently have 4 motors and 8 servos available on Joops YMFC. I'd be a bit out of luck on my current project if 7 servos were my limit. Joop uses timers for other stuff so I can't go above 8 servos even if I drop a motor or two if I'm not mistaken. Wonder if this build has similar timer constraints preventing more servos?
Parky's response pretty much covers everything, but just want to add--there's a complete tutorial in the docs for adding pwm/oneshot125 outputs. Also, adding many more oneshot125 outputs should not impact the code speed at all, as the way its coded, all oneshot pins are set high at the same time, then pregressively set low at the appropriate time according to the mX_command_PWM variables. So my commandmotors() function effectively has a maximum run time of 250 us
Sep 18, 2020, 10:54 AM
Certified Nerd
Thread OP
Quote:
Originally Posted by Centurian
This is a really cool project, but I feel like I'd be giving up too much in the name of simplicity. I have the components in a shopping cart but can 't seem to click buy now to build what is essentially a higher horsepower version of early MultiWii that I built years back.

I like the integrated FC's we have now with OSD, current sensors, altimeters, etc. They are lacking on the quantity of outputs generally but that seems a easier fix than starting over. INAV's next release will solve the same issues while maintaining OSD & GPS navigation. There will be support for an I2C pwm breakout and the logical conditions/global variables section is being greatly expanded to accomplish the same end goal as this project. I think if one's clever enough the changes are already avaialble.

What would be really cool would be to support INAV's efforts to push forward to bringing a hugely powerful configurable mixer that presents all the variables for manipulation. Something like an OpenTX(dRehmFlight) mixer integrating sensor & RX data to generate output. Maybe it's not possible add the level of dRehm flight flexibility to be "configurable" but rather plunk a dRehm flight mixer code section into an INAV fork.

I'm already seeing a fair amount of effort invested by some talented individuals here... Most of the code level stuff is beyond me and I have huge appreciation for what the opensource community has accomplished. I just hate to see starting over with the latest greatest engine when there's already an awesome formula car available that just needs a little work on the transmission....
I understand your hesitation. My reason for creating this is because I hated the idea of jumping through the hoops of setting up ardupilot/inav with all the extra features that I personally will never use. Kind the the opposite of what you want, it sounds like. dRehmFlight is intended to be (and always will be) a bare-bones flight controller for tinkerers to fiddle around with for their custom stuff.
Sep 18, 2020, 04:23 PM
Registered User
Quote:
Originally Posted by rcjetflyer2
Also, adding many more oneshot125 outputs should not impact the code speed at all, as the way its coded, all oneshot pins are set high at the same time, then pregressively set low at the appropriate time according to the mX_command_PWM variables. So my commandmotors() function effectively has a maximum run time of 250 us
The reason I was cautious about suggesting an upper limit on the OS125 outputs is the processing time within the loop that sets the outputs low at the end of their pulse. It is one "if" statement per output and you want that loop to run in under one microsecond to get accurate timing. I know this is a REALLY fast processor, and it can do some branches in a single clock cycle. But if you got really absurd and had 30 OS125 outputs, you MIGHT need more than 1 microsecond to make it through the loop.

There is certainly a lot of margin in there right now, and a dozen OS125 outputs should be just fine.

Besides wiring up 30 motors and ESC's is REALLY boring. We do not want to go there.

Bob
Sep 18, 2020, 04:41 PM
Registered User
Quote:
Originally Posted by rcjetflyer2
I understand your hesitation. My reason for creating this is because I hated the idea of jumping through the hoops of setting up ardupilot/inav with all the extra features that I personally will never use. Kind the the opposite of what you want, it sounds like. dRehmFlight is intended to be (and always will be) a bare-bones flight controller for tinkerers to fiddle around with for their custom stuff.
For my use, I TOTALLY agree. I want stuff to fly RC, not autonomous. Its not FPV so OSD does not matter. It will not have GPS. What I want is some "clean and simple" flight controller that lets me do some pretty complex VTOL controllers easily. Basically, what I want is the next version of Open Aero VTOL. If I ever really needed all the stuff in Ardupilot, I would get a prototype running with OAV or dRehmFlight and then port that specific configuration to Ardupilot.

OAV has worked far better than I expected in a lot of different VTOL's. i.e. doing a tilt wing and having the handling at half way transitioned work out just fine, in spite of it just being a simple linear interpolation of the hover and wing borne mix modes. I really expected to be needing to tweak an intermediate mode that did not exist. But the processor speed and memory were so limited that such a third "profile" was not possible. But dRehmFlight has more than enough capability to do that.

I am not thrilled about having to recompile and reload the whole code just to change one gain parameter. The LCD and buttons on the KK were kind of limited, but it was quite reasonable to change a few settings between flights while getting a complex VTOL to transition cleanly. In all the professional flight test I have done, we always had a "thou shalt not change the code during a flight op" rule. In some cases, changing a gain was OK, in others, not OK. (had to be tested in simulations before flying it). Depended on the scale of the program and the value of the airplane... and if you HAD a flight control simulator available. Anyway, my bias is against recompiling and reloading code at the field. Eventually, some sort of plug in touch screen display for changing gains would be nice, but it is a lot of programming effort to do (and uses up a bunch of IO pins if the Teensy is directly running the display)
bob
Sep 18, 2020, 05:14 PM
Certified Nerd
Thread OP
Quote:
Originally Posted by parky
I am not thrilled about having to recompile and reload the whole code just to change one gain parameter. The LCD and buttons on the KK were kind of limited, but it was quite reasonable to change a few settings between flights while getting a complex VTOL to transition cleanly. In all the professional flight test I have done, we always had a "thou shalt not change the code during a flight op" rule. In some cases, changing a gain was OK, in others, not OK. (had to be tested in simulations before flying it). Depended on the scale of the program and the value of the airplane... and if you HAD a flight control simulator available. Anyway, my bias is against recompiling and reloading code at the field. Eventually, some sort of plug in touch screen display for changing gains would be nice, but it is a lot of programming effort to do (and uses up a bunch of IO pins if the Teensy is directly running the display)
bob
It is arduino, so you could wire up some potentiometers on unused pins and write a few lines of code to map the analog potentiometer input to controller gain variables...tune at the field with some knob twisting until you like it, then go home and check those parameters in the serial monitor to hard-code them in. Might make for an interesting tutorial video down the road. hmmmm...
Sep 18, 2020, 05:38 PM
Registered User
Quote:
Originally Posted by rcjetflyer2
It is arduino, so you could wire up some potentiometers on unused pins and write a few lines of code to map the analog potentiometer input to controller gain variables...tune at the field with some knob twisting until you like it, then go home and check those parameters in the serial monitor to hard-code them in. Might make for an interesting tutorial video down the road. hmmmm...
The problem is too many gain variables. In particular, the OAV "offset" curves, that put a trim offset into each output PWM as a function of what % transition the plane is at. In the worst case that I have actually done, there were 6 ESC outputs (12 motors, but controlled in pairs) and 9 servos. Each output curve has 7 node points, so thats 105 points to tweak!

Typical flight test procedure was to do a hover, sort out all the offsets. Then set the transition control to only go as far as the first node point (16.5% transitioned). Gradually go from hover to that point. Figure out trim changes. Go back to hover and land, adjust 15 offset points as needed. Repeat until it flies fine at 16.5%. Then guess what the settings for 33% would be (i.e. copy over the 16.5% settings as a starting point) and take off, go to 16.5. then gradually go to 33%. Go back to hover, land and adjust as needed. Then 50% transitioned, etc. Once you got past 50% it was pretty easy to jump to 100% and then sort out wing borne, then go back to the intermediate points. At 75% the plane is moving pretty fast, and maneuvering when its not sorted out is not always fun. But, normally, you have a pretty good idea of what will work for wingborne trim.. and TX trims can usually handle any issues.

That plane had OAV on two KK boards. One for the front of the plane, one for the back (easiest to wire). But it was possible to get pretty good transition within about a half hour flying time, done in a few hours.

I have some really good video of that plane, but it is company proprietary still.

bob
Sep 18, 2020, 08:15 PM
Registered User
Here's some stuff to play with (or throw darts at.... )

The attached code contains:

1) The cleaned up MPU6050 implementation. I moved it to the MPU6050 library for clarity. The full scale gyro and accel ranges are selectable.
2)The MPU9250 implementation, based on the MPU9250 library. This code expects the MPU9250 to be connected to SPI2 on the bottom of the board. It is, unfortunately, difficult soldering. But the reads are very quick with a 20 MHz SPI clock. Full scale gyro and accel ranges are selectable too. Currently the low pass filter values are the same for the MPU6050 and MPU9250, that may need some study.
3)SBUS receiver, based on the sbus library. Expects sbus input at RX5. The raw data is getting processed correctly, but it needs some scaling and biasing work to be useful.

I've tested some, but not all, of the full scale ranges. The MPU9250 is binging in gyro/accel/mag data, but need to give some thought to mag filtering and scaling. The way it's used by the Madgwick 9DOF fusion, it may only need to filtered and we can let the fusion algorithm normalize it, so no need for scaling. Need to look at the data sheet some more. Testing is obviously a work in progress.

The rub with this is that you need the libraries I attached. The MPU9250 lib has some mods to make SPI work. These mods haven't been merged to the main stream library, but I included them here to make it work. A few delay statements are necessary because this processor is so fast that the SPI device needs time to get ready after the device select goes low. Copy these folders to the library folder in the Arduino folder which lives in the documents folder.

So it's definitely a work in progress, but I figured some might want to play with it and maybe fill in some of the testing holes.

Last, I rearranged a few sections of the code to put the user definable stuff at the top.

Need to solder on some headers next, and then I'll be able to further test things, and finish the sBus integration.

Have fun.
Sep 18, 2020, 10:32 PM
Nicholas Jacobs
njacobs's Avatar

Requirements Doc


Nicholas et al.

Well, it seems to me that there are quite a few Engineer(Parky, Ran...) and Comp Sci types (Me , Nicholas, ... ) and others with a lot of good ideas and talent to make this a really good product if we put our heads together.

If we as a group go down that path of working with (under) Nicholas on dRehmFlight, I think (and I'm not meaning to step on Nicholas' foot by any means), need a project requirements doc to work from. Gather requirements, work out priority, perhaps divide and conquer - put in github, share, build....

I'm with Parky on recompiling, building, downloading. Its another one of the things I like about OAV - its configurable from a user interface without even needing a computer. Let's put it all in there and just configure !

Nicholas, you have an awesome prototype, what are your thoughts ?

Personally, I liked the GUI, import/export, save functionality of OAV (not because I worked with David on it , but because it was my suggestion in the first place!! )

I also like a table/parameter - driven program and also the concept of a display - I always used the KK2.1 with separate display - but it was still small for my old eyes. I was thinking that having configurable parameters (like OAV), and a detachable touch screen display (ardino-based) to display, set, save, sent to PC/Mac over wifi etc.

My other wish would be to have more than two flight modes to blend, perhaps 3 or 4 (configurable).

An easy way to duplicate channels would be useful too. (along with a PC/MAC gui perhaps )

There's a lot of excitement about this - good to see

I might have about 12 or so KK2.1, 4 red button, 2 min red button for sale real cheap soon (some New in box)

Cheers
Nicholas (Jacobs, not Rehm)
Sep 19, 2020, 07:50 PM
Certified Nerd
Thread OP
Quote:
Originally Posted by jihlein
Here's some stuff to play with (or throw darts at.... )

The attached code contains:

1) The cleaned up MPU6050 implementation. I moved it to the MPU6050 library for clarity. The full scale gyro and accel ranges are selectable.
2)The MPU9250 implementation, based on the MPU9250 library. This code expects the MPU9250 to be connected to SPI2 on the bottom of the board. It is, unfortunately, difficult soldering. But the reads are very quick with a 20 MHz SPI clock. Full scale gyro and accel ranges are selectable too. Currently the low pass filter values are the same for the MPU6050 and MPU9250, that may need some study.
3)SBUS receiver, based on the sbus library. Expects sbus input at RX5. The raw data is getting processed correctly, but it needs some scaling and biasing work to be useful.

I've tested some, but not all, of the full scale ranges. The MPU9250 is binging in gyro/accel/mag data, but need to give some thought to mag filtering and scaling. The way it's used by the Madgwick 9DOF fusion, it may only need to filtered and we can let the fusion algorithm normalize it, so no need for scaling. Need to look at the data sheet some more. Testing is obviously a work in progress.

The rub with this is that you need the libraries I attached. The MPU9250 lib has some mods to make SPI work. These mods haven't been merged to the main stream library, but I included them here to make it work. A few delay statements are necessary because this processor is so fast that the SPI device needs time to get ready after the device select goes low. Copy these folders to the library folder in the Arduino folder which lives in the documents folder.

So it's definitely a work in progress, but I figured some might want to play with it and maybe fill in some of the testing holes.

Last, I rearranged a few sections of the code to put the user definable stuff at the top.

Need to solder on some headers next, and then I'll be able to further test things, and finish the sBus integration.

Have fun.
Just had a look through your changes--awesome work! I will include them in the next 'official' 1.2 release and make sure to update the docs accordingly. I think the way you've done everything makes the most sense and is understandable as well. I'll try to get ahold of an sbus radio to test the sbus implementation soon. Not too much of a fan of needing to install extra libraries, but I suppose it must be done...I'll make sure thats included in the docs/tutorials to make it as painless as possible. Thanks again for helping to clean up my code a bit


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product Radiolink-Byme-A-D Flight Stabiliser Flight Controller Gyroscope Self-stabilization Merch Banggood.com 0 Aug 13, 2019 09:45 PM
Discussion 3 Axis-A AUX Control System Gyro Flight Controller Stabilizer For FPV Flying Wing EDF scousethief Banggood.com 0 Aug 05, 2018 06:58 AM
Discussion Is there a fixed wing flight stabilizer that can control yaw by thrust vectoring? jamieFL FPV Equipment 23 Apr 01, 2018 11:46 PM
Discussion OpenAero-VTOL Flight Controller Introduction Ran D. St. Clair 3D Foamies 0 Oct 05, 2015 03:34 PM