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 ?
As for dynamic ID I must say that personally I am strongly against this feature.
As for Dev_ID, you are absolutely right, it is used to distinguish calibration.
Dev_ID:
ok
so, I herewith officially report that this feature is then broken !!
(and I consider that a very serious issue, as it affects safety of the vehicle). I can provide screenshots, if needed, but I think it is trivial to reproduce for anyone: reset all magcal values, do mag cal with only an internal mag available, connect external mag, redo mag cal, disconnect external mag, and check mag cal values …
mag calibration issues (reported some posts up): comments on that? 
Working on this. Major update with several CAN interfaces is coming and this will also be solved in it.
hey Folks,
just a kind of a status report: The project made some great progress, but stalled again.
I’ve extended the uc4h node to also handle gps. I.e. you can connect it now to a standard gps+magnetometer unit, and get both data delivered via UAVCAN. Also, the parameters (and other stuff) became useful.
The UAVCAN GUI Tool seems to be quite happy with my node and slcan adapter. On an oszi signals look good, also the debug outputs I can activate on an additional uart port of the node. So I considered getting “serious” and doing the next steps towards an actual flight.
I thus flashed the flight controller (AUAV-X2 1st batch) with AP3.6-dev (5.5.), fetched the latest MP, and started setting up the flight controller for a real flight. In the course of that I found that the ardupilot node is extremely “unstable”. I thus tried AP3.4.6, presuming this to be a more stable version. Behavior is more reliable, but often the pixhawk node will disappear after ca 10 secs.
I do have some confidence in, especially, my SLCAN adapter. It’s such as simple hardware and code thing that it’s not obvious how it could make the ardupilot/pixhawk node to disappear, while being happy with the uc4h node. On the other hand, one rightfully could argue that my earlier issues was a hardware issue, so one could suspect that here too.
Anyway. The situation is weird and I can’t figure it out as it seems. Whatever the reasons are, I’ve given up on that project. Was IMHO a nice idea, but UAVCAN and AP is not DIY, at least currently.
I’d like to seriously thank EShamaev and Pavel, especially Pavel. Keep up your great work.
Cheers,
Olli
Sorry you decided to give up, anyway I was unable to use my Zubax gps and compass with AC 3,5.5 while with 3.5.4 it was initialise correctly.
I am very sorry to hear that you gave up.
As for node disappeared, I advise to check everything one more time (hardware and software) and also to use latest master version.
I have now almost 5 hours of flight time with Zubax and also 6 UAVCAN controlled servos (8 nodes total in network) and did not notice any hangup or node disappear.
Folks, this is a long complicated thread, so apologies for finding an answer to my question in it if it is there… This issue seems to be related to the one I’m having and about which I have even filed a bug (https://github.com/ArduPilot/ardupilot/issues/6400).
It’s quite simple – the Zubax V2 GPS used to work with ArduPlane on Pixhawk until February-March or so. To get it to work, I set BRD_CAN_ENABLE to 2, GPS_TYPE to 9, and the GPS ran just fine. However, since at least ArduPlane 3.8 beta 5 it hasn’t been working with the above parameters anymore.
How do I get to work again?
Thanks,
Andrey
akolobov , not sure is the right place to ask, but I notice too that with latest Arducopter beta 3.5 Zubax do not work anymore.
It would be nice if the manufacturer of Zubax will find a solution.
@akolobov @lucamax The new CAN stack in the APM does not support dynamic node ID allocation yet, so you will need to configure Zubax GNSS to use a static node ID. Any value from 2 to 125 will work fine. The configuration parameter for node ID is uavcan.node_id, and the commands to set it are as follows:
cfg set uavcan.node_id 42
cfg save
Paging @EShamaev
Thanks @Pavel_Kirienko, could you clarify a bit though: where should I run these commands? From Mission Planner somehow?
Thanks @Pavel_Kirienko.
akolobov, you must use the Command-line interface, as explain here https://docs.zubax.com/zubax_gnss_2
I suggest to use Putty , as explain here https://docs.zubax.com/usb
Thanks to you Pavel for such a great product as the Zubax GPS , IMO the best GPS / compass device in the market.
1 Like
Super, the GPS is alive again! Thanks people! And yeah, I totally share @lucamax’s sentiment regarding this unit.
Hey
if one gets stuck with a project, it’s sometimes not a bad idea to let it rest for a while. So it is with this project. I also regained interest because I could free quite some substantial resources in the STorM32 gimbal controller, which gives it now the muscles to handle UAVCAN, and because I have seen that EShamaev’s big PR is getting closer to be merged (and in fact had been merged now, congrats!).
Earlier I gave up, because of all sorts of “instabilities”. I can’t say for sure what THE solutions was, but I believe (strongly) that my previous issues were because I was using the SN65HVD230 CAN transceivers. These are so-called 3.3V transceivers, and on the osci I just saw “ugly” CAN signals. So, I watched out for alternatives, and I finally settled for the TJA1051 (which I really like a lot). These give signals as seen in the textbook. Moreover, what I found was that it is sufficient to have only one TJA in the system, and the signals would look good (i.e. even if the other transceivers in the line are SN65HVD230). So, I equipped my AUAV-X2 with a TJA instead of a SN65, and since when I do not appear to have any of the previous issues. I further looked on the web, and I noticed that the pixracer is also equipped with a TJA (and I think also PH2), which might explain why others might not have seen issues like me, even then using SN65-equipped nodes (such as the Zubax gps). I also noted that the TJA is a ■■■■■■■■■ recommendation (but not the SN65). I perfectly understand that Pavel does NOT support that conclusion, that the SN65HVD23x can cause issues, and I accept that. However, the above is a truthful report of what I did and saw, whatever the correct conclusion is.
Although not of much importance, I also niced up my hardware, i.e. designed pcb’s for the uc4h-slcan-adapter and the uc4h-node bridge, pictures below. All bench tests ran very well. So, I think I can start again with out-door test.
Chears, Olli
Node:
SLCAN-adapter:
Bench test setup:
1 Like
could spend evening for first out-door tests … all went very well … no issues
I guess, once I understand the dual gps thing, I can prepare for real flight
well, maybe one “issue” … the main gps (i.e. the one connected to uart, which is my “normal” gps) repeatedly took much longer to fix and also scatters much more than what I had become used to (the green curve I would consider typical) not sure why that is, maybe I have both gps too close? Will have to see.
(I’m using ac3.5-rc9, btw)(and the main gps is a drotek m8)(and blending was off)
1 Like
next step forward
STorM32 goes UAVCAN
Sadly, to the best of my knowledge, ArduPilot doesn’t yet support any gimbal related UAVCAN messages, so not much I can do further at the moment. 
Noted, and forwarded 
What would make sense to send and receive to a gimbal ?