V-22 Osprey 2025 Update

-

 It's hard to believe that this project is already 6 years old.  I never thought in 2019 that I would still be pursuing this idea of making my own V-22 RC model.

It hasn't been 6 years of continuous work, that's for sure. I seem to move in fits and starts, making progress here and there, getting frustrated and putting it away for months at a time before diving in again.

This is a list of challenges I'm having:

  1. Poor quality of IMU chips
  2. Improper PID tuning leading to stability issues
  3. Near overload of rotor motors
Poor quality of IMU chips

The dRhemFlight VTOL project leverages inexpensive MPU-6050 6-DOF sensors.  While inexpensive, recent batches of these chips have been unreliable.  A previous unit in the Osprey decided it no longer wanted to interface regularly with the Teensy microcontroller via I2C.  Another one in my F-35 VTOL (another Nick Rehm design) would occasionally "lock out" and return bad data, causing a crash.  After these two recent failures, I'm investigating other alternatives.

I purchased a couple of LSM6DSOX boards from Adafruit and worked to integrate them into dRhemFlight.  I've worked out the code to the best of my ability, and it does seem to be working.  I've been able to hover the V-22 in my yard with some success.

Ports of dRhemFlight to other platforms, like the ESP32, are in the works by other folks, and that might also affect this project.


Improper PID Tuning

Nick developed dRhemFlight initially for multirotors and other fixed-wing style aircraft. To my knowledge, I'm the only one who has tried to implement it in a rotorcraft.  It's been difficult to determine what the correct throws should be on the cyclic servos to have a good control response.  The dRhemFlight code doesn't do a great job of mapping the relationship between max angle or rate, the P term of the PID controller, and the actual servo response.  Add in the input from the pilot on the PWM line, and it compounds the issue.

I think previous stability problems were due to not understanding this relationship.  I've toned down the roll/pitch/yaw throws by reducing the max rate, but I have to increase the P term to compensate for a larger control response.  There's no particular guidance on what the PID terms should be -- they are just numbers in the code.  Is 0.5 good?  Is 0.75 too much?  It's all a bit overwhelming.  Thanks to the plethora of channels available on SBUS (16 channels), I mapped 6 of those channels to adjustments in my radio, and I can adjust the PID values for 2 directions at a time live without having to plug in a computer.

I have had some recent "successes" of hovering around the yard for a few seconds at a time.  I am seeing better stability overall with the changes I've made this year.


Near overload of rotor motors

In previous iterations, I was using the stock motors from the KDS Innova 450 helicopters. These are 2838-sized motors at 3650KV on 3S batteries.  The default configuration is a 2-blade setup, but I'd really prefer a 3-blade rotor to be more scale.  Even with a smaller pinion gear to increase the gear ratio, the motors were running too hot for my liking.  I decided to try switching to a 6S setup.  I made a new series battery connector to use instead of the parallel system I had originally. I had been doubling up 2x 3300mAh 3S packs, and this new one puts them in series for a 3300mAh 6S system. The new motors are 2520-1900KV motors.  The increased diameter meant I had to redesign the rotor side plates a little bit, but the change was fairly straightforward.  However, during the recent hover tests, I've noticed these motors are also getting a bit too hot for my liking.


So what now? I'm going to proceed further and see if I can get the PID tuning dialed in better for hover.  I have also seen some nasty vibrations, and I wonder if they are from the long drive shaft.  I have some additional bearings I can add to support the drive shaft better.  It means dismantling the rotors, but it should offer some support.  Hopefully, I can remember to update my progress more often!

Until next time...


Comments

Post a Comment

Popular posts from this blog

Whereabouts Clock Simplified

-
Image
 Whereabouts Clock (v6) When I published the last update to the Whereabouts Clock I knew that I would make another version that simplified the architecture.  Apple iOS supports the idea of location regions (home, work, etc.) and can notify an App when the user enters and exits a region.  This "presence" feature is utilized in Life360, OwnTracks, and others. Instead of looking up a user's location from a static database, we can leverage the built-in feature to tell the Arduino clock how to move and when.  There's no more polling a web page for updates or maintaining a database of locations. So how does the whole system work now? Devices with OwnTracks send location data (either standard location messages or transition events into/out of a known region) to the MQTT broker (Mosquitto).   These messages contain the region information setup on the device (more on that in a minute) The Mosquitto MQTT broker broadcasts these messages to its subscribers (other OwnT...
Read more

V-22 Osprey Project - Design Changes for v3

-
Image
It's been a busy end of 2021, and as we start 2022 I'm getting closer to building version 3 of the Osprey wing.  The single biggest problem I've faced is the amount of backlash in the direct spur gear drive of the tilt mechanism.  It introduces some nasty instability that, left unchecked, would likely destroy the model in flight. I've investigated other tilt mechanisms, but the one I keep coming back to is the rack and pinion design that Tom Mast uses in his model at Rotormast.  His design uses a high-torque digital servo with a small pinion gear driving a rack attached to the rotor nacelle.  The servo has been modified with an external potentiometer that's driven by a gear on the translation tube to give positional feedback to the servo.  I like this design a lot because 1) It works, and his model is proof, and 2) it requires less torque from the servo and has less backlash. I ordered the pair of modified servos, potentiometer, and rack from Tom's site and star...
Read more

Whereabouts Clock Update

-
Image
After a few months, Life360 has gone the way of Apple and locked down the API I used to get location data from the phones.  This is disappointing, but inevitable. I found on a forum for Home Assistant that the app OwnTracks might be a suitable alternative. It's a neat little app that will trigger the phone to send its location data via MQTT to a server that you specify. I had to rework the code a bit, but the new operation is as follows: OwnTracks on the phone will push location data per its configuration to the MQTT server (Docker container) The Mosquitto (MQTT Broker) container will receive the data and forward the data to its subscribers The MQTTWarn container is a subscriber and translates the received data and adds it to the MariaDB database The Apache web server hosts a Python CGI script that is checked each minute by the Arduino microcontroller.  If the data has changed, the hands are moved to the new location. The only exposed port to the Internet is TCP 1883 for...
Read more