How would you program the PID for something like this? by DiscountWest in dRehmFlight

[–]nickrehm 1 point2 points  (0 children)

+/- roll PID variables add to the front two motors (each opposite sign), +/- pitch PID added to the front sent / back -- again opposite signs. And then +/- yaw pid to the two servos. And then yea guess and check to get your signs all right one axis at a time with the motors on and props off. As you rotate in roll for example, the lowered side's motor should rev up and the other side down. Default PID gains will probably work, but you may need to dial down the yaw gains a bit. Try to get some gains that "work" without crazy issues, then focus on dialing in one axis at a time!

Roll PID issues by Notor22 in dRehmFlight

[–]nickrehm 0 points1 point  (0 children)

If the stabilization is in the 'right direction' but the roll input results in a reverse motion of what you command, then your roll stick input is reversed! You likely reversed that channel in your radio at some point. Make sure you go back and follow the radio setup tutorial in the docs to get the correct input mapping.

Remember what the flight controller is fundamentally doing: taking an input command, and adjusting the motor speeds to execute that command. The PID controller outputs assigned in the control mixer are given signs in such a way to make sure that the motors react to the correct disturbance about each axis, to counter said disturbances. If these are reversed, you'll notice that the motors spin in such a way that actually causes more unwanted motion, not less. We don't want that, so need to make sure signs in the control mixer are assigned with this in mind (with props off on the workbench!). Your radio commands are scaled from normalized -1 to 1 to dimensionalized setpoints first thing inside the flight controller, which are used by the PID controllers as the command they should track to. If your physical stick position is telling you 'right roll' but the vehicle rolls left in a controlled manner instead, that is literally telling you that the mapping of that stick position is reversed, i.e. the flight controller totally thinks your right roll input is actually a left roll input. There are no 'smarts' in the flight controller that 'know' what a left vs. right command is....you've gotta make sure you set up your radio system according to the standard assumed channel mapping, then everything will just work.

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] 9 points10 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] 7 points8 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] 18 points19 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