UAVCAN for Hobbiests: Simple GetStarted Questions

[OlliW]

Hey Pavel, and everyone else,

for a while now I was pondering about adding UAVCAN to my DIY pure-hobbiests projects, but feel now prepared to get more serious. I would have some simple questions though.

* Is there any cheap (!) usb-can or usb-uart converter which can be recommended?
I've seen the other thread, but $65 isn't cheap at all on my scale, and the other solutions don't seem ready to go. I've seen some $20-$25 adapters on aliexpress/ebay (http://www.ebay.de/itm/USB-CAN-USB-to-CAN-BUS-Converter-Adapter-USB-Cable-support-win7-System/391116436962). Any experience with them?
Any other better suggestion available?

* I understand the saftey issue with a proper hardware interface design, but as a hobbiest it's difficult to make the right choice. You thankfully give some hardware recommendations, which is very helpful.
May I assume that the SN65HVD230 is the recommended transceiver?  (I ask for an explicit confirmation because I believe to remember that on some fc board the transceiver type was changed because the "old" one was found to have issues, from which I conclude that it's not like that any transceiver is as good as any other)
Could you please also offer some specifics on the fuse, ideally a mouser/digikey/farnell/newark number? (It would be cool if the info would be such that one just would have to build and would know that one has done everything right. :))

* I would work on a F103. The full UAVCAN lib is too heavy for me, and I use plain C and not C++ anyhow. The LIBCANARD seems the right thing, but the last time I checked its code didn't looked ready to me. I just re-checked again, and it still looks incomplete. Is my impression correct (yes/no)?
Is it to be expected that something fully useable will appear in the next time (weeks/months), or would I essentially start from scratch? 
(don't get me wrong, starting from scratch would be fine, I just would be very unhappy if two weeks later a fully working LIBCANARD would become available LOL)

Thx for all your work you put into this. Cheers,
Olli

[Antoine Albertelli]

Hey Olli,

* I would work on a F103. The full UAVCAN lib is too heavy for me, and I use plain C and not C++ anyhow. The LIBCANARD seems the right thing, but the last time I checked its code didn't looked ready to me. I just re-checked again, and it still looks incomplete. Is my impression correct (yes/no)?
Is it to be expected that something fully useable will appear in the next time (weeks/months), or would I essentially start from scratch? 
(don't get me wrong, starting from scratch would be fine, I just would be very unhappy if two weeks later a fully working LIBCANARD would become available LOL)

libcanard is not ready yet but there is some code available. You would need to implement message serialization yourself, but there are some examples, e.g. https://github.com/UAVCAN/libcanard/blob/master/src/canard_test.c#L221-L237. You will also need to write drivers for your CAN interface. That should not be too difficult, depending on your level of familiarity with the STM32.

That said, what makes you think it is not possible to make libuavcan fit into an stm32f103 ? My team was able to make it work in a stm32f303 with 256 kB flash so it should be quite doable. I agree that if you don't know c++ it will be hard at the beginning, but the approach we chose was to only write the communication code in c++ with most of the application in c. You can find the (ugly) code on github if you want: https://github.com/cvra/motor-control-firmware/

Good luck with your projet,

Antoine 

[Pavel Kirienko]

Hi Olli,

1. The best adapter known to me that is currently available on the market is 8devices USB2CAN, I believe you were referring to it when mentioned the other thread. It doesn't match your price expectations, but in my experience it provides the best experience for the price compared to other options I tested. Regarding aliexpress and alike - I ordered one no-name adapter once from there, found zero documentation and zero customer support, 0/10 would not buy again. I know that Ben Dyer (a huge contributor to UAVCAN) had some experience using USBtin, but I'm not sure whether it was positive or not. Lastly, we can ship you a prototype of Zubax Babel (not available on the market yet) - a high-throughput/low-latency USB/CAN+UART/CAN SLCAN adapter that works with Win/Linux/Mac. If you're interested please contact me off the list.

2. Use SN65HVD232DR for CAN transceiver, and 0ZCH0050FF2G for a fuse (this one is rated for 0.5A, adjust if necessary).

3. As Antoine said, there should be no problem with using libuavcan on STM32F103. I personally used this library on this MCU without issues. You need to allocate about 20..30k of flash and about 6K of RAM for the library though. If that is not feasible, I suggest you to start with libcanard - it still lacks platform drivers, but you could port the STM32 one from libuavcan, it should be quite easy to do.

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/41a8f672-77bd-4860-8b7a-54bfaad3ee5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[OlliW]

THX for the helpful responses :)

I didn't meant to imply that uavcan wouldn't work on F103, sorry if I was misleading (6k can sometimes be an issue with the 20k limit on some, but certainly not always).

I'm not using C++ but am fluent enough to use/modify code written in it. It's just that all my other stuff is in C, and I'm not going to rework that just for UC. LOL. Maybe your approach, Antoine, to mix C and C++ is a very good idea, haven't considered that but I probably should. Thx for the suggestion.

65$ for just an adapter is out of question. I'll see what I'll do.

THX for the can transceiver/fuse info. This really helps a lot.

Thx again, Olli

[OlliW]

I was asking a question in the thread "stm32 chip.h" (https://groups.google.com/forum/#!topic/uavcan/V9cgPijQW8k) which lead to some exchange which I now feel are much better placed here, so copy some pieces over, and continue here:

[OlliW]

Am Montag, 10. Oktober 2016 18:08:58 UTC+2 schrieb Pavel Kirienko:

Hi Olli,

> clearly got the impression that the initial stepping stones to get going are huge, at least on a hobbyists level, it's not only the driver, but also heap, serialization/dsdl, and this and that and so on and forth

Yes indeed, libcanard is designed for very resource constrained systems, and it provides a very minimalist function set - basically it implements only the transport layer, leaving all the rest to the application developer. You've probably seen this example already: https://github.com/UAVCAN/libcanard/blob/master/tests/demo.c, notice a few things about it:

- it implements dynamic node ID allocation in the application;

- it uses canardDecodeScalar() and canardEncodeScalar() for marshalling, since libcanard does not support message generation (there is some abandoned effort to implement message generation though, any help welcome: https://github.com/UAVCAN/libcanard/pull/6).

> but also heap

Neither libcanard nor libuavcan use heap, since they are designed for high integrity real time applications.

> if one wants to interface with ArduPilot - which is what I want - one needs e.g. the auto-ID thing

No, you do not have to implement the auto-id thing unless your application requires it. The auto-id thing is documented here: http://uavcan.org/Specification/6._Application_level_functions/#dynamic-node-id-allocation.

> do I have it correctly that

> (a) one "only" has to provide implementations for can.hpp and system_clock.hpp ?

> (b) and in fact only for the classes

> * ICanIface

> * ICanDriver

> * ISystemClock

> but not CanFrame, CanFilterConfig, CanSelectMasks ?

The documentation on developing a driver of your own is provided here: http://uavcan.org/Implementations/Libuavcan/Platforms/Adding_support_for_a_new_platform/. You need to provide implementations for the interfaces you listed - ICanIface, ICanDriver, ISystemClock, that is correct. You should not replace or in any way modify any header files of the library itself.

> considering that some stm32 code is already there, why would it be better to make a new custom driver, that is, what is so bad about the current code which would make it easier to start from scratch instead of from it?

Indeed, I was rather unclear in my original message. What I intended to suggest is to fork the current STM32 driver, ditch all functionality pertaining to ChibiOS, FreeRTOS, and NuttX, and fix the baremetal part of it. I consider the ditching part important, since in its current form the driver has become a horrible and unmaintainable mess of conditionally compiled parts; growing it further is a recipe for disaster.

In order to give you a more direct advice, could you maybe describe your application, specifically why you're keen on avoiding RTOS?

Pavel.

On Sun, Oct 9, 2016 at 6:19 PM, OlliW <oll...@gmail.com> wrote:

pl let me expand on your suggestion of making a custom driver for libuavcan

do I have it correctly that
(a) one "only" has to provide implementations for can.hpp and system_clock.hpp ?
(b) and in fact only for the classes
* ICanIface
* ICanDriver
* ISystemClock
but not CanFrame, CanFilterConfig, CanSelectMasks ?

If so, considering that some stm32 code is already there, why would it be better to make a new custom driver, that is, what is so bad about the current code which would make it easier to start from scratch instead of from it?

[OlliW]

hey Pavel

many thxs for your responses

thx for directing me to the demo.c, I for sure have seen it, but I did not appreciate it as much as I probably should have ... it indeed has much solved :)

heap: sure, I wasn't clear, sorry, I meant this dedicated "pool allocator" thing or whatever the uavcan terminus is

auto-id: ah, that's interesting ... I couldn't refind now that comment, but I think to have read somewhere that it is recommended to not mix auto-id-ing and fixed-id-only units in one uavcan network ... further assuming that AP uses auto-id-ing I concluded that this is kind of a minimum requirement ... so, you're saying, there won't be any issue with using a fixed-ID unit, which is totally unaware of auto-ID-ing, together with ArduPilot (y/n)? This would make life a lot easier, I guess.

driver: yeah, I noted that document, and it is clear on that ICanIface, ICanDriver, ISystemClock are only needed, but I guess I wasn't clear, sorry, what I kind of asked is if CanFrame, CanFilterConfig, CanSelectMasks could be (re)used as-is and wouldn't need changes.

reusing stm32 driver code: ok, that's what I actually did at first ... LOL

RTOS: well, LOL, you know, I'm not a professional software guru ... I've never used a RTOS, have no experience with that, and honestly I find getting uavcan up and running difficult enough so that this is not going to become my first learn-RTOS project :)

application: well, I'm not sure what to do with it exactly, I just think that once it would be available for the average DIY guys like me it would open many simpler applications ... I mean, currently it's not like that for simpler applications there would be code ready-to-grab, also there is no cheap usb/uart-uavcan bridge (babel is probably fantastic, but >60$ just for that????), and so on ... to me it currently really looks like uavcan is only for the dedicated professionals ... and I don't like that :D

thx, Olli


(my greatest problem currently is anyhow that Coocox 1.7 doesn't really allow to compile c++ ... LOL)

[Pavel Kirienko]

Hi Olli,

> so, you're saying, there won't be any issue with using a fixed-ID unit, which is totally unaware of auto-ID-ing, together with ArduPilot (y/n)? This would make life a lot easier, I guess.

Mixing dynamic ID and static ID is not prohibited, but not recommended. More is elaborated in this chapter: http://uavcan.org/Specification/6._Application_level_functions/#dynamic-node-id-allocation

If you want to be on the safe side, I would recommend either implementing auto ID on your node, or disabling dynamic not ID allocation on the autopilot, making all nodes statically allocated.

> if CanFrame, CanFilterConfig, CanSelectMasks could be (re)used as-is and wouldn't need changes.

There is no reason for them to require any changes.

> RTOS: well, LOL, you know, I'm not a professional software guru ... I've never used a RTOS, have no experience with that, and honestly I find getting uavcan up and running difficult enough so that this is not going to become my first learn-RTOS project :)

It may seem counter intuitive, but I would hazard that it should be easier to start with an RTOS, rather than from baremetal. Check out ChibiOS, it has a number of convenient abstractions and it is very easy to setup and get running.

Pavel.

--

You received this message because you are subscribed to the Google Groups "UAVCAN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/78bcd105-2259-4407-b99a-8059d546443e%40googlegroups.com.