UAVCAN for Hobbiests

[olliw42]

Hey,

I’m on a little DIY project which for myself I called UAVCAN for hobbyists (LOL), which was stale for a long while but thanks to the recent release of LibCanard v0.1 (thx Pavel!) made progress now. I have two basic nodes communicating and built&written a simple DIY SLCAN adapter, to diagnose with Pavel’s UAVCAN GUI Tool.

My driving goal was that I got tired of this dammed I2C, which is (at least for hobbyiests ;)) unavoidable with an external mag. So, I though, build a UAVCAN-to-i2c adapter and connect that to the mag, so that the long wires would be CAN now.

And that’s what I want to do now, but am not sure about some starting points. Maybe you would have ideas to these questions:

Q1: UAVCAN is said to be available in ArduCopter since a long while. However, with AC3.4 I found it extremely difficult to see how it is working, since there it is so deeply hidden in the PX4 layer (well, fact is, I did not see how it is working :)). I do know about the current in-tree efforts, and that UAVCAN is very actively worked on, but I feel unable to judge about it’s current state. So, question: I want to build a UAVCAN magnetometer node, which AC firmware should I use to test if it is working?

Q2: In the current List of standard data types the only data type I could find with some relation to magnetic fields is uavcan.equipment.ahrs.MagneticFieldStrength. However, it is totally unclear to me if that is what is used by AC, and if so, what data it is supposed to send. I mean, in my simple-minded world a UAVCAN magnetometer node would simply, at some rate, broadcast the three raw magnetic field values (converted to G), exactly as the sensor measures them. No calibration, no covariance, no whatever. So questions: Is this the correct data type the magnetometer node should send? What values should be emitted? What should be the rate? Which other data types must be supported for proper functioning? etc. etc.

Any comments on these matters would be highly appreciated.

Thx, and cheers, Olli

EDIT: HAHA … I’ve just now seen that just yesterday there had been huge number of commits, and most of them UAVCAN related. If one is not up to date up to the last second before asking a question … LOL. Anyway, from the commit “AP_UAVCAN: library for support of UAVCAN protocol”, am I right to conclude
Q1: latest master
Q2: yes, uavcan.equipment.ahrs.MagneticFieldStrength; yes, only three field values in G
?

[OXINARF (Francisco Ferreira)]

Hi Olli,

Well, yes. If you want to develop something for the future, going with master starting yesterday is your best bet - it is also way easier to follow the code paths than it was with it buried under PX4Firmware.

Regarding your second question, yes too, that is the message current UAVCAN compasses use, so it is the one ArduPilot expects and reads: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_UAVCAN/AP_UAVCAN.cpp#L177-L194

[olliw42]

many thx Francisco, for the quick reply.

Since you seem to be so deeply involved with AP’s UAVCAN layer, maybe I could ask these shorties in addition:
at what rate should my mag-node emit?
can the mag-node’s id be static, or must the node support dynamic id allocation?
is there anything else the node should or must do, or I need to consider, beyond NodeStatus, GetNodeInfo, and MagneticFieldStrength?

Thx for all this,
Olli

[OXINARF (Francisco Ferreira)]

I was deeply involved with reviewing the ArduPilot side of it, yes. But I don’t know that much about UAVCAN and I think those questions are better for @Pavel_Kirienko. Have you tried asking in UAVCAN Gitter?

@olliw42

at what rate should my mag-node emit?

I can answer this one by saying that for a compass to stay healthy in ArduPilot an update is needed with a time interval shorter than 500ms: ardupilot/libraries/AP_Compass/AP_Compass.cpp at master · ArduPilot/ardupilot · GitHub

[Pavel_Kirienko]

Thanks for inviting me here @OXINARF, I am normally out of the loop of the APM affairs so could have missed this topic otherwise.

@olliw42

at what rate should my mag-node emit?

I would recommend 50 Hz or higher, but APM devs could suggest otherwise.

can the mag-node’s id be static, or must the node support dynamic id allocation?

Yes it can be either static or dynamic. Static nodes are difficult to use, since they require the user to manually configure stuff before connecting the node to the bus. I would recommend you to support the dynamic node ID allocation feature in your node.

is there anything else the node should or must do, or I need to consider, beyond NodeStatus, GetNodeInfo, and MagneticFieldStrength?

No.

[olliw42]

thx Francisco!

hey Pavel,
haha, that’s now kind of funny … not that we didn’t had been in touch recently LOL. I was assuming I would be better placed here with these questions, and was kind of not expecting that they would lead back.
So I’ll start with static id , once this works do dynamic id, and do all that at 50Hz. Should be really easy from here on. Let’s see how soon I can report on a cheap DIY uavcan magnetometer node.
btw, I also saw the variable field thing now, I actually did count the numbers to understand the demo.c code, but obviously counted wrong by one byte LOL. So, there is a hidden trick in the code.

THX
Olli

[olliw42]

just as a kind of feedback there this currently stands (the help was not for nothing):

https://www.rcgroups.com/forums/showthread.php?2869828-Uavcan-for-Hobbiests

[olliw42]

hey

I’m trying to make progress and get my pixhawk to communicate per uavcan, but it doesn’t seem to be as easy as I thought

first, I’m actually not sure where I should ask these questions, here or at uavcan google. On the one hand my questions are clearly very ArduCopter related, but on the other hand Pavel isn’t often here. Maybe you could give me an indication.

my hardware: Auav-X2 first generation, slcan adapter and node (UC ID 42) as in the above, the node or the slcan adapter is connected via a SN65HVD230 transceiver to the CAN ports of the AuavX2 (as in uavcan hardware docu).

I first tried it with the AC firmware I had installed on the AuavX2, namely AC 3.4-rc5. It had just one Uavcan parameter, which I’ve set to 1. Not 2, not 3, 1. According to an issue in the git repository that’s appropriate. Nothing happened. On the AuavX2’s CanH&CanL pins I see about 2V, but absolutely no action.

I then downloaded the latest V3.6-dev, ArduCopter-v2.px4 from APR 15 00:01 (I also have the latest MP). I do see now several more CAN and Uavcan related parameters, which are
BRD_CAN_BITRATE 1000000
BRD_CAN_DEBUG 2
BRD_CAN_ENABLE 1
BRD_CAN_UC_EN 1
BRD_CAN_UC_NODE 10
However, exactly same result, absolutely no action on the AuavX2’s CanH&CanL pins.

In MissionPlanner OptionalHardware Uavcan page, the Uavcan is shown as enabled, but the buttons, e.g. StartEnumeration etc., are disabled.
A 3rd Compass #3 seems to be “detected”, i.e. I see a parameter COMPASS_DEV_ID3 5.368712E+08. It’s value is however independent on whether the node is connected or not.
Also in the MandatoryHardware Compass page, the compass #3 is now checked as ExternallyMounted.
In the FlightData Tunning Window, when I check mx3,my3,mz3, no data is displayed.

I’ve carefully rechecked that my slcan adapter and uc4h node do work properly together, and that I got the wiring correct.

??

Thx, and cheers
Olli

EDIT:
I wonder, is there maybe any dependency which is required for (uav)CAN to be activated which I’m overlooking? E.g., I was thinking it could be the transceiver on the AuavX2; the newer transceivers have a CAN-5V detection&disable safety feature, but on the AuavX2 it is a Max3051 which is essentially identical to the Sn65hvd230, i.e., no such feature. Anyway, I maybe should precise the hardware setup: it’s the AuavX2 with a Gps+external mag connected (uart+i2c), the beeper+saftey switch, powered by USB, nothing else.

[EShamaev]

I would advice Gitter channel https://gitter.im/ArduPilot/CANBUS

From the photo above I could not understood your setup. Can you please draw your schematic on paper to clarify it?
You should be able to see changes on CANL and CANH during boot of AP even the wiring is totally incorrect.

[EShamaev]

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?

[olliw42]

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

[EShamaev]

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

[olliw42]

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

[EShamaev]

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.

[olliw42]

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. 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) …

[Pavel_Kirienko]

@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.

[olliw42]

hey folks

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

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

[Pavel_Kirienko]

@olliw42

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. ??

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.

[olliw42]

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 …

[Pavel_Kirienko]

@olliw42

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 …

Correct.

@olliw42

I couldn’t find very good pictures of your zubax gps 2

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.

@olliw42

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

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.