UAVCAN for Hobbiests

[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):

[olliw42]

first release v0.19 uploaded, and some info created

Binaries for the uc4h slcan adapter and uc4h gps-mag node can be found here: https://github.com/olliw42/uavcan4hobbyists.

Some info on the project and build schemes: http://www.olliw.eu/2017/uavcan-for-hobbyists/.

The uc4h SLCAN adapter can be build for as little as $4.71, and the uc4h GPS-magnetometer node for as little $3.70 (exclusive PGS+compass module). That’s DIY, isn’t it.

some pics of schemes and builds

[Pavel_Kirienko]

Olli, this undertaking of yours might be helpful for people who are starting with UAVCAN, even if they are not hobbyists. Would you care to announce it on the UAVCAN mailing list?

Thanks

[olliw42]

step by step … towards completion

I today did a test flight with my uc4h power brick, and - not unexpected - no issues with it.

For me that’s actually a big step, since I was shying away for quite some time from doing my own switching regulators, for all the problems one may encounter here. But it seems I did that carefully enough. I did some range test, not very professional admittedly, but as good as I could, and I could not detect any negative effect of the uc4h power brick.

The current AC3.6-dev master doesn’t support the CircuitStatus UAVCAN message, but there is a PR by EShamaev (https://github.com/ArduPilot/ardupilot/pull/6527). So, yesterday, I downloaded the master and added the changes of that PR myself. Surprisingly enough, the compile did work out. So, I’ve loaded that firmware, and it works nicely, I had no problems with getting the flight controller to recognize the UAVCAN messages emitted by the uc4h power brick. Nice job, EShamaev. Not sure why UAVCAN development seems to be on hold since so many weeks.

Here the setup:

Here the flight log:
www.OlliW.eu//drop/apm/AUAVX2-canunit-beta36r00103-flight-w-uc4h-gpsmag-powerbrick-2017-08-13-13-38-08.bin

I did even a bit more. I’m not happy with using CircuitStatus, IMHO that’s conceptionally a bit inconsistent - my reasoning is found in the mentioned PR. So, I’ve added a new message GenericBatteryInfo to both the ArduCopter code and the uc4h power brick code. Cool enough, also that worked very well!

(I found some general issue, https://github.com/ArduPilot/ardupilot/issues/6762)

Of course, needless to mention, the GPS and magnetometer were again a uc4h gpsmag node. I in fact had more than a half dozen flights with it now, and have not encountered a single issue. So, I guess, one slowly can start to think about labeling the uc4h nodes as “does work”.

The next step will of course be to add UAVCAN - STorM32 support, but I have feeling that this is not going to be as simple as adding the GenericBatteryInfo message LOL. Let’s see.

Cheers, Olli

[olliw42]

I’m not sure that’s of interest (I’m a bit entertaining myself here LOL), but just in case:

I’ve reworked the pcb layouts for the SLCAN adpater, gpsmag node, and power brick, removing few tiny bugs and making the latter two slightly smaller and “better”. I’m going to order them the next days, but I of course could order more of them. So:

In case anyone wants a pcb, pl leave a note.

This are the current v1.0 versions of the boards.
uc4h gpsmag node:

uc4h SLCAN adapter:

uc4h power brick:

[lucamax]

Great job olliw !

I think that it can be very useful because I2C bus can have several problems .

[olliw42]

Thx, sir.

I think it now went far beyond I2C. I actually like the power brick most, with all it’s innovs it became the brick I wanted. Already now I can’t imagine how I could have lived without it

[olliw42]

I have to show this, to demonstrate the point (E) Precise Charge Estimation of the uc4h power brick
(and I guess implicitly of the importance of (D) LDO stabilized power for the current Hall sensor):

I did a “long time” test, where I let the copter hover in poshold until the battery ran below ca. 20%, just for the sake of doing it. I used a freshly charged battery, and after landing charged it fully.

the u4ch power brick recorded a charge of 4336 mAh (see the log below)
my charger shows a charge of 4391 mAh

so, that’s accurate to better than 1.5% !!!

Note that this is without any calibration of any sort! The only thing I did is to take values from the ACS770’s datasheet and values from the electric scheme of the power brick to calculate conversion factors.

How cool is that. It’s definitely so much better than anything I’ve got with my 3DR-type power bricks, even with calibrating them. An accuracy of 1.5% in fact sounds to good to be true, but that’s a truthful report of what I just got.
Considering the error sources in the system (accuracy of the ACS770, accuracy of resistances, accuracy of LDO, accuracy of charger), the observed 1.5% is in fact somewhat fortunate, several % are however very realistic.

log file:
www.olliw.eu/drop/apm/AUAVX2-canunit-beta36r00103-flight-w-uc4h-gpsmag-powerbrick-2017-08-15-14-45-02.bin

charger result:

[olliw42]

yesterday - unintendedly - I got another reliable measurement point

I did an autotune, and since one can expect this to take a bit longer I started with a freshly charged battery (that’s important to get a reasonable data point). I however ended up doing 4 flights with that battery (=power downs in between), (1) autotune flight, (2) brief control flight with the new PIDs, (3) I went home and briefly tested again, (4) my neighbor’s cousin wished to see it flying too, so, another brief flight. From the logs I read off these discharges:
1: 3138, 2: 461.25, 3: 385.25, 4: 576.5 = 4561 mAh total
My charger told me a recharge of: 4652 mAh

so, that’s an accuracy of 2.0%

as said before, it’s unclear how coincidental this is, I certainly don’t know e.g. how accurate the charger is, etc. pp., but I find it funny that the numbers add up to something reasonable even though the battery has been disconnected repeatedly.

[olliw42]

finally the newly designed v1.0 PCBs have arrived and I’ve build a couple of them

below a photo of all world-wide existing v1.0 uc4h modules

so far all looks good, they all have passed the bench tests and all pcbs are like I wanted
tomorrow I’ll plan to test-fly mine, to have the final proof

(I guess I will start a new thread once some “data” comes in for them… )

cheers, Olli

[olliw42]

I did a couple of test flights today, and the modules appear to work great, could not see any issue with them

even though I’m largely talking to my self here, I want to share this part of the story, however, since I think it’s a great example of what two GPS units can do:

In these tests I had an issue with my copter, in that the standard ublox gps, connected as usual to a serial, had serious outages in the first flights. I can’t remember having seen that before, and I’m absolutely sure that this was because of the wiring of that GPS - I still use the crappy wires with which it came delivered… and rattling on them made the issue go away. Anyway, the good message, the uc4h GPS did not had any issue at all, and ArduPilot happily went along. In fact, and this is now really the point, I didn’t notice ANYTHING of that during the flights, the flights felt just normal! I saw that only afterwards in the logs, and was in fact “surprised”, you know, I didn’t had noticed anything before … I think we can safely assume that if I would not have had the uc4h gps on-board, I would have noticed immediately, in one way or the other

Well, you of course could say, “Get your dammed wiring right”, and you are of course right, but … I’m glad I didn’t had an incident

Great stuff this GPS blending thing!

In terms of data it looks like this:
(in the map please notice that the green line is GPS2 or the uc4h gps, while you can nicely see the outages of GPS1 in the blue line)

[mike (mike kelly)]

In the lower center of the image when the blended (yellow) averages the two gps ,which have drifted apart a considerable distance, the blended “short-cut” track is about half way between the two GPS. Did you experience any abrupt changes in flight or did it smoothly take the blended path?

Cheers

[olliw42]

good question, I too wondered about what this is supposed to mean, as well as the behavior of the red line
such cases are also visible in the top right loop
no idea

no, I did not notice ANYTHING of that, the flight was perfectly smooth, as usual, no jumps, and certainly not by 3 meters

this might not be so in hover, in the very first of today’s flights the copter was quite jumpy in hover, maybe I should dig out this log too

but at the end of the day, I guess I’m too lazy, the copter now finally got new wires for gps1, and all that is totally gone and is as before, I should have replaced them long ago … too lazy (or too busy)

edit: we should not forget that this is on master, which is not yet perfect

[mike (mike kelly)]

Well it also indicates well for the blended GPS code since previously with two GPS, that did not agree, the aircraft could abruptly change when Arducopter switched to the second GPS.

[lucamax]

@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

Hello Pavel ,
With Arduplane 3.8.2 I am not able to have the Zubax working, I still receive a “no gps” status from Mission Planner.
I have configure the node_id and set “gps_type” to 9 .

BRD_CAN_ENABLE and GND_PRIMARY parameters do not exist anymore.
A new CAN category is now present.

How can be configured the Zubax with Arduplane 3.8.2 ?

UPDATE: Setting CAN_P1_DRIVER to 1 makes the GPS to work
How to configure the Barometer and the Compass with Arduplane 3.8.2 ?

[tridge]

@olliw42 first off, I’d like to say how impressed I am by what you’ve done with UAVCAN for hobbyists! I didn’t know about this discussion until it was raised in the weekly dev call today, and I’m kicking myself for not paying closer attention and seeing it previously given it has been going on for many months. I’m really amazed at your persistence and the fantastic progress you’ve made.
You had a Q on the dev call topic about custom DSDL and what to do about it. I think the answer depends on the nature of the DSDL. If the DSDL is for messages that @Pavel_Kirienko is happy to consider for upstream acceptance then going via Pavel and getting it upstream is best. If the DSDL is not something that Pavel wants to consider for upstream but we do want to accept it for ArduPilot then I think it should go into the ArduPilot git tree.
Let’s take the example of DSDL for I2C-over-UAVCAN or serial-over-UAVCAN messages. Pavel has made it clear that he doesn’t want that in upstream UAVCAN, but I think it is something we should have in ArduPilot (if only to make hobbyist and prototyping easier), so the DSDL for that should be in the ArduPilot git tree. I think putting it in a libraries/AP_UAVCAN/DSDL directory in the ArduPilot git tree would make sense. @EShamaev, would you be happy with that?
One thing I’d really like to see with your work @olliw42 is to create a github fork of ArduPilot with your work. @james_pattison pointed out on the dev call that you do have it in a github repo here:

olliw42/storm32bgc

but that isn’t a fork of the ArduPilot git tree, so we can’t use normal git tools to merge, rebase, cherry-pick etc. We’d have to manually edit files to track changes. Would you be willing to redo your work as a normal github fork with your changes on top?
Perhaps we should add a small sample DSDL message in libraries/AP_UAVCAN/DSDL to act as an initial example? Maybe a simple message with a string that gets displayed as a MAVLlink STATUSTEXT? Just something to get started with our project specific DSDL, and get the build rules right and tested.
Cheers, Tridge

[tridge]

@lucamax

How to configure the Barometer and the Compass with Arduplane 3.8.2 ?

they should be working if you set CAN_P1_DRIVER. I fly my ranger with a Zubax1 and its working for me. Do you not see them?

[olliw42]

Hey Tridge,

thanks for chiming in and spending your precious time on this.

As regards my persistence you should not be impressed; it is limited. It is actually essentially exhausted, and I plan to sell off my pixXXX’s (except one). I have aimed at too high hanging fruits here and am too dependent on others for my lack of skills; the two topics you address are two examples :).

DSDLs: At the end of the day I would not care where or by whom they are placed. I just strongly feel that the current situation, where I had to fake them into the standard DSDL section (since I didn’t know better), isn’t the proper way. I also note that the concept of “vendor specific data types” is part of the UAVCAN concept. To me that implies that it doesn’t have to be either “accepted by Pavel” or “go into the ArduPilot tree”, it also could be just a folder which anyone who makes a fork for her/himself can place her/his messages. An example to explain that could be the UserCode,UserVariables files. You offered a place for anyone to put their stuff, but whatever anyone puts in there rarely goes into the ArduPilot tree or even higher upstream.

In the git issue I suggested a folder structure like (taking your suggested folder as base):
libraries/AP_UAVCAN/DSDL/ArduPilot
libraries/AP_UAVCAN/DSDL/ThisAreYourPrivateDSDLs
libraries/AP_UAVCAN/DSDL/ThisAreMyPrivateDSDLs
libraries/AP_UAVCAN/DSDL/…
this would only require adapting the build system such that it also dsdl-compiles everything it finds in libraries/AP_UAVCAN/DSDL/.

GIT: Well, that’s a problem. I’ve explained that already to james pattison: I’m not using git and find it difficult enough to be extremely reluctant to learn it. I in fact had made several attempts to read and comprehend the AP docs, but every time got lost half-ways in the middle and stopped. I don’t need it for what I’m doing, and I don’t find it a comfortable tool. I’m a hobbyist. The set of tools you guys use is above my level.
(you may find it not too difficult to find the changes though, searching for //OW does it)

Cheers, Olli