Servers by jDrones

UAVCAN UART NODE ; adding 3 more Serial Ports to your Flight Controller with TUNNELING


(ppoirier) #1

Thanks to the excellent work from @olliw42 and experiments from @mike, I finally decided to start experimenting with UAVCAN, following this blog.

I present here a simple project, that may interest some of you that are looking to add more serial interfaces and cannot switch to an alternative technology like I2C or SPI.

It is using off the shelf modules that you can order from the usual web suppliers for a few bucks and by interfacing 2 x Benewake TFMINI serial RangeFinder, you can make a basic avoidance with a range of 12 Meter Indoor and 6 Meter Outdoor.

Building the DIY Nodes
Looking at the schematic above, you need:
2 STM32F103C8 development board, also called "BluePill’
2 SN65HVD230 Can transceiver module, CJMCU-230
1 SILAB CP 2102 (CJMCU–CP2102) or a FTDI USB -TTL Adapter

You can build using different techniques, ProtoBoard, BreadBoard or "DeadBug’’.
Take note that some of the modules may be defective or marginals, I suggest you order some spares just in case.

We are building 2 Modules:

UC4H SLCAN Adapter
The SLCAN adapter is an indispensable tool for checking and debugging the proper functioning of a UAVCAN network. In simple terms, it is a USB-CAN adapter, which is connected to the CAN bus on the one side and via USB to a PC on the other side. On the PC side the UAVCAN GUI Tool, which is freely available as part of the UAVCAN project, provides a nice software for doing a lot of things, such as spying the messages on the CAN bus, plotting data, setting node parameters, and so on .

UC4H UartBridge Node
The UC4H UartBridge node allows one to connect any device with a standard UART/serial port, such as a GPS module, and to communicate with it through the CAN/UAVCAN bus. It’s like a USB-TTL adapter, except that the USB frontend is now UAVCAN. The UC4H UartBridge node provides two UART ports (this limit is imposed by the hardware of the used STM32F103T8/C8/CB chips).

TOOLS Required:

Upload BetaCopter on your Flight Controler :
Select the ‘u’ variant from the binary files and update the firmware of your flight controler using Mission Planner (Load custom file)

STEP 1
Build the UC4H SLCAN Adapter and flash it with the latest release
/uavcan4hobbyists/firmware/binaries/uc4h-slcan-v009.hex (or bin)
!!Note, you need to specify the extension when using the STM flashing tool in order to see the files!!

If you are using the CP2102, you need to patch the driver in order to get the correct speed, look here:http://www.olliw.eu/storm32bgc-wiki/How_to_configure_CP2102_USB_adapters_for_high_baud_rates

Next you can connect to the flight controller - PixHawk in this project- and enable the CAN as showned in @mike blog: Configuring Ardupilot for UAVCAN

Then you can connect the SLSCAN tt Flight Controler as showned in the schematic above and launch the UAVCAN GUI Tool , select the port and set speed at 1000000. You should see the initial GUI interface, click on “local nide ID” and you can click on Dynamic Node if you dont see the node 10 , that is default for PixHawk. More on @mike second blog: UAVCAN: CANbus for the rest of us

STEP 2
Build the UC4H UartBridge Node and flash it with the latest release
/uavcan4hobbyists/firmware/binaries/uc4h-uartbridge/uc4h-uartbridge-v007.hex (or bin)

!!!ABOUT THE BENEWAKE TFMINI DATA FORMAT !!!
At the time of this lab I experienced some instability while using the TFMINI in native mode (Binary Output). Using the clear text mode -pix format- , the Node is working flawlessly. There are numerous reference showing how to flash the rangefinder in this mode, just make sure you send this sequence for pix format output 42 57 02 00 00 00 04 06 and that you can read distances as clear text on a terminal @115200baud.

STEP 3
Once complete you should be able to start node and connect with the SLSCAN in order to set the parameters of node (See picture center below ). Then you start Mission Planner and set 2 of the the 3 Serial Tunnels SERIALTNL according to the Speed , The Channel ID and the signal type = 9 being Range Finder. Finally you set the RangeFinder configuration for the 2 instances using Orient 25 -Looking Down - and type 8 (Lightware serial as we send clear text values from TFMINI as explained above) for the first and Orient 0 -Looking Forward - and type 8 for the second.

You should get readings as “Sonar Range” for the Looking Down and on Mission Planner you hit CTRL-F and select proximity (bottom right) to get the “Radar Screen” for the “Looking Forward” rangefinder.

That’s it, we added 2 serial sensor (with third SERIALTNL still available) and you still have ALL the physical UART available !! :slight_smile:

As a final comment , please note that you can now buy prebuilded and tested nodes (and other models) at low cost from Jdrones Store . Now, any DIY builder can afford to use UAVCAN. This set of boards allows for complete, fully functional UAVCAN drones, with unprecedented features.


OlliW's New UC4H Rangefinder
CANbus for Ardupilot with UAVCAN and UC4H
(mike kelly) #2

Great job and a solution for some people desperate for more ports for sure!


(OlliW42) #3

great report! :+1:
good to see the potential of UC4H and BetaCopter being exploited


(ppoirier) #4

@olliw42 following your test code, I will follow-up with a 3 UART node , probably adding the Cheerson Serial Opticalflow


(MartinKeilloh) #5

thank you for that Patrick great tutorial best to buy parts from jdrone or have you got a link of were to get the parts please


Copter-3.6.5-rc1 available for beta testing!
(ppoirier) #6

Hello
JDrone sells complete units, for building I suggest you google the parts to find the best supplier on your area. I ordered from Banggood, AliExpress, Ebay and Amazon.


(Hugues) #7

Nice tinkering and playground for testing UAVCan. Nice and clear explanation too, Patrick. Thanks for that.

About the whole purpose of this though, I can’t imagine doing this in practice, even on a DIY project, when it involves adding 5 extra electronic boards and extra wiring when the main purpose of UAVCan is supposed to be having simpler builds with fewer parts/wires !


(OlliW42) #8

your counting is, frankly, a bit odd. I mean, if you were to replace the pixhawk by modules of its’s individual components (which e.g. Patrick is known to have done, see his linux builds :wink: ) you also would have plenty of wiring and electronic boards, yet you would not put in question the concept of it … so it is here, you can do that with just one electronic board, the UC4H general-purpose board

the full ease of UAVCAN will come to live only once enough UAVCAN specific sensors are available … which it currently is not (except of few) … so one has to chose: either to wait another millenium or to start now with what’s possible

just remind you how the first MultiWii copters looked like …

gladly people didn’t got distracted by such arguments :wink: (and gladly people were faster moving than AP on CAN matters)


(ppoirier) #9

Thank Hugues,

I agree with you that this setup is a little bit clumsy and I know you know that this is a technology demonstrator.

Please take a look at jDrones nodes , they are pretty neat and they offer some standardized connections and cabling.

I tried to demonstrate that UAVCAN can be used as a viable technology that is affordable and easy to implement, allow me to fine tune my next projects and I am pretty certain you will be interested exploring this technology on one of your build


(Hugues) #10

I will take a look at the JDrones nodes and might get convinced :slight_smile:


Running out of serial connections
Port hog: buzzer
(ppoirier) #11

Just received my UC4H from jDrone http://wiki.jdrones.com/can/gennode , thanks for the fast delivery :slight_smile:

Loaded one GenNode with Notify firmware.
“Show your autopilot status on UAVCAN connected 0.96“ OLED board.”

Loaded the other GenNode with UartBridge and installed 2 x TFMINI.
Please note the large capacitor of 470 uF (actually it is a little oversized , but that’s all I had on the bench) to prevent current surge at startup as the GenNode has a build-in resettable picofuse that is shutting down if inrush current is too much. Bear in mind if you plan to use these type of devices as the TFMINI draws 80mA each nominal (you can double for inrush). Alternatively you can use a separate source of power to feed the node, you then need to connect the supply to the devices directly (there are some external power feed connection options on the Gen Node) and keep common grounds.

Additional notes on the picture above:

  • The power supply is an external regulated 2 Amps AC adapter for bench testing.
  • The power is not connected to CAN of Pixhawk as we keep the ‘‘exclusivity rule’’ = just on source of supply.
  • The pixhawk internal regulator is sharing its output of 2A (nominal 1.5) to all peripherals and I personally would not recommand using it, a dedicated UBEC being best.
  • The balance line is terminated both ends : One end to the internal resistor of PixHawk, the other end is a terminator block connected to the SLCAN module.
  • All these are in conformance with techniques of Balance Lines Distribution (see below)

Here is a little schematic from TI (http://www.ti.com/lit/an/sloa101b/sloa101b.pdf)
image

Think of it when you plan your CAN installation:

  • Single source of power on the bus (You can use additional power sources to individual nodes)
  • Terminator (120 Ohm) at both ends
  • Adding some noise immunity if the bus gets over 1 Meter (Shielding or else). The supplied jDrones cables have the CAN Bus Lines twisted.

:slight_smile:


(OlliW42) #12
  • The power is not connected to CAN of Pixhawk as we keep the ‘‘exclusivity rule’’ = just on > source of supply.
  • The pixhawk internal regulator is sharing its output of 2A (nominal 1.5) to all peripherals and I personally would not recommand using it, a dedicated UBEC being best.
  • Single source of power on the bus (You can use additional power sources to individual nodes)

I beg for pardon, but I can’t agree with this as a general recommendation.
I would recommend to not draw too many general recommendations at this early stage of exploration. Practical experience with more nodes than 2 may lead to alternative insight.
:slight_smile:


(ppoirier) #13

Olli , these rules will not change = The datalines must be balanced and a single source is a general power supply rule.
Do you have reserves on specific issue ?


(OlliW42) #14

The datalines must be balanced

I wasn’t commenting on balanced data lines. Even though I here too have my own opinion. :wink: I use it since 1-1/2 years with just one termination resistor, not paying any attention to balancing, and also not paying any attention to daisy-chaining etc … so I’m doing about everything wrong according to CAN textbooks … but I couldn’t yet identify any issue, and it’s clear to me that the moment there I’ll have an issue because of this will never come (one reason btw I use the TJA). So, on copters, where you generally find short paths, it’s all MUCH MUCH less of an issue. This will be different on planes, though, but with 2 CAN ports it’s going to be all very elegant on planes. It’s as always with these kind of rules written in specs … they are not a must for all applications :wink: And in fact I claim that for most of what we do with DIY copters it’s a nice have and make you feel good, but not a technical necessity. At least that’s my 1-1/2 years experience, and it makes sense too electrical-wise.

a single source is a general power supply rule.

The powering of the CAN bus network in contrast is more delicate then I think you realize at this point in time. It would be all easy if we would use 12 V “board voltage”, but that’s not what we are doing most of the time. We often like to just use the USB for convenience, and at least folks like me got used to just plug in the USB and do things like parameters, calibration, flash, i.e. do what one is normally doing. This won’t be as fluently with more complicated setups, installed on a real copter, for which one wants to do all this without disrupting the copter back to a test-bench setup. It then needs “smarter” power solutions.
(I do not have yet a fully satisfying solution btw, just an “approximation” to it)

my 2 cents on the matter :slight_smile:

I felt it somewhat important to expose this opinion, so that folks don’t get a wrong impression, that CAN would be so difficult to wire and just a tricky difficult beast. In my opinion this is fact:
Even when doing everything wrong with the wiring, CAN is so much more reliable and robust than I2C.
The one thing I also would strongly recommend is to twist the CANL/CANH wires, but this is really easy to do, and with that there is really little which can go wrong (in the cases I’ve outlined)

The powering can need more attention, however, but this is just because the CAN nodes tend to consume more power than, let’s say an I2C magnetometer. (and because of the safety measures taken by 3rd generation CAN transceivers)

:slight_smile:


(ppoirier) #15

Olli,
What I wrote above is a sort of wiki, with standard engineering rules so that ultimately, I will be able to give support and refer users to the textbook.

I think that experienced builders like You and Me can make anything work even if it defy the textbooks… Call me a “Serial Builder”, because once a system or vehicle is build and demonstrated , I get bored and I look for the next project…


(jpkh) #16

@ppoirier for future power issues. there are few new boards brewing up that can be used when higher current consumption is needed. Gen.Node is mean for as you know, general use and hacking for different things. Olliw’s Gen.Node is a wonderful small board that allows you to do many things.

Keep up the good work :slight_smile:


(OlliW42) #17

I understand this, yet … I take the liberty of a different opinion

I think that any wiki would benefit if it would give more practical advices than just the standard rules. Especially if the wiki wants to guide also non experienced builders.

for instance, in your shown setup you have interrupted the CAN5V line at the pixhawk. It’s surely a skillful test setup, but not general. In some sense it’s against the rules. Also, it might not be the optimal approach, at least from a practical pov. Consider e.g. having a mag in addition, which you would want to calibrate. Now consider the alternative powering scheme, where the CAN5V of all nodes are connected as normal, but where only the rangefinder 5V’s are connected to the external BEC (all grounds of course connected). You now would be able to do the mag calibration with just plugging in the usb, as usual. In your scheme one always has to power up everything and take care of the pix. Now let’s consider that you in addition have a mavlink bridge which allows you to configure the node parameters from within MissionPlanner (e.g.), in “my” scheme it would nicely work with just a USB connection. And so on.

Btw, the UC4H general purpose node nicely supports this alternative scheme. You could have soldered the rangefinder’s 5V to the 5Vext pin on the left, and the BEC to the 5Vext pin on the right. This would also be advisable from the power-surge perspective, since the power surge wouldn’t affect the CAN5V line, and thereby other nodes.
(I would wish the Dronecode standard plug would have had 5 (or 6) pins … IMHO a clear example of drafting standards without much experience in the back)

Clearly, you of course didn’t suggest to disconnect the CAN5V on the pix as recommendation, we understand that this was just a quick for doing the test. However, you’ll notice that this isn’t really relevant to what I just outlined, what I just outlined was a practical example against the “one source” philosophy.

In short, I would come to a significantly different set of recommendations.

And I come especially to the recommendation that it’s maybe not optimal to write down too many recommendations at this early stage of exploration :slight_smile: . Non experienced builders may take them more seriously than the should be taken.

(e.g. it’s not even clear if what I’ve just outlined is actually the “best” recommendation, I could see others, IMHO one still has to see what eventually works best for most)

as before, and as always, just my personal opinion about what I would do
(and I think I have said enough on this, so will TO :slight_smile: )


(ppoirier) #18

Thanks Olli , that makes lot of sense, I appreciate your input on this matter.


(ppoirier) #19

After more reading, it becomes pretty obvious that my guidelines do not comply with UAVCAN
https://uavcan.org/Specification/8._Hardware_design_recommendations/

The Micro connector is based on the proprietary JST GH 4-circuit connector type.

The suitable cable types are flat or twisted pair #30 to #26 AWG, outer insulation diameter 0.8—1.0 mm, multi-strand. Non-twisted (flat) cables can only be used in very small deployments free of significant EMI, otherwise reliable functioning of the bus cannot be guaranteed.

The CAN physical layer standard that can be used with this connector type is ISO 11898-2, also known as high-speed CAN.

Devices that deliver power to the bus are required to provide 5.0—5.5 V on the bus power line. The anticipated current draw is up to 1 A per connector.

Devices that are powered from the bus should expect 4.0—5.5 V on the bus power line. The maximum recommended current draw from the bus is 500 mA per device.


(jpkh) #20

I have some TFMinis incoming. After received those. I can look and create a dedicate board for TFMinis. @ppoirier let me know if you have any other requirements than just “connector” compability