What’s the error? @peterbarker
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.
Ok, thanks. Appreciated.
[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 
1 Like
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
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).
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=“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.
@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.
this is FANTASTIC. Thx so much. I’ll respond in the PR.
now it has happened
the race is over
MIKE KELLY IS THE WINNER
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 .
2 Likes
The hard part is going to be finding some grandkids!
1 Like
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
2 Likes
Awesome!
Are you aiming for just a single esc per node, or more?
Re esc’s, I’ve been using Airbot recently for a side project (non ArduPilot), and haven’t had any problems (https://store.myairbot.com/).
This is a cool way to get dshot support too - which is pretty neat.
@tridge
I was thinking about it. Technically it’s well possible to support “many” escs with one unit. But I couldn’t really see a reasonable application. You do?
So, I’m currently thinking about a pcb into which the ESC can be soldered in. A bit like KISS’ carrier PDB, but just for one ESC.
I do not think that “DSHOT support” would be a valid claim, it kind of defeats the purpose of DShot. There is some additional latency+jitter of something like 250us due to the CANbus, and in addition the ESC update rate is relatively low. I don’t think that this would impress any DShot user. Any of the recent protocols, from OS125 onwards, is better than UAVCAN.
I think 2 in 1 would be nice for coax setups. I see the use case as mainly larger copters, where esc’s are often outboard with the motors, so 2 is probably practical. Other than that, it is more a size/weight consideration - for instance, 4-in-1 esc’s have become popular, and having to use 4 adapters would be impractical if someone wanted to convert to uavcan. But I’m not sure that UAVCAN would really fit that use case, as the 4-in-1 esc’s are usually in smaller quads.
The DShot support comment was more in the context of feedback than performance. Getting motor feedback would make it easier to implement failure identification and management, which is something I’d like to see make it’s way into ArduPilot.
I had seen these dual motor cases too … you’re no concerned that folks will be worried about breaking redundancy? I mean, one node failing will bring down two motors … as said, technically it would be a piece of cake to do it.
Yeah, 4-in-1’s, actually, the gpsmag node pcb, which I’m using in the above, has 4 pins and could control 4 motors … but those are popular not only in small but also in race quads, none of which will ever be dominated by CANbus. IMHO.
Feedback is NOT related to DShot! E.g., the KISS 24A I’m using offers telemetry for any protocol. Not sure BLHeli_32 does, but it too could.
Getting motor feedback would make it easier to implement failure identification and management, which is something I’d like to see make it’s way into ArduPilot.
this would be fantastic, agreed, but honestly, maybe one should first aim at getting the basics working, see e.g. Mike’s experience: MP mag calibrate does not work with EKF2 enabled in 3.6dev. I guess Mike would rather prefer that someone takes up that challenge :). There is a list of other issues.
@EShamaev
as regards the GenericBatteryInfo message you were saying in the ardupilot gitter channel that
The Olli’s reasons were documented, but I find them very unconvincing.
His message is simply a stripped down version of DSDL’s with lot of simplifications.
You also were making this point that it is just a stripped down version of existing dsdl messages elsewhere. The only way I can see this could be true is that you think that available dsdl messages carry a data field which could have been used.
So, could you pl tell me which data field(s) in which dsdl message(s) you think I could have used for the purpose?
I mean that if there exists a well though message with more parameters, I see no point in introducing a custom reduced one.
I also made points “elsewhere” what can be used.
So here it is:
mAh consumed is meaningless to me. My motors and actuators consume power and not only current. In my setup torque produced by motors is directly related to power.
The parameters full_charge_capacity_wh and remaining_capacity_wh do give much better understanding of remaining flight time.
Also in larger UAVs the battery can be charged in flight from generator (my case) and thus other parameters of DSDL make sense.
What can be added to this message is “nominal voltage” though.
It was historicaly, that Ardupilot “overmanaged” the devices connected to it as it was the only one “smart” component on board. It is a legacy we have, but no one prohibits us from moving forward. There is already get_watt_max in AP_BattMonitor and capacity_remaining_pct that can be used with the parameters in existing DSDL messages.
I would rather see percentage on GCS than the arbitrary mAh when I do not know battery voltage and total capacity.
Another issue that power brick is NOT a smart battery at all. It is also a legacy that it is considered one but that’s a huge mistake and your approach with broadcasting CircuitStatus message seems much more reasonable to me and that’s one of the reasons I added that message to AP_BattMonitor. However due to high tension I removed it now from that PR for now.
1 Like