Publishing PWM values for motors

Firmware/software/electronics/mechanics
malintha
Beginner
Posts: 17
Joined: Thu Dec 07, 2017 4:58 pm

Re: Publishing PWM values for motors

Post by malintha »

Hi natolambert,

The approach you have followed to send the PWM values sounds correct to me. Make sure that you are not held up by unnecessary tasks by commenting them out in the stabilizer.c. And also make sure that the stabilizer.c runs at 1000Hz (RATE_MAIN_LOOP RATE_1000_HZ). However, did you take the maximum logging frequency into the consideration? As far as I could remember logging cannot be done beyond a certain max frequency. Secondly, if you calculate the PWM values offboard, is it really required to send set points/state variables to the drone?

Basically, what I did there was; adding a new 4 variables for the setpoint type and setting the motor values to those 4 variables by decoding the incoming CRTP message in the crtpCommanderGenericDecodeSetpoint().

Code: Select all

void crtpCommanderGenericDecodeSetpoint(setpoint_t *setpoint, CRTPPacket *pk) {
  static int nTypes = -1;
  ASSERT(pk->size > 0);
  if (nTypes < 0) {
    nTypes = sizeof(packetDecoders) / sizeof(packetDecoders[0]);
  }

  const void *data1 = ((char *) pk->data);
  const struct geometricPacket_s *values = data1;
  size = pk->size;
  m1 = values->m1;
  m2 = values->m2;
  m3 = values->m3;
  m4 = values->m4;

  setpoint->m1 = m1;
  setpoint->m2 = m2;
  setpoint->m3 = m3;
  setpoint->m4 = m4;
}
and in stabilizer.c add the following to the while(1) loop in the stabilizerTask.

Code: Select all

        
        while (1) {
        vTaskDelayUntil(&lastWakeTime, F2T(RATE_MAIN_LOOP));

        getExtPosition(&state);
        stateEstimator(&state, &sensorData, &control, tick);

        commanderGetSetpoint(&setpoint, &state);

        motorsSetRatio(MOTOR_M1,setpoint.m1);
        motorsSetRatio(MOTOR_M2,setpoint.m2);
        motorsSetRatio(MOTOR_M3,setpoint.m3);
        motorsSetRatio(MOTOR_M4,setpoint.m4);

        checkEmergencyStopTimeout();

        if (emergencyStop) {
            powerStop();
        } else {
            powerDistribution(&control, &setpoint);
        }

        tick++;
    }
natolambert
Beginner
Posts: 4
Joined: Tue Aug 14, 2018 9:30 pm

Re: Publishing PWM values for motors

Post by natolambert »

Thanks for the follow up. I'll add a few more details to our approach, which is very similar and where the issues may be coming up.

We only use the premade datapackets as a carrier for sending PWM values, we do not send velocity or state data. Plan on refactoring the code to make a new packet type later. Initial work was "will this work" kind of thing.

We are looking for attitude control, so we send back packed attitude data crazyflie-> ROS at 250Hz. You can increase the logging frequency by removing the *10 in the code here https://github.com/bitcraze/crazyflie-f ... log.c#L383. We found that here: viewtopic.php?p=15300#p15300. We found that when collecting training data, you could log the state data at 250Hz stably (timestamps 4ms consistently). Currently think that maybe with more outboard commands from the ROS node, maybe the radio is getting clogged up. (Collecting data we use internal controllers).

1. For confirmation, was the only state data you were using from VICON, or did you figure out how to send state data backet in ACK packets.
2. Were there any notable changes you had to make in ROS with publishing or subscribers etc, or did you use your own interface?
3. I was looking in the ROS radio control loop, and noticed that it has a lot of sendPing() calls. It seemed like our log data was coming on the ACK's from send ping. Curious if anyone can chime in on that functionality.

Will update if I figure more out & thanks.

N
whoenig
Expert
Posts: 395
Joined: Mon Oct 27, 2014 2:55 am

Re: Publishing PWM values for motors

Post by whoenig »

I am the author of crazyflie_ros and can help out for 3.
Logging data is sent back to the PC as part of the ACK payload. A ping packet is basically an empty/No-Op packet that just triggers an ACK. So in case the user does not sent enough other requests to the CF (such as sendSetpoint), or the user uses broadcast communication only, we use sendPing() to get enough logging data.
malintha
Beginner
Posts: 17
Joined: Thu Dec 07, 2017 4:58 pm

Re: Publishing PWM values for motors

Post by malintha »

1). For that PWM enabled implementation, I entirely relied on VICON data to calculate the attitude, velocity etc. So I only had to send data packets with PWM values to the drone.
2). There are some changes I did on the cf_ros to send the PWM packets out. Feel free to try this out. This might not be the optimum way of doing that as I had to remove some ping timeouts to get it working. But, as I was getting all the values from the vicon, it wasn't an issue for me.
https://github.com/Malintha/crazyflie_r ... controller
https://github.com/Malintha/crazyflie_r ... controller
natolambert
Beginner
Posts: 4
Joined: Tue Aug 14, 2018 9:30 pm

Re: Publishing PWM values for motors

Post by natolambert »

Thanks for the insight. It seemed like our system was trying to log too fast while sending commands. We turned off more log commands that we weren't using as state data and further compressed a couple floats down to fewer bytes (eg. compress yaw pitch and roll each to 10bits and package all three into one uint32). We got our effective control (Tx) and log data rate (Rx) from ROS to hit 180Hz. We're hoping this is enough, especially as it doesn't seem to be the limiting factor anymore. I'll update you guys if we get the attitude control stable with just these internal variables and offbaord control.
Post Reply