UAVCAN for Hobbiests

ArduCopter
, ,
75

hey Folks

I did some more flights these days, and as a result have just decided to officially declare the UC4H project as “working”. :slight_smile:

The UC4H nodes are working well. There are of course little things which still could be improved and changed, but overall I’m very satisfied. It’s working and I very much like my UC4H-ized copter, it is more reliable than ever before. In this sense the project has accomplished its goals.

I’d like to leave some comments on its current applicability:

In principle, the UC4H nodes can be used in any UAVCAN network. That’s the idea of UAVCAN. However, in practice the options boil down to ArduPilot, with these additional restrictions:

(to the best of my knowledge! please correct me where I am wrong)

ArduPilot master:
You need to flash at minimum from master. The “new” UAVCAN support is only in master so far. As much as I know this holds true for both Copter and Plane. However, master only supports the GPS and magnetometer UAVCAN messages, but not the UC4H power brick. With ArduPilot master you can use the UC4H gps-magnetometer node.

BetaCopter 3.6dev:
This is a fork of ArduCopter master of 12. Aug. 2017, and has compiled (and flight tested) binaries for v2 and v4 flight controllers. It has full support for the UC4H gps-magnetometer and UC4H power brick nodes (as well as for the STorM32 gimbal controller). Thus, if you want to make use of the full potential of the UC4H project, you want to flash BetaCopter3.6dev-v005 (binaries are here: https://github.com/olliw42/storm32bgc/tree/master/betacopter/betacopter36dev-v005/ArduCopter). The limitation is that it is only for Copter, and v2 or v4 flight controllers.

The UC4H SLCAN adapter is of course independent on any flight controller support, and also UAVCAN, and thus can be used in any CAN bus network.

I admit that I would have expected the project to attract more interest among hobbyists; I even thought it could evolve into a sustainable source of funding for ArduPilot LOL. But I’ve grossly misjudged that; I have failed to realize that CAN and UAVCAN in particular is pretty much unknown to them. It’s not on their plate (thx Mike for teaching me :)). However, I myself have benefited a lot. I have now a SLCAN adapter to work with CAN without having spent 80$ or more, and I never would have put a CAN transceiver onto a STorM32 board otherwise. Even if it would be for these side effects only, it was a great endeavor.

I’d like to close with saying a big thanks to all those who have supported this with answering my pesty questions, THX to EShamaev and Pavel! Especially Pavel!

Hopefully ArduPilot will tighten up its lose ends related to UAVCAN rather sooner than later. It would be cool to see the new UAVCAN environment become part of AC3.6.

Thx, and cheers,
Olli

1 Like
76

Olli, thanks for pushing the boundaries: it’s people like you who keep projects like ArduPilot moving forward.
If you have suggestions about how to keep this moving forward, or how ArduPilot can support contributors like yourself a bit better, feel free to drop me an email.

1 Like
77

well, as said, UC4H is IMHO working, I don’t see significant lose ends which would need immediate attention. I do see lose ends on the ArduPilot side. The magnetometer support could need attention, the GPS support is even dodgy if not buggy, hints point to that the GPS blending has edge issues, the circuit status PR is not merged, there is no possibility to configure UAVCAN node parameters, the DSDL messages are somewhat of a mess, there is the issue of supporting custom DSDLs, and so on. I note that there hasn’t been any improvement for many months. Zero. For at least 1/4 year. And as said I do not have the strength to solve them. So, I think the best support would be if ArduPilot’s UAVCAN would reach a state where one could wholeheartedly recommend newbies, dummies, hobbyists to use UAVCAN nodes. UC4H, for the moment, is fine. IMHO.

78

You are just too fast and a little too early! Keep up your great work!
Are you planing to sell the parts?

79

Olli, I have to admire you blazing such a trail and just doing this, and working around obstacles. And not just doing this on the bench but in flight, and producing really nice hardware designs as well. I too just found this thread – not that I was looking.

I hope it can result in Ardupilot embracing what you have done and finding a way to get this into master. We really could use CANBUS and your approach just seems to work and has the merit of being affordable. And i2C cable runs just suck!

Olli – you are too modest. You should just directly ping the principal devs when you need something.

80

a discussion with mike_kelly has brought up this

WARNING:
On the power brick, the labeling for the CAN connector on the bottom side is INCORRECT.

On the SLCAN adapter and the gps-mag node the labellings are all correct.

81

What’s the error? @peterbarker

82

SIlk screen on the board indicates the wrong order of vcc, canh, canl, gnd. They are correct on the connector. Works fine, just labeled wrong on the silk screen.

83

Ok, thanks. Appreciated.

84

[quote=“Thorsten, post:78, topic:16464”]Are you planing to sell the parts?[/quote]me? no

[quote=“james_pattison”]What’s the error?[/quote]as mike_kelly already said, the silk screen for the JST connector on the bottom side is reverted … note: this holds for only this connector, the silk screen for e.g. the pin header next to it is correct

mike_kelly is making great progress with his uavcan-franken-solo project:

first ProfiCNC Here uavcan gps/mag, enabled by uc4h.

IMG_0002.JPG1600×1200 367 KB
IMG_0003.JPG1600×1200 339 KB

I forgot to announce this also here:

The first one who demonstrates a successful flight using UC4H components will get the “World’s First UC4H User” batch … currently mike_kelly seems to be in the lead :slight_smile:

1 Like
85

Nice work mike.
@proficnc you might like this. Goes well with the other uavcan solo work :wink:

86

Hi Olli, I found this thread through research on UAVCAN for a power module design I’ve been working on. However, it seems you’ve already implemented pretty much exactly what I had in mind, right down to small details like the ACS770 with a properly implemented LDO regulator.

There’s one additional feature that I think would be very useful for the UC4H Power Brick: Individual cell voltage monitoring. This would assist with battery health monitoring, and bridges some of the gap between our current system, and full smart batteries.

Being able to read these values in flight gives some degree of advanced warning if something is going wrong with the battery, and would simplify regulatory compliance that requires commercial operators to log these values in Australia (and probably elsewhere too).

This could be achieved using the ADC abilities already present on the STM32F103, and a 0.1" header or JST-XH connector that would connect to the balance lead of the battery.

1 Like
87

Good Evening,

Just chiming in to say that I like this idea - it would provide similar functionality to the smart battery support of the existing implementations for SMBus-attached packs (i.e. the Solo battery and Maxell packs described here. Having read through that portion of the Battery Monitor code, I would definitely recommend a more thorough implementation of the SBS v1.1 specification, as opposed to the bits and pieces (total and remaining capacity for this model, cell voltages for that model, only voltage and current for another . . .). I’d also be interested to see if the ACS781xLR cannot be used in place of the bulky ACS770 (though the manufacturer description implies lesser accuracy?)

Don’t misunderstand - this is no small feature suggestion. It involves more low-level work than I myself am accustomed to, so it’s easy to bring it up without myself appreciating the depth involved. However, I’m already somewhat invested in the smart-battery approach, and am similarly tied by the hands for safety monitoring regarding regulations/approval compliance. If nothing else, I’d end up having to develop it myself to meet requirements (though it would be integrated with a full BMS system for li-ion packs, just using UAVCAN as the carrier).

(P.S.: I believe using a 5V version of the ACS7x series may be wise, as an analog sensor’s resolution is determined by the output swing (cut in half for the bidirectional version I suggested!) and the accompanying ADC’s resolution, tempered to some extent by the collective accuracy of the sensor, ADC, and effects of system EMI).

88

The issue with the ACS781 is the resistance of the current sensing element. It’s 200µΩ, as opposed to 100µΩ for the ASC770. This effects thermal management, where doubling the resistance essentially doubles the amount of power the module will need to dissipate.

89

[quote=“GuyMcCaldin, post:88, topic:16464, full:false”]
The issue with the ACS781 is the resistance of the current sensing element. It’s 200µΩ, as opposed to 100µΩ for the ASC770. This effects thermal management, where doubling the resistance essentially doubles the amount of power the module will need to dissipate.
[/quote]

Ah, I had overlooked that factor. 200µΩ @ 100A yields 2W of heat dissipation, after all.
Was it mentioned what the design current of the assembly is? I presumed the full 100A rating of the hall sensor.

90

@olliw42 I took a quick shot at merging your code changes from betacopter36dev-v005 into ardupilot master and created a PR here: https://github.com/ArduPilot/ardupilot/pull/7167

I haven’t yet tried to fork the uavcan submodule, so it won’t yet compile. But please let me know if I’m on the right track here, and if I missed any of your changes in the ardupilot code.

91

this is FANTASTIC. Thx so much. I’ll respond in the PR.

92

now it has happened

the race is over

MIKE KELLY IS THE WINNER

batch-mike-kelly.jpg786×938 102 KB

well, it was not exactly a race … as much as I know he was the only participant LOL … but this in no way diminishes his accomplishment and the fact that he is the first user demonstrating a successful flight using UC4H components.

So, CONGRATULATIONS!

Your grand kids will tell their grand kids about this historic moment :slight_smile:.

2 Likes
93

The hard part is going to be finding some grandkids!

1 Like
94

hey folks,

a new kid is in the blocks: the UC4H ESC node

trying to also control the motors via UAVCAN was kind of an obvious thing, albeit a bit of an overkill. However, with UAVCAN one can get in principle also telemetry data from the ESC & motor, and this would be a real additional value. Gladly, the latest KISS or BLHeli ESCs do in fact offer telemetry, so that then paired up with an UC4H ESC node this should be something cool. I further realized that quite some times ago I bought a KISS 24A ESC, which I never used, but now gladly found in my box. So, as a late afternoon exercise, I just started.

Unfortunately, I could not yet convince the ESC to provide the telemetry data. Not sure why, maybe I have to flash a newer firmware, will have to see. However, everything else seems to work: The node digests the esc.RawCommand message at the selected esc index, and broadcasts the esc.Status command. And with a UC4H SLCAN adapter and Pavel’s great UAVCAN GuiTool one can test all this quite conveniently. Ah, the motor also turns of course LOL.

As is, it is not yet useful. One probably would want smaller pcbs. Also, it is probably wasted time to continue working with the KISS 24A, a DSHOT capable ESC with telemetry, ideally BLHeli_32 due to the lower price, should make more sense. But I don’t have any. And the selections are quite confusing, so I need to do a bit research, I guess. Recommendations?

Anyway, a start has been made, and this is on the way

cheers, Olli

uc4h-20171114-esc-node-01-setup.jpg1471×1080 332 KB

uc4h-20171114-esc-node-01-uavcanguitool.jpg1670×1080 343 KB

uc4h-20171114-esc-node-01-oszi.jpg1452×1080 212 KB

2 Likes