Configuring Orel with Pixhawk and QGroundControl

Support Sapog motor control
1

Hi Pavel,

I’m trying to Fly a DJI F450 quadrotor with a Pixhawk and 4 Zubax Orel 20 ESC’s connected via UAVCAN. I’m using QGroundControl.

Here is what I did:

  1. Daisy chain 4 Zubax Orel’s to the Pixhawk CAN port, and connect the 4th Orel to a terminated Babel board.
  2. Open UAVCAN GUI Tool and turn on the Dynamic node ID allocation server
  3. In QGroundControl under parameters, set UAVCAN_ENABLE to “Dynamic ID/Update” and save
  4. In QGroundControl under Power, check “Show UAVCAN Settings” and “Enable UAVCAN…”
  5. Reboot the Pixhawk
  6. All 4 Orel boards beep twice and have solid green lights
  7. In QGroundControl under Power check “Show UAVCAN Settings” (Enable UAVCAN still checked) and “Start Assignment”
  8. All 4 Orel boards have blue blinking lights
  9. Spin the motors by hand in order (1, 2, 3, 4…).
    Each Orel board beeps, some once and some twice.
  10. All 4 Orel boards have solid green lights

So this worked really nice and I was basically able to reproduce the video here:

pixhawk.org/modules/pixhawk_esc

Questions:

My problem is that when I disconnect the Babel board from Orel #4 and terminate it, steps 7 fails.
So, the QGroundControl/Pixhawk UAVCAN Motor Index and Direction assignment does not seem to work without the Babel connected.
Do you understand why this could happen?
Could this be related to the discussion here: github.com/PX4/Firmware/pull/5356 ? (Should I post there? I would be happy to help with testing).

Do you know if a quadrotor using Pixhawk with Zubax Orel 20 (over CAN) and QGroundControl has successfully flown yet?

On step 9, some of the Orel boards beep once and others twice when spinning the motors.
What does one beep mean? What does two beeps mean?
The number of beeps didn’t seem to match CCW/CW and wasn’t repeatable.

Also, I noticed that in step 5 after changing UAVCAN_ENABLE to “Dynamic ID/Update” after rebooting the Pixhawk it reads “Motors/Update” in QGroundControl.

I’m not sure what the right forum is for this…
Maybe under pixhawk… but the pixhawk page “forum” link (discuss.px4.io/categories…. but when I tried to sign up I never got a confirmation email (not even in spam) so I can’t post there at the moment.
If I should post this elsewhere please let me know.

Thanks!

Derek

2

Hi Derek,

Sorry to keep you waiting.

First of all, I reported about your registration issues at the PX4 forum here, please monitor this thread, they may post some solutions: discuss.px4.io/t/new-user-regist … ssues/1740

Re your question: yes, plenty of UAVs were flown with PX4 and Orels. PX4 does have some difficulties with UAVCAN, they are getting resolved, albeit slower than I would like to.

The failure at the step 7 could be caused by:

  • Broken termination plug
  • Misconfigured PX4 - the dynamic node ID allocation server may be turned off. However, if “UAVCAN_ENABLE” is really set as you described, that shouldn’t be the case. If you have access to the CLI on PX4, please run “uavcan status fw” and see whether it confirms that the dynamic node ID allocator is running.
  • A bug in PX4. Wouldn’t be the first one.

The varying numbers of beeps must be caused by another obscure bug in PX4. The Orels themselves don’t make any sounds except right after bootup; in normal operating mode they are commanded to beep by the PX4.

We are currently continuing to work on the general PX4 UX issues with the PX4 team.

I appreciate your cooperation.
Pavel.

3

Thanks Pavel,

I tried this again after updating the PX4 firmware (v1.4.4) and I still see the same problem.

QGroundControl does not seem to allow UAVCAN_ENABLE to be set to “Dynamic ID / Update”.
The value is set to “Motors / Update” after reboot.
Is this a problem?

I have some questions about the UAVCAN_ENABLE parameter…
In QGrounControl there are 4 options (In the order they appear in the QGC list):

Enabled
Disabled
Motors / Update
Dynamic ID / Update

Where are the corresponding indices for these values defined?
They are not labeled in QGroundControl which can make things confusing when documentation switches between using text and index nomenclature.
UAVCAN_ENABLE gives only a few results in the PX4 source:

github.com/PX4/Firmware/search? … CAN_ENABLE

And it doesn’t seem to appear in libuavcan:

github.com/UAVCAN/libuavcan/sea … CAN_ENABLE

Here it says that “Motors / Update” corresponds to a value of 3:

docs.zubax.com/sapog/using_with … ight_stack

But based on the order in QGC (which of course may not be correlated at all) I would think “Dynamic ID / Update” would have a value of 3.
However “Dynamic ID” also sounds like it would be the right choice (this is also what it is called in UAVCAN Gui Tool).

If I do dynamically address the boards with the Babel connected to the Pixhawk and 4 Orels and then disconnect the Babel I am still able to control the motors with the Pixhawk (using a joystick for example).
Can I safely use this as a work around until I get the Pixhawk dynamic addressing to work?
I think this means I will have to address the Orels every time the Pixhawk is rebooted.

To get access to CLI on PX4 would I need a DroneCode Probe board (or similar)?
I only have a Babel board at the moment but I could get a DCP board if that would help.
I don’t think it’s the termination plug… it’s a brand new one ordered from Titan Elite.

Thanks,

Derek

4

It could be. I will report it on the PX4 bug tracker, we’ll see if this can be fixed easily. Meanwhile, as a work around, you could use static node ID assignment: just set the parameter “uavcan_node_id” on each ESC to any unique value, e.g. 100, 101, 102, 103. The particular values do not matter, and they are not correlated with the ESC index values.

Here: github.com/PX4/Firmware/blob/ma … .c#L50-L54
As you can see, “Motors/Update” equals 3.

Yes, but you correctly identified a problem with this approach. I recommend you to use static addressing instead.

Either that, or you could use QGC - it is supposed to have a CLI access feature, which I never used though.

5

Another possible reason is your PX4 being out of memory. If you managed to gain access to the CLI, then besides the command I asked you to run above, please also execute “free” - it’ll show the current memory usage.

Libuavcan is a feature-rich library, and its memory footprint is correspondingly large. PX4, however, historically had issues with available memory reserves being too low, which we fought with in the past, but they could reappear as new features are added into the firmware, increasing its memory usage.

6

Thanks Pavel,

For static addressing, what should UAVCAN_ENABLE be set to in QGC?

Derek

7

Hi Pavel,

I am using a quadrotor X configuration…
So counterclockwise from the forward flight direction the rotors are 0 (CCW), 3 (CW), 1 (CCW), and 2 (CW).
This is also the order of my UAVCAN connection chain, rotor 2 is terminated.
I am using a 15 cm cable to connect Pixhawk to the first ESC and 3 50 cm cables to connect the other 3 ESCs (cables from Titan Elite).
I have been using QGC in manual flight mode.

With the babel board I have statically set the uavcan_node_id to correspond to the esc_index (and light_index):

uavcan_node_id, esc_index, light_index
100, 0, 0
101, 1, 1
102, 2, 2
103, 3, 3

I am able to control each motor with UAVCAN Gui Tool using either the ESC Panel or the Interactive Console and the rotation directions are correct.

In QGC if I arm and takeoff I get the message “Set Mode Command Temporarily Rejected” (presumably because I am inside and have no GPS).
Nonetheless I have partial control of the motors with a joystick (Logitech F310) configured via QGC. (This does seem a bit strange).

I first gave the joystick throttle an impulse to the maximum value and released it. 3 of the 4 motors spun at constant RPM before stopping (presumably because the joystick input has timed out).
This works without the Babel so the static addressing seems to have worked.
However the 4th motor (ESC 2) either chirped/stalled or did not turn on.
After re-calibrating the joystick, ESC 2 did turn on but then holding full throttle for some time and releasing it would cause it to stop.
Playing with the roll and pitch controls would also result in different ESCs stalling or turning off completely.
So it seems I am having some problems with motors stalling and shutting off.
Are there some ESC parameters I should adjust?
Is there anything else I should try?
I tried switching out ESC 2 with a different board but that didn’t help.

I also tried taking it outside so that GPS was working.
When I try to take off all motors chirp/stall and do not reach a constant RPM.
Applying full throttle would cause only one motor to spin at constant RPM.

Do I need to worry about cable length? At places the cables are very close to the power lines, but since CAN is differential hopefully this isn’t a problem.

Setting UAVCAN_ENABLE to “Enabled” or “Motors/Update” seems to work the same in the static addressing case. Is one preferred?
In QGC I am using the airframe “F450-sized quadrotor with CAN”.

8

As I understood from your description, since you’re able to control the motors from the UAVCAN GUI Tool, the ESC themselves are working well, there is no need to change any parameters. Neither do you need to worry about cable length - these lengths are not sufficient to cause any problems. To be extra sure, you can use the Get Transport Stats feature in the UAVCAN GUI Tool (in the node properties window) to make sure that the number of CAN errors is not growing significantly while the system is operating (I’m pretty sure everything will be OK in this regard). Concerning the motors turning off, this is likely caused by the mixer. While the UAV is not in the air, the mixer will be likely issuing significantly different setpoints to motors due to saturation of the PID controllers, so some motors will be randomly slowing down (to the point of stopping), some will be accelerating. You can instruct PX4 to never stop the motors while the system is armed by setting the parameter UAVCAN_ESC_IDLT to 1.

As to why the motors were not spinning up in normal mode, I am not sure. If you had PX4 log files, that would likely help to investigate the reason. At any rate, as I said above, if you’re able to operate the ESCs via the GUI tool, the problem likely resides on the PX4 side.

9

[quote=“dbarge”]
Setting UAVCAN_ENABLE to “Enabled” or “Motors/Update” seems to work the same in the static addressing case. Is one preferred?
In QGC I am using the airframe “F450-sized quadrotor with CAN”.[/quote]

If your bus is fully static, plain “Enabled” is recommended, because it uses less RAM.

10

Hi Pavel,

I do not see UAVCAN_ESC_IDLT in QGroundControl (Stable_V3.0).
I updated the PX4 firmware a few days ago with QGC… I think it is v1.4.4.
The only UAVCAN parameters available in QGC are:

UAVCAN_BITRATE 1000000
UAVCAN_ENABLE Enabled
UAVCAN_NODE_ID 1

I’m not sure I understand the issue with the saturation of the PID controllers, can you explain this further?
What I would expect is that if the quadrotor is outside with GPS and I go through the takeoff procedure, all 4 motors (without blades) should spin up to about the same RPM.
Then, I would like to see that the joystick controls the rotors in a sensible way (throttle, pitch, roll, etc).
This would make me feel better about flying without crashing the first time :slight_smile:

With the Pixhawk and Babel connected, I do notice some transport errors:

After resetting Node 100 I see this after a while:

transfers_tx: 158
transfers_rx: 10174
transfer_errors: 0
can_iface_stats:

frames_tx: 378
frames_rx: 21616
errors: 0
  • frames_tx: 80
    frames_rx: 0
    errors: 319343

Some time later I see this:

transfers_tx: 253
transfers_rx: 16405
transfer_errors: 0
can_iface_stats:

frames_tx: 574
frames_rx: 34828
errors: 0
  • frames_tx: 128
    frames_rx: 0
    errors: 514561

Nodes 100, 101, 102 all have 0 errors for the first error counter and many errors for the second error counter.
Node 103 has errors for the first error counter but no errors for the second error counter (it’s the other way around):

transfers_tx: 1548
transfers_rx: 100210
transfer_errors: 0
can_iface_stats:

frames_tx: 782
frames_rx: 0
errors: 3277039
  • frames_tx: 3458
    frames_rx: 212905
    errors: 0

Is this a problem?

What is the difference between the first and second error counts? (Are these CAN1 & CAN2? All 4 of my ESCs are on CAN1)

Thanks,

Derek

11

Hi Pavel,

What is the path of the logs (on the micro SD card I presume) that should I send?

Thanks,

Dere

12

Hi Pavel,

FYI this is the kind of thing I am seeing:

youtube.com/watch?v=hjhVE7Fq5FM

This is in manual mode using a Logitech F310 joystick with COM_RC_IN_MODE “Joystick/NO RC Checks”.

Nothing was saved to the log folder on the SD card for some reason.
I have enabled SDLOG_EXT and tried with SDLOG_RATE -1 and 1.
There are some files in the SD root “msgs_*.txt” that I could send if this would be helpful.

Derek

13

Try looking for it in the complete parameter list, it should be there. Here’s the link to master: github.com/PX4/Firmware/blob/ma … rams.c#L80

The output of a PID controller is a sum of 3 components: function of proportional error, i.e. how much the desired system state is different from the real state; function of the rate of change of the error, i.e. how fast the error is changing; and the function of the error accumulated over time. These components are named Proportional, Derivative, and Integral, respectively. When a PID controller is continuously exposed to circumstances where there is some persistent error which it can’t correct, the integral component will be growing until it reaches the limit. Once the limit is reached, the PID controller is said to be saturated.

In your case, this situation manifests itself as follows: some motors are slowly accelerating, some are slowly slowing down, until those that were accelerating reach some (seemingly arbitrary) upper limit, and those that were decelerating either stop completely or reach some (arbitrary) lower limit.

This is normal behavior of the control system and there is no problem in it.

There is no reason for them to spin to the same RPM, unless your UAV is perfectly leveled.

Nodes 100, 101, 102 are connected via CAN1 (which is right), and node 103 is connected via CAN2 (which is wrong and it’s better to fix it, although it won’t cause any real problems in your setup).

Yes, the first set of parameters is for CAN1, the second one is for CAN2. The error counters are growing on the unused interfaces because the controller freaks out that it can’t access the bus, this is fine.

It would be best if you just compressed the entire SD card and sent the archive to me. If you’re not comfortable about sharing the logs here (the forum is public), feel free to email them to me.

14

Thanks Pavel,

In response to a few issues you commented on previously:

  • One of the ESC’s was in fact on CAN2 and not CAN1, I have since fixed this.
  • UAVCAN_ESC_IDLT is in PX4 master but not in the latest Tag v1.4.4… I will try this soon.
  • The problems I had with logs were due to a bad SD card that came with the Pixhawk… I will send you those soon.

I also now have MAVProxy setup between QGC and Pixhawk.
This is really useful from the command line but I haven’t got “MAVExplorer graph” doesn’t work with the log files just yet.

15

Everything is working well after setting UAVCAN_ESC_IDLT to 1.

Thanks!