Servers by jDrones

UAVCAN for Hobbiests


(lucamax) #71

These are bitter words Olli …

I have a great admiration for your work and your skills that I fiercely envy, your work with UAVCAN for hobbiest is a great example of Open Source meaning , thanks!

(OlliW42) #72

they are not bitter but true :slight_smile:

well, if you consider the truth bitter, then … … this becomes philosophical hihi

(Pavel Kirienko) #73

@lucamax For a reference, this is where the docs are posted at:

I suppose you were referring to that page in your post. Yes indeed, these instructions may be a bit outdated. I am considering to drop them completely in favor of the ArduPilot’s wiki. Would someone please volunteer to draft up an updated setup manual on the ArduPilot’s wiki? I can’t do that myself because I don’t currently use ArduPilot (sorry everyone).

(peterbarker) #74

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

If you ever decide to try again and get stuck with anything, stop by the
ardupilot gitter channel. We help many people on there with git

(OlliW42) #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: 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,

(James Pattison) #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.

(OlliW42) #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.

(Thorsten) #78

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

(Marc Dornan) #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.

(OlliW42) #80

a discussion with mike_kelly has brought up this

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.

(James Pattison) #81

What’s the error? @peterbarker

(mike kelly) #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.

(James Pattison) #83

Ok, thanks. Appreciated.

(OlliW42) #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.

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:

(James Pattison) #85

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

(GuyMcCaldin) #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.

(Evan D. Williams) #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).

(GuyMcCaldin) #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.

(Evan D. Williams) #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.

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.

(kd0aij) #90

@olliw42 I took a quick shot at merging your code changes from betacopter36dev-v005 into ardupilot master and created a PR here:

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.