Uavcan: More issues

[olliw42]

did some further tests of the UAVCAN implementation in AC3.6-dev

I can’t say I’m pleased with what I see

config: AUAV-X2 and a pixracer, spektrum satellite connected, and an uc4h SLCAN adapter via uavcan, AC3.6-dev of today

procedure: power up flight controller, press safetey switch, disarm with transmitter stick, move transmitter stick, all on the bench

the findings have been essentially identical for both the AUAV-X2 and pixracer, so the below holds for both even though it’s shown just for one

finding 1:
settings essentially as default, except of course with CAN_P1_DRIVER = 1 to enable uavcan
during startup only StatusNodes are seen (= OK)
after pressing the saftey switch the equipment.actuator.ArrayCommand and equipment.esc.RawCommand appear, with a relatively low rate (= OK)
after disarming the rate of the Array and Esc commands increase
with no stick movement (e.g. Throttle near middle) it settles at ca. 400 f/s, which corresponds to ca. 50 Hz update rate (= looks OK)
however, when moving e.g. the throttle and yaw stick, the update rate goes wild, reaching high’s as large as above 2500 f/s in few cases, but almost always way above 400 f/s !!!
this does not look OK to me
(2000 f/s would be an update every 4 ms, and why should the rate fluctuate that wildly???)

comment: I have seen this not only today, but see this for while, so it should be “real” and easy to reproduce

finding 2:
since I was actually only interested in the equipment.actuator.ArrayCommand, I disabled the esc command by setting
CAN_D1_UC_ESC_BM = 0
but left
CAN_D1_UC_SRV_BM = 255
during startup only StatusNode are seen (= OK)
after pressing the saftey switch the equipment.actuator.ArrayCommand appears (=OK)
but it immediately appears at a rate of 2000 f/s (= 400 Hz) !!!
note the parameter SERVO_RATE = 50 (which according to the docs is 50 Hz)

summary:
there is obviously a serious issue with keeping the rate of emission, the fluctuations should not be as wild as they are IMHO, and there shouldn’t be such a cross correlation between actuator and esc

adding in the issues with the uavcan gps handling I can’t help than to conclude that the uavcan implementation is far from anything usable, I guess I find it inappropriate that there are a couple of PRs for adding new nodes even though not even the basics work.

It seems that with the uavcan-for-hobbyists project I jumped into the uavcan game months (years?) to soon. My mistake.

Cheers, Olli

btw, if any one doubts the uc4h SLCAN adapter, which is valid to do, I can produce experimental evidence that it easily handles a continuous stream of 1800 frames/s (that’s that fast that the UavcanGUI bogs down significantly)

[liang-tang]

i just use uavcan to transmit battery information。

[Pavel_Kirienko]

Thanks for the analysis, @olliw42. I hope @EShamaev will respond once he gets back from his vacation.

Meanwhile, if you could reproduce the problem with another CAN adapter or an oscilloscope for the sake of independent verification, that would be helpful. Many CAN adapters begin to seriously misbehave when exposed to such a high CAN traffic.

You said that your CAN adapter could handle at least 1800 fps, but the bus load generated during this experiment is greater than that, so are you sure that your adapter can be trusted? If you have a Zubax Babel around, you could perhaps try it, because it has been tested at the rates up to 5000 fps.

[olliw42]

Hey Pavel

as said, this is a valid objection

I do not have any other adapter such as Babel. I’m working in a bootstrapping (Münchausen) mode here, I don’t want to spend such money.

I started to gain some confidence in my adapter though. I think a strong argument is if a message is received and displayed correctly in the UavcanGUI. Each frame is crc protected by CAN, and this are multi-frames, which are additionally crc-ed by the uavcan protocol. I consider it unlikely that a valid message comes through if anything inbetween would misbehave.

(off-topic: it would be great if in the Bus Monitor panel, also the number of errors would be displayed, and invalid messages, with e.g. incorrect crc, being marked by a “red flag” (the RX could be changed in color))

Most importantly, if the above is real, then anyone should be able to reproduce it, and vice versa, if no one except me is seeing this, it’s not real.

So, I think there should be an independent test.

Thx, and cheers, Olli

PS: off-topic: Thx for your comment to the YT video. It’s not like that I wasn’t trying to be constructive: https://discuss.ardupilot.org/t/uavcan-gimbal-xyz

[EShamaev]

I will look deeply into that at the end of the week, but for copter 400hz update is perfectly normal. More to that, update occurs when value change, so it might fluctuate a lot.
And I did not understand your note about “GPS handling” issues.

[olliw42]

ähm … SERVO_RATE is set to 50 … are you implying that this is not taken into account?

I would find it OK to have an update rate of 400 Hz for the ESC command (which would take up already 10% or so of the available CAN bandwidth, but ok, there is probably no need for other high-rate messages)

I’m surprised though one also wants to update the servo info at 400 Hz …

I could imagine that the argument was that it also carries the thr/yaw/pitch/roll info, but for high-rate data I would not consider it optimal to send out the same basic info in different formats … I rather would define that whoever wants high-rate info should take the ESC and not the actuator message

Do you have a log of the ESC message rate during a flight?

gps: https://discuss.ardupilot.org/t/ac3-6-dev-dual-gps-issues

cheers, Olli

[EShamaev]

I know only few copters in world that have pitch controlled by servo and I honestly did not run servo tests on copter branch of firmware.
Will investigate into that behavior in nearest time.

[olliw42]

@EShamaev

More to that, update occurs when value change, so it might fluctuate a lot.

I tried to find that reflected in the code, but couldn’t.
As much as I can see the job is done in do_cyclic() in AP_UAVCAN.cpp and _send_outputs() in RCOutput.cpp. I see that the _rco_conf[ch].active is set true at each write and cleared after each broadcast, but I don’t see a check for changed value.

Could you please indicate to me the location in the code there this is done?