UAVCAN for Hobbiests

Olli,
Also just noticed from the logs you posted above that the node of your magnetometer is the same as the AP’s node (10).
Please advice if you changed it to a different one for test with AP?

thx for your replies

yes, noted the 10 thing, and changed the node id to 42 (see two posts up)

can’t currently draw a scheme, it’s the above with the “pseudo transceivers” replaced with sn65 transceivers, so:
node = stm32f103 breakout board (this little green board) + magnetometer of a gps unit connected via i2c + sn65 transceiver connected via canrx/tx
slcan adapter = stm32f103 dev board (blue bottom board) + usb ttl adapter at it’s uart + sn65 transceiver at its canrx/tx

I too would expect the AuavX2 to emit at minimum it’s NodeInfo message, and that thus “signal changes” should be seen at it’s can port, independent on whatever else
IMHO that’s the main issue, how to get the AuvX2 to show signals at it’s can pins

But where is the AuavX2 in this scheme?
Can you disconnect everything from it [autopilot] and check the CANL and CANH with oscilloscope?

I’m not sure this is leading to anywhere …
the AuavX2 is obviously connected to the transceivers (I have mentioned that btw)
that’s exactly what I did, and as said, silence (i.e. 2V) on the CAN pins

let me translate the full content of “On the AuavX2’s CanH&CanL pins I see about 2V, but absolutely no action.”:
The AuavX2’s CanH&CanL pins are sniffed with an oscilloscope in any of the configurations possible with 2 additional units, i.e. only AuavX2, node connected via the transceiver to the AuavX2’s CanH&L pins, slcan adapter connector via the transceiver to the AuavX2’s CanH&L pins, node and slcan adapter connected via their transceivers to the AuavX2’s CanH&L pins, and in those cases where the slcan adapter was connected also by the slcan adapter using the Uavcan GUI Tool, where in all cases things were properly terminated, properly powered, properly rebooted and started up, and in all cases I can’t see any action on the CanH&L pins which could be associated to the AuavX2, which for the AuavX2-only case means no signal except a constant 2V.

in short: the CAN pins of the AuavX2 don’t do anything

I reread all the thread from the beginning and have few comments:

  1. I am strongly against “pseudo transceivers” based on diodes. I am very glad you switched to using normal transceivers.

  2. The MCU pinout of AuavX2 regarding CAN is the same as Pixhawk, so I am sure it does try to communicate.

  3. Here are tests of latest master for arduplane:


  4. Here are tests of latest master for arducopter:


I have a strong feel that you have some hardware issues either with AuavX2 or setup in general.

I do not have AuavX2 board unfortunately, but if possible I am asking you to check the debug console and give the info that is there. It might give a clue what is going on.

ok, it is this:

I’ve inspected in more detail the AuavX2 board, I especially looked at the signals on the pins of the Max3051 transceiver (which according to the AUAV_X2_R01.pdf scheme is what it should be), and from the signals on the RXD and TXD pins I concluded that they are in wrong order! A subsequent more alerted peek into the scheme in fact shows exactly this, namely that Can1Tx is connected to RxD and Can1Rx to TxD !!!

As a proof I soldered wires to the Max3051’s RxD and TxD pins (delicate solder job LOL) and connected them via my pseudo transceivers (I do not have enough transceiver modules around) to my slcan adapter and ran the GUI Tool … et voila, I do see now what one expects to see !!!

I must admit there had been once a time there I considered the Auav stuff high quality, but I stopped thinking so a while ago, and this is now really a most dismaying discovery. :-1: If there would be at least an errata sheet.

Anyway, I guess I have to dissolder that transceiver chip and produce some clumsy workaround … good I bought a high-quality board (and in fact two of them) …

@olliw42 The issue has been reported to the PX4 hardware bug tracker. In defense of AUAV I must report that the CAN bus interface on their Pixracer is fully functional, maybe you should switch to that.

hey folks

some progress to report, and some issues, and some questions :smiley:

since the issue with the AuavX2 got identified now, I successfully could connect all three items, the uc4h magnetometer node (configured to Uavcan ID 42), the AuavX2 (which is by default configured to Uavcan ID 10), and the uc4h slcan adapter via the Uavcan bus (ID 127). Things work (mostly) as expected: The uc4h magnetometer is seen correctly in MissionPlanner, and I could calibrate it properly. In the plot below you can see all three magnetometers to nicely track each other. So, this looks G O O D!

Unfortunately, I do not have yet sufficiently many CAN transceivers (they are on order), so I still had to use the pseudo transceiver trick, but I think that’s just a momentary nuisance and not a real issue.

.

Issue:
The calibration never completed when I had all three magnetometers (Compass #1 = external on i2c, #2 = internal, #3 = uc4h magnetometer node), or #1 and #3, checked to be in use. It then would stop with a beep at some 90y-ish percentages, without any report in the gray message field, and no further response. With #1 and #2 marked as unused the calibration worked immediately. The relax level did not had an effect on this.

Questions:

  • DEV_ID: I do not understand this Dev ID field. It is some strange number. I would have thought that it is somehow related to the node which is connected, e.g., that it’s unique ID is in some way used to produce a DEV_ID. Also, it doesn’t matter if the magnetometer node is present or not. This is unlike with the other magnetometers, where the fields adapt to which magnetometers are present (at startup). What is the DEV_ID supposed to be?
  • Orientation: I’ve mounted both compass #1 (external on i2c) and #3 (uc4h node) such that their magnetometer chips are oriented identically, but I had to choose Yaw90 for #3 in order to get it in sync with the other compasses. This is obviously due to the hard-coded “internal” rotation of the data for HMC5883-type compasses. However, it raises the question what the default behavior of a uavcan magnetometer is supposed to be? I would be inclined to also put some hard-coded internal rotation in my code. ??

thx
Olli

Yes, all data exchanged over UAVCAN is supposed to be in the specific coordinate frame documented here Open technology for real-time intravehicular distributed computing and communication based on modern networking standards.

Concerning the APM specific questions, I hope either Eugene or someone else will respond.

thx for this very quick response

I’m not sure it answers my question though … I mean, the specification doesn’t tell anything about the relation of the chip to the output … if I would put all that into a box and print an x arrow on it then I nevertheless could place the chip inside the box as weirdly as I wanted, as long as I do the code such that it produces output consistent with the arrow on the box … IMHO that’s exactly the situation with the GPS+magnetometer modules, where following a “3DR standard” AP does an internal orientation correction, for the sole convenience of the user … that’s why I would be inclined to also do that internally, but I also wouldn’t want to break with established habits, if there are any

I couldn’t find very good pictures of your zubax gps 2, but it looks to me that here the chip’s orientation in relation to the printed arrow is also the “3DR standard”, which makes me guessing that you do such an internal conversion … for the convenience of the user … you do, right?

the alternative of doing it within the node would be that AP decides to do that internally, exactly as it does it for the i2c … so, there are several approaches … and the intention of my question was to see if there are already some established “standards” for uavcan magnetometer nodes, or if it’s now time to agree on one, or to let anyone do what they want, or you extend your specification to say that for magnetometer chips the “3DR standard” should apply, or …
:slight_smile:

Correct.

Right here: https://docs.zubax.com/zubax_gnss_2. Pay attention to the bottom right corner of the drawing.

Yes, Zubax GNSS 2 performs coordinate conversions internally.

I2C is a poor reference. The autopilot should not and must not care about how exactly the sensors are oriented. There is a standard coordinate frame defined by the bus specifications, and all nodes must agree on it. A relevant anecdote: Zubax GNSS v2.1 and v2.2 use different compass IC, which use different axis conventions, but this implementation detail is hidden from data consumers, and both versions always output consistent orientation data.

ok, so it’s me who has to define - and tell to the user - how the “x arrow” is related to the chip marking … that’s cool
so I’ll choose the “3DR convention” and will do an internal correction

many thx for your detailed answer

will be interesting to hear how this DEV_ID is fabricated …

btw, the 128 bit unique ID I’ve constructed from the STM32’s 96bit unique device id (the missing higher bits are duplicates of lower bits) … is that an acceptable procedure, or what would be recommended?

Any unique ID is acceptable as long as it is globally unique, so yes.

haha … well, you know, from within my little world it’s really hard to claim that a number is globally unique, and I actually doubt that the STM32 ids are disjunct from other “globally unique” number sets one could draw a number from … but I’m happy to hear that it’s considered sufficiently unique :slight_smile:

next set of questions/points

Following the demo.c I’ve implemented the dynamic id allocation feature, and with the GUI Tool it just works nicely. However, I can’t get the AuavX2 to perform the dynamic ID allocation. Yes, I have set BRD_CAN_ENABLE = 2, following the Zubax GPS Tutorial, and an (older) comment in an issue. I note though that this is not in the docu. When, while having the AuavX2 and the node running, I start the GUI Tool and let it do the ID allocation, then things also work, i.e. the node is getting an ID, and the AuavX2 finds and uses it.
Is BRD_CAN_ENABLE = 2 working in master?
What might I do wrong?

I’d like to bring up again the DEV_ID question raised few posts in the above, in case it got buried by the other posts :). I find it quite relevant, from a practical perspective.

What I don’t like with AP and it’s current Uavcan support is that it is kind of impossible to see the status of the node, e.g. if it has been detected, what ID it is, etc… I think a page with info on all sensors on it, such as it is found for other flight controllers, would be appreciated not only be me.

:slight_smile:
Cheers, Olli

I suspect that the new CAN stack on APM does not yet support dynamic node ID allocation. @EShamaev is it true? Do you know, perchance, when this feature will be supported? Thanks!

I would be totally happy with that, IMHO that’s not the most pressing feature … (IMHO the whole sensor discovery and health management (all buses) is much more pressing, to me the logic looks quite screwed up)

it would be good to know though
I’m working on parameters in the uc4h mag node, so its id can anyhow be configured

brief update:

got some more transceivers today, and could now equip all three nodes, the AuavX2, the uc4h mag node, and the uc4h slcan adapter with transceivers, and things work perfectly as they should.

So, the issue was unequivocally a hardware bug in the AuavX2, as EShamaev suspected.

Thx a lot for the help.

The calibration issue and DEV_ID thing are still dangling around, but they don’t prevent operation. The node supports dynamic id allocation, supports all the parameter services and in fact is configurable, and of course emits the mag field message with proper orientation and scaling. I’ve also designed pcb boards for the mag node and the slcan adapter, which will come however only in few weeks. So, I think I’m quite close to an actual test … time to get the winter dust off my copter :slight_smile:

cheers, Olli

Dynamic ID allocation is not supported, but will be right after multiple CAN interfaces are finished. I expect it to be few weeks.
As for the Dev ID field this work is now in progress and will be based on UAVCAN ID and type of device.

dynamic ID: fantastic
albeit no “pressure” from my side, I myself am happy also with fixed ID’s
thx for the clarification

Dev_ID: fantastic
you certainly know the unique id thing, I would think that this maybe could also be digested into the dev_id in some way … as much as I understand (and which would match my bill) the Dev_Id is also used to determine if a calibration is valid for the attached device (although this seems to be broken, but there is such a comment in the code) … so it would also have to be node specific to some extend

mag calibration issue: comments on that ?