UAVCAN for Hobbiests

[olliw42]

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

[lucamax]

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.

[EShamaev]

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.

[akolobov (Andrey Kolobov)]

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

[lucamax]

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.

[Pavel_Kirienko]

@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

[akolobov (Andrey Kolobov)]

Thanks @Pavel_Kirienko, could you clarify a bit though: where should I run these commands? From Mission Planner somehow?

[lucamax]

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

[Pavel_Kirienko]

@akolobov What @lucamax has helpfully suggested is entirely correct. Thanks, @lucamax!

[lucamax]

Thanks to you Pavel for such a great product as the Zubax GPS , IMO the best GPS / compass device in the market.

[akolobov (Andrey Kolobov)]

Super, the GPS is alive again! Thanks people! And yeah, I totally share @lucamax’s sentiment regarding this unit.

[olliw42]

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:

[olliw42]

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)

[olliw42]

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.

[LuisVale (Luís Vale Gonçalves)]

Noted, and forwarded

What would make sense to send and receive to a gimbal ?

[olliw42]

well, that’s a good question

There are some uavcan gimbal messages in the standard DSDL, http://uavcan.org/Specification/7._List_of_standard_data_types/#uavcanequipmentcamera_gimbal, but they don’t look very useful to me. Not sure how they made it to a standard.

I have no suggestions, and am hesitant to make some. I just hope that the uavcan message set is going to be a bit more - don’t know how to say it properly - farsighted?

I think AP supports the actuator messages. I don’t yet understand them but I guess they carry the RC inputs as send by the transmitter, so, as a first crude “do something”, I consider misusing them for controlling the gimbal orientation. But that’s certainly not for permanent.

[Pavel_Kirienko]

@olliw42 you are right, the current gimbal control messages have some deficiencies. They were defined far before the current specification was released, and they don’t even make use of the more advanced DSDL features such as unions, which were added at a later stage of development. Luckily these messages are not in active use at the moment, so we could deprecate them easily if there was a better alternative to replace them with. I urge you to list the shortcomings that you have detected with these definitions so that we could start fixing them. Thanks!

[olliw42]

THX a lot for skimming in.

as regards messages, it’s IMHO not clear which messages should be specific and which should be general and a standard - we had a related discussion before.

I see the effort to support the Gremsy gimbal, there would be now the STorM32, and I guess one also should throw Alexmos/Basecam into the game. My feeling is that at the end of the day there won’t be such a thing as a “uavcan gimbal” driver in ArduPilot, but drivers for each gimbal. Also, I think the answer depends much on the type of function, e.g., if it’s about messages to control the gimbal, or messages reported by the gimbal. I’d also like to see messages related to discovery and startup.

I guess what I try to say is, that this is not something which I can see would be settled easily and quickly. To be honest, in the bottom of my mind I’m assuming that it eventually will go as before, that I’ll do a betacopter. I know, not a very optimistic projection, but it’s not always possible to reconcile everyone’s opinions in one standard.

Anyway, I think that this discussion is somewhat off topic, i.e. would be better placed in a separate thread.

And in case I have not mentioned it recently, many thx again for all your efforts with UAVCAN! You may note, I have a lot of fun with it.

[olliw42]

Y E S

after this period of “silence”, the uc4h project has reached a mile stone today

I did the first real flight using (only) the uc4h gps-mag node … and, it went well

To reach that point I had to build a new copter. My old one was just too small and cramped. From the pics you easily will recognize what it became LOL.

My initial plan, as mentioned before, was to have the gps and magnetometer of the uc4h node enabled in addition to the usual gps and two magnetometers, but to configure things such that the 2nd gps and 3rd compass are not used but their data recorded. However, this didn’t worked out for reasons (bugs?) described elsewhere. So, I decided to take the risk and substitute the normal gps+magnetometer with the u4ch gps-mag node. To do that with minimal intrusion I installed both gps+mag units on the copter, but in a first flight had connected only the normal gps+magnetometer unit, and in a subsequent flight only the u4ch gps-mag node.

Since I’m testing and running the code on the bench for such a long time now, and relevant things also successfully went into uavcan-izing the STorM32, I had quite some trust in it and was confident that it will work out well. Nevertheless, it’s a great thing to actually see that in a real flight.

In the data log, I see two red EKF warnings/errors. I’m not sure what they are supposed to tell me. Signs of trouble?

There had been one “surprise”, namely with the configuration of the magnetometers. Usually there is some smartness at work, which puts the external mag on ID1 and the internal on ID2, and sets the primary, used, and external flags accordingly. Not so with the uavcan mag, it was placed as ID2, and the primary, used, and external flags were set quite incorrectly. So, a point to improve, but not a big issue.

Finally: Pavel, THANKS so much, sir!

Cheers, Olli

Pics and the log file:
www.olliw.eu/drop/apm/AUAVX2-canunit-36dev-flight-w-uc4h-2017-08-04-18-18-48.bin

[olliw42]

and the next story to tell

my uc4h powerbrick node is a great success so far

I think this brick, if it will turn out to be reliable, has some top-notch features:
(A) Uavcan:
well, obviously, …
(B) 5.3V by low-noise 42V, 3.5 A switch regulator:
I use the LT8610A, that’s a member of the SRs used by the ACSP- series of AUAV/mRo. So, you’ll agree, top-notch.
© 100A current Hall sensor:
no lousy resistor shunt, hall sensor should be state-of-the art. I’ve used the ACS770, which is the predessor of the widely used ACS758, with slightly better specs. I was considering also to use a ACS780/1 because of it’s significantly smaller size. It has also the advantage of a 3.3V version. But it’s small size has also its cost (e.g. I think the ACSP7 is not perfectly designed).
(D) LDO stabilized power for the current Hall sensor:
that’s actually a point which I think the ACS modules so far have all overlooked (I just know about Mauch and ACSP7), the ACS is ratiometric. That means that if its power supply varies also the current sensor signal varies proportionally. If the ACS is now directly powered from the 5.3V source that means that if one draws significant power on the 5.3V line (such as 2A), the voltage drops by e.g. 0.3V or 6% in my tests, also the current on the main line will be measured incorrectly by 6% - which is IMHO quite a lot. So I’ve added a LDO for the ACS.
(E) Precise Charge Estimation:
This is another unique feature. Since the UC4H power brick has it’s own microcontroller, it can determined the consumed charge (mAh) much more precisely than would be possible otherwise. This is so because it can measure the current at a much higher rate and thus track current fluctuations much more precisely. Specifically, the node’s firmware measures the current at 1 kHz, which is several 100 times faster than with the currently available power bricks.

the only disadvantage: it is not really tiny (but obviously it’s the first test version)

I couldn’t do a test flight, since power.CircuitStatus is not yet supported by AP (if I’m not mistaken, there is “only” a PR). I actually struggled a bit with finding a procedure to test the brick, but luckily I found in my garbage bin an old heater element, with a resistance of ca. 2 Ohms, so perfect for some bench tests. So, I could do a good set of tests.
(i) heater element connected to the 5.3V power source => ca 2.3A Amp draw, no issues with that, the voltage ripple stays at 5-10 mV (the switching regulator chip gets hot, but that’s how it is). The voltage drops by about 0.3V to ca 5.0V, but that’s OK.
(ii) 3S lipo connected to the heater heater element, with the powerbrick in between => current draw of ca. 3-4 A. Voltage&Current recorded with UavcanGUITool => everything looks perfectly fine
(iii) 3S lipo connected to the copter with the powerbrick in between, one motor equipped with prop => current draw of up to ca. 9 A. Voltage&Current recorded with UavcanGUITool => everything looks perfectly fine

I’m really happy with that.
Hopefully the “AP_BattMonitor: UAVCAN support” PR gets merged into master soon
This brings up however again the question of a concept for how the CAN bus should be powered …

Olli

here the module and some “proof” by pictures

test (i) (1DIV = 5mV):

test (ii):

test (iii):