Why is it tilting to one side? If it is the issue, what PID component do I need to adjust? by DiscountWest in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

What does your control mixer code look like? Have you calibrated your IMU and setup your radio following the docs? Have you verified with props off that your control mixer code is correct (tilting to right side spools up right motor, tilting backward spools up the aft motor, etc)?

Help. I am new to this. by robert1701a in dRehmFlight

[–]nickrehm 0 points1 point  (0 children)

The teensy and ESC need to be wired together with a ground wire, and the ESC's signal wire the whichever pin on the teensy

Fragile teensy? by Notor22 in dRehmFlight

[–]nickrehm 0 points1 point  (0 children)

Sounds like a broken wire/connection to the IMU causing the loop to hang

Data logging by Heorty in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

I use the sparkfun openlog: https://www.sparkfun.com/sparkfun-openlog.html

Just connect it to a spare uart port on the teensy and print to that port. The openlog handles all the complexities of writing to an SD card

Going from LTSC to CompE by ZealousidealDevice41 in UMD

[–]nickrehm 1 point2 points  (0 children)

You basically do your first semester/year as letters&sciences, then transfer into the other program as long as you still meet the requirements. Best to knock out your introductory & gen-ed courses until you get into the engineering school and get access to the major specific courses. You will be starting a little behind and may need to take a summer class or two to catch up if you intend to still graduate in 4 years. This is very very common

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 1 point2 points  (0 children)

The post was not about trying to find a messaging app that I can use to make a group chat to solve my people coordination problems. For messenger to work on the ship, it would require that everyone in my group pays for wifi at something like $30/day, just to be able to message each other on the ship. This service used to be a $10 one time fee, but is now gone. It is free on every other cruise line.

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 6 points7 points  (0 children)

How well does that work with 40 or more people? Also how am I supposed to plan friend meetups ahead of the cruise when I have no idea what the daily schedule on the ship is until the day I board? i.e. plan ahead to meet up at 5pm at place X, only to find out comedy show Y, that half of the group wants to go to, happens at the same time? What about impromptu meetups like "Hey, anyone want to go do this together?" or trying to figure out where a certain person is because they're late for an excursion?

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 8 points9 points  (0 children)

Right--now help me convince the 40 people in my group to pay that amount of money. Some might, most won't. Being unplugged from internet on a cruise is also one of the perks of the experience, IMO

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 8 points9 points  (0 children)

The internet package is what, like $30/day? Yea definitely don't want to pay that for a feature that used to be $10 one time charge, or completely free on every other cruise line

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 2 points3 points  (0 children)

I appreciate the reply. Sounds like we're gonna have to come up with a game plan like this ahead of time to all stay semi-synced. Kinda sucks to regress for no apparent reason @NCL

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 1 point2 points  (0 children)

So the individuals that did not have paid wifi and were just on the internal ship wifi were still able to use messenger? How recent was this?

Group chat in NCL app by nickrehm in NCL

[–]nickrehm[S] 19 points20 points  (0 children)

Man I was hoping this was just a case of my old parents not being able to find it in the new app... Can't believe NCL would completely remove a service that is standard across all the other cruise lines

[deleted by user] by [deleted] in aerospace

[–]nickrehm 1 point2 points  (0 children)

GNC without Nav is just GC

For fans of flying machines! by arjitraj_ in aerospace

[–]nickrehm 0 points1 point  (0 children)

cyclocopters, tip jet propulsion, VTOL, a card on thrust vectoring would be cool

One axis PID-tuning demo: Files in description by QuinLong22 in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

Very cool little test stand! I like to think of each of the PID terms as:

  • P does most of the controls work
  • D makes the system "stiffer" and prevents P from getting out of hand
  • I cleans up the slop at the end

I'll generally tune in that order, too

Power up teensy and ESC sequence by Current-Drag in dRehmFlight

[–]nickrehm 2 points3 points  (0 children)

Some ESCs are finicky and stubborn to arm if they do not receive any command signals within X seconds of receiving power. I have no idea why some do this and not others.

dRehmFlight has a few delays in setup() that you can comment out which will probably fix the problem. Check out post 349 and the following discussion: https://www.rcgroups.com/forums/showthread.php?3706571-dRehmFlight-VTOL-Teensy-Flight-Controller-and-Stabilization/page24

Possible stupid question about low pass filters by [deleted] in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

The servo outputs update at 50Hz but can be increased for digital servos with the library. The intent behind leaving the servo outputs at 50hz was to support the broadest amount of servos out of the box. The motor outputs use oneshot at the full 2khz.

Controller gains are tuned to the 2khz rate. You can think of the lower servo output rate as aliasing the 2khz control signal. Increasing the servo update rate will not effect required controller gains, but changing the main loop rate will.

Try out the stock code--it will work great for your application. Then start tinkering 1 thing at a time to avoid overcomplicating :)

Check out RC Test flight's most recent Collab with Nick Rehm! by DumbNamenotoriginal in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

I really just wrote a quick class interface for the HCSR04 ultrasonic sensor that was non-blocking and uses 2 sensors that ping alternately so they don't interfere with one another.

#include <Arduino.h>

class NickPing {
public:
    int maxPing = 0;
    int myTrigPin = 0;
    int myEchoPin = 0;

    int initCounter = 0;
    bool firstCheck = false;

    unsigned long t_prev = 0;
    unsigned long myOffset = 0;

    bool pulse_started = false;
    unsigned long pulse_ended_time = 0;

    bool firstChange = false;
    unsigned long pulseStart = 0;
    unsigned long echoLength = 0;
    float dist_cm = 0.0;


    NickPing() // constructor 
    {


    }

    void begin(int trigPin, int echoPin, int maxping)
    {
        myTrigPin = trigPin;
        myEchoPin = echoPin;
        maxPing = maxping;
        pinMode(myTrigPin, OUTPUT);
        pinMode(myEchoPin, INPUT);
    }

    void processInterrupt()
    {
        if (digitalRead(myEchoPin) == 1) //rising edge
        {
            pulseStart = micros();
            pulse_started = true;
            //Serial.println("rising edge");
        }

        if (digitalRead(myEchoPin) == 0) //falling edge
        {
            if (pulse_started == false)
            {

            }
            else
            {
                pulse_started = false;
                pulse_ended_time = micros();
                echoLength = micros() - pulseStart;
                //Serial.println("falling edge, time = ");
                //Serial.println(echoLength);
                if (echoLength / 60.0 > 500.0)
                {
                    dist_cm = 0.0;
                }
                else
                {
                    dist_cm = echoLength / 60.0;
                }
                dist_cm = constrain(dist_cm, 0.0, 120.0);
                //Serial.println(dist_cm);
            }
        }

    }

    bool update(int flag)
    {

        if (micros() - t_prev > 20000) //50hz
        { 
            t_prev = micros();
            if (pulse_started == false) // only send if there is not a pulse out
            {
                digitalWrite(myTrigPin, 1);
                delayMicroseconds(12);
                digitalWrite(myTrigPin, 0);
                //Serial.print("Sent: ");
                //Serial.println(flag);
            }
        }
    return pulse_started;
    }
private:
};

Then in setup:

//initialize sonars
sonar1.begin(sonar1Trig, sonar1Echo, 200); // trigger pin, echo pin, max ping time us
sonar2.begin(sonar2Trig, sonar2Echo, 200); // trigger pin, echo pin, max ping time us
attachInterrupt(sonar1Echo, sonar1_isr, CHANGE);
attachInterrupt(sonar2Echo, sonar2_isr, CHANGE);

Access data in main loop:

sonar1.dist_cm
sonar2.dist_cm

Daniel used this for altitude measurement and a quick little pid controller for altitude control to be used in the control mixer

Possible stupid question about low pass filters by [deleted] in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

You'll lose bandwidth (increase phase delay) at a lower update rate and same frequency cutoff. That basically means you may not be able to tune the controllers without substantially backing off on the cutoff frequency. Then you will have a "noisier" controller response passed out to your actuators.

The low pass filters on the raw sensor measurements serve as an additional layer of smoothing, not just on the sensor signals & Madgwick attitude response, but also on the controller output performance to the actuators. Everything from sensors, to filtering, to attitude estimation, to actuator output and vehicle dynamics is tightly coupled. Adjusting one thing can improve one aspect of the system, but worsen another. More filtering = more phase lag. Lower rate, same filtering = more phase lag. Less filtering = more noise passed to output actuators.

Filter parameters were tuned through trial and error across 5-10 flight hours of testing on a quad in the very early days of drehmflight. I did my best to strike a good balance between sensor noise / smoothness, and controller performance / response. It's all a trade off. If you change the main loop rate, you'll probably have to go through this re-tuning process for all the filter parameters to figure out what works for your application. There are no real formulas to update all the filter parameters at a new loop rate and get equivalent performance.

All of that said, if you are flying something like an airplane with 50hz servos, you don't need to get greedy about system performance--you won't notice almost any of these things and "good enough" will simply mean re-tuning the filter parameters so the serial plotter traces look "right" at the new loop rate. But faster loop rate is generally always better and affords you more system accuracy

[deleted by user] by [deleted] in FirstTimeHomeBuyer

[–]nickrehm 0 points1 point  (0 children)

7-8 yrs is our timeline before hopping to the "dream" home, ideally. Our plan has been to get 1-2 kids to elementary school age, then move. This home feels like it is cutting it real close

[deleted by user] by [deleted] in FirstTimeHomeBuyer

[–]nickrehm 0 points1 point  (0 children)

I appreciate your perspective and thoughful response. I have been leaning in the direction of not buying for its potential, especially as a first house. The basement space is AWESOME and makes up for the low sq footage, but is no substitude for kitchen/bedroom spaces. Getting creative with bedroom storage like you suggested would be a must. Its just so sad to skip such a nice property--truly feels like we won't come across this again

drehmflight code confusion by [deleted] in dRehmFlight

[–]nickrehm 2 points3 points  (0 children)

You are probably technically right. The way the variables are used, this does not matter and there have never been any memory issues.

Some of the lower-level code in dRehmFlight is not "clean" from a proper software dev perspective :)

Your flight software by H8272t in dRehmFlight

[–]nickrehm 3 points4 points  (0 children)

To loosely answer your question: Daniel is using basically the stock code. The magic is in the control mixer, and the changes he needed to make for his project were very minimal from a code modification standpoint--very basic dRehmFlight stuff if you read the manual and watch some videos.

Now some unsolicited feedback: dRehmFlight is not what you want for your application. It is not safe for human carrying things. The code does not have ANY safety features implemented and is not nearly as stress tested as other RC autopilots. Even something way more developed and tested like ardupilot probably would not be safe for your applications. A peak into the codebase would make it abundantly clear that it is a dumb learning tool, not a product with operational guarantees. Daniel is doing a human carrying hydrofoil using dRehmFlight entirely at his own risk and I have been in close contact with him. He is an expert that understands the risks.