Funding for UAVCAN DIY UC4H ESC nodes [Closed]

It seems exposing as many core devs to UAVCAN is a good step to wider UAVCAN support. And perhaps not just for ESC’s in the future…

Hacker has released the Ditex line of servos with telemetry. Sadly, closed to Jeti so far. Hitec also has a new line of digital servos with telemetry but they also appear to be sticking to a closed protocol. It would be awesome to see an open alternative using UAVCAN for servos. Closed loop for simple gimbals and tilt rotor servos comes to mind. Assuming continuous rotation could also be handy for rovers.

I believe OlliW is interested in adapting UAVCAN via UC4H nodes for servos. Check his UAVCAN thread in RCGroups.

https://www.rcgroups.com/forums/showthread.php?2869828-Uavcan-for-Hobbyists&highlight=UAVCAN

1 Like

Thought this may be a reasonable place to ask as this is for ESC development. For our test rig I need a reliable PSU. has anybody had any experience with EA Elektro-Automatik 6230263 Digital Bench Power Supply:?

https://uk.rs-online.com/web/product/products/8069717/

Thanks

I am not against this funding nor UAVCAN experiment.
But ArduPilot isn’t rich unfortunatly, so I don’t want to spend much money on project without direct counter part for everybody. The project money isn’t dev money, but communauty money. So I cannot spend money on something without direct counter part for the communauty, other we can be accused to only use the money for ourself, called devs.

So I would expect, some wiki doc, and some blog post on the funded hardware in 1 to 6 month ! That is my condition, that is not big …
That is my personal opinion on this proposal, it engage only myself. But I prefere to be clear from start.

@khancyr FYI http://www.olliw.eu/2017/uavcan-for-hobbyists/
There’s already a rather comprehensive blog :wink:
But yes, if we pull support in upstream, the wiki needs attention. I think that’s a fair stipulation.

Thought I remembered something similar.

https://discuss.ardupilot.org/t/next-gen-esc-validation-and-integration-vesc-declined/12534

REMINDER REMINDER REMINDER

I’d like to draw your attention to the attempt of a group buy of UC4H ESC KISS Carrier Boards, which can be used to build UAVCAN ESCs by installing KISS 32A or 24A ESCs in the carrier. The details of that effort are described in post #526 RCGroups

Currently 24 carrier boards have been “ordered”, but I’ve (artificially) set a limit of a minimum 30 (or 32) to complete this effort. So, we are short of two participant.

The call is however still running for about a week, so, still time to sign in!

I will close this call by Thursday, 8. March., 24:00UTC.

(this is to get things synchronized with my day work )

Have fun, Olli

Hi guys! I am Alex, engineer from Zubax. I found this topic and I really like it.
I have one question about it. Why won’t you use Zubax Orel instead of inventing your own very special UAVCAN ESC?
If it is all about having ALL-IN-ONE solution how about using a set of off-the-shelf Zubax Orels and design a 3d-printed housing to hold them all together(btw, there is housing for it on thingiverse)?

1 Like

Mike, thanks for the reminder. I’d like to fund this, possibly adding ACPUK to the list of people getting them, if that’s ok with you.

I agree with khancyr’s concerns: we would expect each participant to not only test but commit to participate in a discussion thread pertaining to this, document findings, and also participate in wiki documentation.

Mike for 5 people, would $1,250 total be appropriate, at least for budgeting purposes?

The funding committee will try to meet soon (before 3/8) and come up with a final decision.
Thanks again!

I am a little bit confused here
UAVCAN is not open sourced and Zubax is ?
Are we about to invest in a closed source system ?

Correct me if I am wrong but I can see the source on Zubax here: https://github.com/PX4/sapog
but just hex files for the UAVCAN : https://github.com/olliw42/uavcan4hobbyists/tree/master/firmware%20binaries

Unless I’m mistaken, Zubax doesn’t open source their current code - what’s released/linked is a hardware compatible firmware that is feature poor.
I would much prefer that Olli opened his source code though.

Agree, if @olliw42 can open the code that would make it really interesting , otherwise I think this is disqualifying the project.
Not being a member of the funding comitee, I will let them decide on the qualification of such a project.

I’m sharing my personal view on this.

The proposal should have 2 tiers

  1. for the uavcan adapters, where the hardware design is opensourced by @olliw42 and the DIY SLCAN adapter

here i don’t mind about the nature of the firmware, as I also don’t mind the nature of the firmware of other components, like the ublox gps firmware. Nobody is asking also for ublox to open source their firmware…

  1. The Kiss ESC’s

If any dev is seriously interested on this project he/she probably has already some compatible ESC’s or can easily buy a set of ESC’s. @olliw42 clearly explains why he chose these on the rcgroups thread, so I’m sure that other ESC’s might also be used, and would be beneficial if other ESC’s were used to increase the range of choices, as long as they maintain the required specs laid out by @olliw42.

This looks like up to date, completely opensource firmware?

If there’s an opensource product available, surely that should be encouraged over closed solution? Having the firmware opensource is a much better model for the community as all that open knowledge can be evolved by multiple implementors and there is potentially a wide choice of hardware for the community, similar to ardupilot/px4 and flight controllers. Having opensource hardware but closed firmware is essentially a proprietary product controlled by a single entity.

There’s opensource hardware reference implementation as well as the zubax commercial offering:

Yup, familiar with it.
I think you’ll find my point valid. They don’t enable anything we can’t already do - ie no feedback. Olli’s work is enabling new things.
And at USD$77 each plus shipping sapog just isn’t worth the money (imho).
I’d add that when OMD are ready, I think we should fund a small set too, and that’s all open source (https://github.com/OpenMotorDrive)

The Zubax ESCs/Sapog firmware publish ESC status messages (https://github.com/UAVCAN/dsdl/blob/master/uavcan/equipment/esc/1034.Status.uavcan) and even accept RPM commands.

What type of feedback or new things are you referring to?

My bad then! Thanks Dan.

Indeed, as stated above SAPOG which is a firmware for UAVCAN ESC(OREL) is open-source. Also, there is reference hardware for SAPOG freely available(it is pretty similar to Orel). If anyone really likes to - he can combine those together and manufacture his own Orels. But as far as I see there is no point in doing that as its too much trouble.
It is always easier to get already existing hardware.
Anyway, I’d like to add here that there are several UAVCAN tutorials here. Maybe you will consider them useful.

For me the ORELs are not within reach of the DIY hobbyist and I own a set of ORELs. The UC4H adapters are going to be under $15 making it possible to have a UAVCAN ESC for half the price.

You are right, ORELs may be a little bit pricey. But they are here and they are ready. You can have them in, like, a week or two and they will definetly work (I own some of them too).
At the same time creating a new ESC(even from existing ones) may bring numerous problems

  • It may take more time than expected as it often does in manufacturing
  • No one can ensure it will 100% work
  • Chinese ESCs are widely known to be overrated.

If your goal is to integrate proper UAVCAN support to ardupilot firmeware - I’d higlhy recommend to use off-the-shelf(and 100% working) hardware, as it will save lots of time. Orel or recently released Myxa are good examples of such hardware.

If your purpose is to develop your AFFORDABLE UAVCAN ESC - I’d recommend you use PX4 SAPOG reference hardware and get into all troubles of manufacturing. You may save some costs excluding some parts from reference design and replacing something with cheaper alternatives, I guess…

Just making an adaptor(which, by the way, is already described in one of the tutorials listed above) won’t bring you all the benefits of UAVCAN. No doubt, it will make wiring of your UAV much cleaner, but RCPWM interface is inherently pretty slow and this will become bottleneck of your idea. And you will also lack lots of status data(like current consumption, ESC temperature or RPM).