CANbus for Ardupilot with UAVCAN and UC4H

@olliw42 OK I reduced the frame rate to 50 Hz , this is how:
Enter configuration mode by the command:
42 57 02 00 00 00 01 02

Data output cycle 42 57 02 00 EE FF 00 07
EE FF: setting of output cycle (ms) it must be the integral multiple of 10ms
Byte4-5 EE FF double byte parameter, EE is low 8 bit; FF is high 8 bits
so… I guess 20 msec is 14 00
42 57 02 00 14 00 00 07

Exit configuration mode by the command:
42 57 02 00 00 00 00 02

Now I see data more steadily, now you need to update BetaCopter as the TFMINI driver has been fixed no so long ago, and the error pattern I see was prior to the fix.

@olliw42 have an Issue here, don’t know where to report

The notify node does not cold start.
I have to get into GUI and initiate a RESTART in order to get the display started and showing data

Release: uc4h-notify-v009-4bl-jd.bin

many thx for the testing and the update on the TFMini

I do have now a TFMini myself. I reduced the timeout in the UC4H node somewhat, and I do get clean packets all time, with the TFMini in the default mode (hex output, 100 Hz). I have also flight tested it and I don’t see indication of any unsteady data flow or any error pattern.

With the “old” timeout some of the UAVCAN tunnel packets are indeed weirdly packed, 100Hz and 10ms just don’t fit well, as I suspected, but from looking at the ArduPilot code I would have thought it should just take it (it’s a really simple parser). I guess I should test myself to possibly see what issues you are talking about. With the changed timeout I can’t see any issues, at least there is nothing which triggers me. Maybe you would have a graph of the issues.

I haven’t noticed that the TFMini/RangeFinder driver has been fixed, thx for mentioning.

EDIT: Are you sure the Benewake driver has been changed lately? I just looked at master and what I have in BetaCopter and I couldn’t see a difference…

What does this mean: “the error pattern I see was prior to the fix”? Are you saying that you saw the same error pattern which you saw with the tunnel also before in AC3.6?

display: well, these OLed dispalys are a bit of a thing, I’m afraid, as much as I know there are many similar looking but in fact different kinds of them … I have three of these: https://www.aliexpress.com/item/Free-shipping-Yellow-blue-double-color-128X64-OLED-LCD-LED-Display-Module-For-Arduino-0-96/32233342471.html?spm=a2g0s.9042311.0.0.77664c4d2A0bsh (not from the same seller, bought at different times, all three work) . Unfortunately not a guarantee for anything.

as a first test, could you flash the non-bootloader firmware and see if anything changes?
also, as always, good power supply, USB often isn’t sufficient.

When you write:

I reduced the timeout in the UC4H node somewhat, and I do get clean packets all time, with the TFMini in the default mode (hex output, 100 Hz)

Where do I set this ?

That’s exactly the model I have, I supply with a dedicated 2 Amps supply

Please note that I had to install a capacitor on the serial node as the 2 x TFMINI could not start together because of the power on surge.

All code are uploaded from the GUI as I am testing this ‘‘preferred’’ method

rangefinder: you can’t set this, I did it in the code to see if it would help, and it did. As said before, when I did the tunnel I was thinking that it never would be used for high rate data :D. The timeout mechanism has some weakness, so I’m going to do a quite different logic for the sending. Which will be more robust and not need user interference, I hope. (it’s WIP, you kind of just came too early :wink: )

display: hm … I’m a bit clueless what the issue could be, I guess I would test by removing. E.g., would it work without any TFmini? Or with the OLed powered from the Pix, and the TF’s from the external BEC. I mean, is there any minimal configuration which would work.
Yeah, uploading is the preferred method, but for a test pl flash the non-bootloader version.

EDIT: if it’s possible to find a minimal working configuration for the OLed, I quess you’ll start to understand why there is this 5Vext stuff on the gen.nodes :wink:

@olli
Concerning the Oled Display, it is really a startup delay issue.
I loaded on the bluepill and I need to hit the reset in order to get the display started.

So you need to allow the display to boot before starting the I2C bus, I guess a 20-50 msec delay would be OK

@ppoirier
hm … I generally find it weird then nominally identical setups perform different … anyway, let’s test it, so here a test version which has a parameter StartupDelay, and it is the very first thing which is called: uc4h-notify-4pp-startupdelay.zip (62.6 KB)

EDIT: btw, you now really should get yourself some WS2812B … you could attach one to the notify node and then would also have the indicator led :wink:

I just put 10 msec and it is starting each and every times :wink:

Thanks

GREAT!
would you mind to also quickly give this a test: uc4h-notify-4pp2-startupdelay.zip (62.6 KB)
I’ve reshuffled things a bit here + some fixed delay

There is no delay parameter in new code, so I don have the display starting

this was the purpose of it to remove the parameter b ut to keep the function
but your saying it is NOT starting now ??? the delay before the i2c starts is now more than 20 ms !

@olliw42 trust me man, I test your loads and I report :wink:
I reloaded the delay version and tested different timing
5 ms too short it is not getting initialized
10 ms and more is OK

I totally trust you :slight_smile:
the statement “There is no delay parameter in new code, so I don have the display starting” is however somewhat ambiguous since the 4pp2 has even 20ms !
I’m confused at the result
I suspect there is an additional factor in the game, not just a 10 ms delay

I will double check tomorrow
Good nite Olli

I have no doubt that you’ll get the same result again, my guts feeling says there is something missing … so, sleeping is a good idea :smiley:
good night too

… argh, stupid me, I’ve forgotten to uncomment a line … the 10 ms correspond to 50 ms :cold_face:

ok, let’s see if I could get it right now :smiley:
uc4h-notify-4pp3-startupdelay.zip (62.5 KB)

Yep , it is starting correctly all the time, could you make ad bootloader type so I can test the whole sequence ?

Are you uploading them on http://wiki.jdrones.com/can/firmwares or someone else is doing it ?

Yep , it is starting correctly all the time

great! Thx a lot, this was useful :slight_smile:

could you make ad bootloader type so I can test the whole sequence ?

yep: https://github.com/olliw42/uavcan4hobbyists

Are you uploading them on http://wiki.jdrones.com/can/firmwares or someone else is doing it ?

you’re kidding me, right :smiley: :joy: :heart_eyes: