uavcan in ardupilot master

[Andrew Tridgell]

Hi All,

Over the last couple of days I have pushed changes to enable uavcan
support in ardupilot master. It is also now enabled in the autobuilds.

The uavcan support is based on the tremendous work by Pavel Kirienko,
helped by others from the PX4 team. Also many thanks to Holger Steinhaus
for his great work on ardupilot integation.

See this site for more information on uavcan:

http://uavcan.org/UAVCAN

If you are building ardupilot yourself then to enable uavcan you will
need to clone the uavcan repository into the same directory that you
have your ardupilot, PX4Firmware and PX4NuttX trees. So do this:

git clone git://github.com/diydrones/uavcan

In the future we will move to using git submodules to make for easier
integration with these external trees and automatic updates. I'll send a
message to the list once that is ready.

So far we have only tested uavcan ESCs, and specifically the px4esc (an
experimental uavcan ESC). It has been test flown both with copter and
plane. If you have a px4esc setup then note that for now you will need
to connect to each ESC with a serial cable to configure the ESC number
(motor number) and the canbus node address. We hope to automate the
configuration more in the future. If you fly with px4esc then you will
get ESCn dataflash log messages giving the voltage, RPM and current of
each ESC at 10Hz.

Support is also in the tree for uavcan gps, magnetometers and
barometers. We haven't tested these yet, but hope to test them soon
using this combined module:

http://zubax.com/product/zubax-gnss

uavcan in ardupilot is still considered experimental, but we expect to
be using more and more uavcan devices in the future. The robustness and
flexibility of canbus is a huge step forward over I2C.

Right now we only support uavcan on Pixhawk, but we hope to support it
on Linux based boards in the future. The uavcan project includes drivers
that work on Linux, and the PXF cape for BBB has a canbus connector, so
we just need to work out some driver and integration issues to add
support for uavcan to the Linux ports.

Thanks again to Pavel for his pioneering work with uavcan!

Cheers, Tridge

[Jaime Machuca]

This is great news! I will start testing this ASAP.

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Craig Elder]

Thanks Pavel, Lorenz and Tridge.  This is great work.

[Roberto Navoni]

Fantastic work Tridge and Holger ,too :)

[Glenn Gregory]

Great work guys! I have a Zubax GPS on the way so looking forward to testing this and contributing.

[Holger Steinhaus]

Hi tridge,

thanks for all the work collecting up all puzzle pieces and integrating them in a clean and tidy fashion. This part was not easy going, as the native PX4 firmware has moved on significantly in the time we were working towards 3.2. Big thanks to Pavel and Lorenz again - the firmwares, drivers and UAVCAN itself really work great and the clean and well-documented APIs make it easy to use them. I am looking forward to the day where PWM RC and I2C signals will be history in our UAVs.

During the last days, I did a lot of flying with my UAVCAN copter (ESCs and GPS), without too much trouble so far. From my point of view there are the following open issues: 

 - when raising the gains, the resulting oscillation still looks a bit atypical

 - Motor feedback: ESC temperature not implemented yet, reported current is the phase current during motor PWM on, not the average current of the ESC

 - GPS: sometimes a wrong time is reported - logs might get a date in future or past (I'm on it)

 - baro: not yet supported, as APM still lacks second baro support (some parts missing for read() interface in PX4/Firmware as well - but fixing this is rather trivial)

What we need most now is lots of testing - I would like to encourage anybody to try UAVCAN as soon as the ESCs are generally available.

Regards,

  Holger

[Andrew Tridgell]

Hi Holger,

> - when raising the gains, the resulting oscillation still looks a bit
> atypical

definately worth looking into some more. Could you try hooking up the
same ESC via PWM and see if it shows the same issue? You should be able
to combine PWM ESCs and uavcan ESCs at the same time. If you had a tacho
and properly calibrated both ESCs then you should get the same rotation
rate on both. Revving up and down may let you notice any delays.

> - Motor feedback: ESC temperature not implemented yet, reported current is
> the phase current during motor PWM on, not the average current of the ESC

ok, should be fixable.

> - GPS: sometimes a wrong time is reported - logs might get a date in
> future or past (I'm on it)

thanks. I'll be very interested in what the GPS velocity numbers look
like in turns on a fixed wing.

> - baro: not yet supported, as APM still lacks second baro support (some
> parts missing for read() interface in PX4/Firmware as well - but fixing
> this is rather trivial)

I'm part way through doing this change. Just need to find some free
hours to finish it.

> What we need most now is lots of testing - I would like to encourage
> anybody to try UAVCAN as soon as the ESCs are generally available.

yep!

We also need code for making configuration easier. Have you looked into
whether we could automatically change the canbus node IDs?

Cheers, Tridge

[Pavel Kirienko]

Tridge, Holger,

> Have you looked into whether we could automatically change the canbus node IDs?

Here's some information on the automatic enumeration feature:
http://pixhawk.org/modules/px4esc#uavcan
https://github.com/pavel-kirienko/uavcan/blob/master/dsdl/uavcan/protocol/560.EnumerationRequest.uavcan

[Andrew Tridgell]

> Here's some information on the automatic enumeration feature:
> http://pixhawk.org/modules/px4esc#uavcan
> https://github.com/pavel-kirienko/uavcan/blob/master/dsdl/uavcan/protocol/560.EnumerationRequest.uavcan

ahh, thanks, that doesn't look too hard.

Is there a way to broadcast a msg to ask all ESCs to reset back to
passive mode and go into this mode? That may be useful if you need to
retry the configuration.

No we just need a MAVLink command to trigger the automatic enumeration
sequence, with prompts to the user to spin each motor in turn.

Cheers, Tridge

[Pavel Kirienko]

Tridge,

Is there a way to broadcast a msg to ask all ESCs to reset back to
passive mode and go into this mode? That may be useful if you need to
retry the configuration.

No, service requests can't be broadcasted by design. The sequence can be like that:

- Detect what nodes are present in the network

- Detect which of them are ESC, there are two ways to do so:

-- Query the service GetNodeInfo and see if the node name string contains "px4esc" (assuming that you're interested only in this particular ESC)

-- Or, check if they are subscribed to uavcan.equipment.esc.RawCommand by means of querying uavcan.protocol.GetDataTypeInfo (this works with any ESC).

- Reset all detected ESC

- Perform the enumeration

Note that this is a highly generic approach that allows one to work with specific nodes only; e.g. an unrelated device like Zubax GNSS would be unaffected by the ESC configuration procedure.

Pavel.

[Holger Steinhaus]

Hi Tridge 

 

>  - when raising the gains, the resulting oscillation still looks a bit
> atypical

definately worth looking into some more. Could you try hooking up the
same ESC via PWM and see if it shows the same issue? You should be able
to combine PWM ESCs and uavcan ESCs at the same time. If you had a tacho
and properly calibrated both ESCs then you should get the same rotation
rate on both. Revving up and down may let you notice any delays.

Unfortunately my RPM logger is limited to one channel, and I would expect the differences in the ms range. Do you have a chance to do that with APM:Plane? It is rather hard to get Copter to output equal values of thrust. I don't have a working plane setup yet (allthough a foam plane in the garage is already waiting and flying planes is quite familiar to me ;) ).

 

>  - GPS: sometimes a wrong time is reported - logs might get a date in
> future or past (I'm on it)

thanks. I'll be very interested in what the GPS velocity numbers look
like in turns on a fixed wing.

Just fixed the system time issue: https://github.com/diydrones/ardupilot/pull/1642 

 

>  - baro: not yet supported, as APM still lacks second baro support (some
> parts missing for read() interface in PX4/Firmware as well - but fixing
> this is rather trivial)

The PX4/Firmware part is Implemented now, see https://github.com/diydrones/PX4Firmware/pull/22 . Please consider that this code is absolutely untested, but a similar approach works well for the mag. It might also be missing important features (oversampling, averaging).

Holger

[David Pawlak]

This is great, can't wait to get a hold of some of those ESCs.... Early 2015 they say?

[Pavel Kirienko]

David,

> Early 2015 they say?

Yes.

Pavel.

[Andrew Buck]

Hi,

I'm trying to use UAVCAN with Pixhaw, but I'm confused. The PX4Firmware seems to have a git submodule  link to the uavcan library in its uavcan module. Howevever, that library doesn't compile. I get errors involving undefined references to the c++ versions of standard c libs: "/opt/gcc-arm-none-eabi-4_9-2014q4/arm-none-eabi/include/c++/4.9.3/ctime:69:11: error: '::ctime' has not been declared  using ::ctime;"

I'm able to build the uavcan lib separate by using cmake, but I'm not sure how to enable the functionality in ardupilot and I don't understand how the PX4Firmware submodule relates to it.

Thanks for your help.

-Andrew

[Pavel Kirienko]

Hi Andrew,

Please post the full build log here, and describe your environment.

Thanks,

Pavel.

[Andrew Buck]

Ok, my question is a bit broader than just the compiler errors. I'm confused about the different between https://github.com/pavel-kirienko/uavcan and https://github.com/diydrones/uavcan. Or more generally, does the PX4Firmware project need to have the uavcan source code in its lib directory at all if I build the lib separately using cmake, as descriped in the readme? Once I've build the lib, how do I enable it with ArduPilot?

My current build log is attached. I can get the compiler errors to go away if I include the c versions of the include files, such as <time.h> instead of <ctime>, but even if I get it to compile by making those changes, I don't understand how to actually enable the usage of UAVCAN.

Thanks,

Andrew

[Andrew Buck]

Oh, I forgot to say that my build environment is Ubuntu 14.10 with the arm-none-eabi 4.9.3 toolchain.

On Monday, March 23, 2015 at 2:39:10 PM UTC-7, Pavel Kirienko wrote:

[Holger Steinhaus]

Hi Andrew,

I just tried to build a clean (freshly cloned from diydrones/*) environment, using gcc 4.9.3 20141119 on CentOS 7.0 64bit.

These were my steps:

mkdir foobar; cd foobar

git clone https://github.com/diydrones/PX4NuttX.git

git clone https://github.com/diydrones/PX4Firmware.git

git clone https://github.com/diydrones/uavcan

git clone https://github.com/diydrones/ardupilot.git

vi PX4Firmware/makefiles/toolchain_gnu-arm-eabi.mk 

> change frame size limit to 3072 (line 141)

cd ardupilot/ArduCopter/

make configure

make px4-v2-upload

The build is running without issues here. After uploading and connecting to the debug console, the output of "uavcan status" indicates that UAVCAN is up and running.

I guess something is wrong with your build environment or one of your components is following a different branch or repo.

Holger

[Andrew Buck]

Thanks, Holger! That worked for me. What had confused me, was this file: https://github.com/PX4/Firmware/blob/be0cdd6c6f979d61c536668de4c68751d49a4d1f/.gitmodules. Which led me to believe that the uavcan repo needed to be cloned inside the PX4Firmware src/lib directory and added as a PX4Firmware module, which wasn't working correctly. I appreciate your help.

[Holger Steinhaus]

PX4/Firmware switched to git submodules a few months ago - this change has not (yet) made it into diydrones/PX4Firmware. Currently you need to go the way described above and clone (and update) diydrones/uavcan manually.

Holger

[Andrew Buck]

Thanks, Holger. That makes sense. I'm sorry to keep asking questions, but I'm excited to get UAVCAN working and I'm running into problems. Once I've set the output mode to uavcan_esc, UAVCAN is running, and I've armed the actuators, is there anything else I have to do to get the Pixhawk to start sending CAN messages? I'm following this page: https://pixhawk.org/firmware/apps/uavcan, but I must be doing something wrong. Also, does UAVCAN work in passthrough mode?

Thanks again. I really appreciate all you help.

-Andrew

[Holger Steinhaus]

You should differentiate strictly between ArduPilot/ArduCopter on Pixhawk and the Pixhawk native flight stack. The native stack (described under pixhawk.org , disscussed here: https://groups.google.com/forum/#!forum/px4users) is following a different approach for configuration. When talking about ArduPilot, the ESCs should respond as soon as they got configured to an unique node id and a valid esc id (0..3 for quad rotors) and the cabling is right (remember the termination!).

If it still doesn't work, I would suggest to connect a debug console to UART 4/5 and to post boot messages plus the the output after entering the command "uavcan status". Do not forget to power from battery, otherwise (e.g. when powerd via USB) the ESCs don't get supplied.

 

 

Also, does UAVCAN work in passthrough mode?

I don't think so. Currently I am also not aware of any other UAVCAN actuators than ESCs. 

BTW, I am flying a small quad equipped with UAVCAN ESCs and a GNSS/baro/mag combo module (with both ArduCopter and the native stack). Works great, the technology really has the potential to simply things significantly in our drones.

Holger

[Andrew Buck]

Ok, since I'm using Ardupilot, I guess what you're saying is that I don't need to set OUTPUT_MODE for UAVCAN to work, correct? I'm in the process of creating my own UAVCAN node and for now, I simply want to see CAN messages coming out of the Pixhawk, but I'm not able to.

When I asked about passthrough mode before, maybe I used the wrong terminology. My question is can you calibrate ESCs when using UAVCAN by passing the throttle position directly to the ESCs rather than having it go through autopilot logic. When I said passthrough mode, I meant ESC calibration mode.

My boot log is attached. I noticed this in the uavcan status: "ESC output: -1000 -1000 -1000 -1000". I'm new not only to UAVCAN, but also to Ardupilot, so there's likely some step I'm missing.

I completely agree with you about the great potential of UAVCAN. 

-Andrew

[Holger Steinhaus]

Hi Andrew,

your boot log is looking absolutely ok - UAVCAN seems to be up and running. I would definitely expect to see valid RawCommand messages to appear on the CAN bus. If they don't, I see two potential reasons:

1. As you mentioned you are new to Ardupilot, maybe there is some arming or other configuration problem. To rule that out, you should probably connect a few conventional RC servos to the lower PWM outputs of the Pixhawk to make sure that Ardupilot is producing the output signal that you expect. Don't forget to provide power to the servo rail for this test (not needed for UAVCAN-only output).

2. Something is wrong with cabling, test setup or the Pixhawk PCB itself.

Holger

[Ricardo 曹嘉誠 IACT Tsao]

Hi guys :

Is it possible to port the px4esc firmware to run on ESC32 hardware?

the esc32 have i2c, pwm, can supported.

I just want to know ...Is there anybody doing this porting?

[Tom Pittenger]

Not that I know of, although the stack protocol used for ArduPilot and PX4 is UAVCAN. Perhaps the question is does the ESC32 project support this new and up-and-coming protocol? There will surely be more products with UAVCAN soon. The long term plan for Ardupilot is to ditch analog PWM as much as possible and CAN plays a large part in that.

[Andrew Buck]

Thanks, Holger. I've got it working now. It turned out to be a CAN bitrate issue.

[Andrew Buck]

Can anyone explain to me how the ESC RawCommand message works with an octocopter? Each motor's command is 14-bits and with eight motors that comes to 112 bits, but the max CAN data length for a single message is 64 bits. For a quadcopter, the data fits in a single message, but not with an octocopter. I'm trying to follow the code through, but I'm having trouble seeing what happens in this scenario.

[Pavel Kirienko]

Andrew,

In the case of an octocopter (or anything that has more than 4 motors) the message will be split into two (or more) CAN frames, and then it will be re-assembled back into one entity on the receiving side. See http://uavcan.org/CAN_bus_transport_layer_specification for details.

Pavel.

[Andrew Buck]

Thanks, Pavel! That's very helpful. I'm new to CAN in general and I didn't know about multi-frame transfer. I'm glad to know that this issue will be taken care of automatically and it's not something I need to do anything manually to address.

[Andrew Zaborowski]

Hi everyone,

I'm new to ArduPilot. I see a mention of a tree that can send ESC
commands through CAN in this thread. I started playing with the APM
code yesterday with a goal of adding support for I2C ESCs. I notice
the assuption that ESCs talk PWM and only PWM is quite widespread in
the code but I see a non-invasive path to make it configurable --
basically make AP_Hal::RCOutput as subclass of a simple abstract class
and then only modify AP_Motors to use pointers to that abstract class
instead of hal->rcout directly. Is there a tree that already adds
this flexibility, possibly in a different way?

Also Andrew Tridgell wrote:
> The robustness and
> flexibility of canbus is a huge step forward over I2C.

Could you expand on the benefits?

The I2C protocol that can by enabled in the popular SimonK ESC
firmware even on $10 ESCs seems to work well, is fast, the electrical
connection is trivial (no need for termination) and addressing is
easy. Here's a 12 line description of the protocol:
https://github.com/balrog-kun/tgy/blob/master/tgy.asm#L1358-L1370

Many thanks

[Tom Pittenger]

The biggest benefit of going to CAN for things like servos and ESCs is a bidirectional data link. Servos can tell you actual angle instead of just the commanded angle, and escs can tell you rpm, current draw ect instead of just commanded PWM. If an I2C link is added it, I would hope it includes similar features.

-TomP

[Andrew Zaborowski]

That's also true for I2C, hence why I wonder what is brought in by CAN.

Typical RC-hobbies ESCs have no easy way to measure current but they
can tell you the magnetic RPM, voltage, often the temperature and do a
health-check to tell you which motor coil or FET isn't doing well.

Many thanks

[Craig Elder]

>>>> flexibility of canbus is a huge step forward over I2C.
>>>Could you expand on the benefits?

The I2C protocol was designed for chip to chip on board communications to a maximum cable length of 10cm.  We routinely violate the 10cm maximum length and most of the time get away with it.  The key word is most of the time.  I2C is not an appropriate communication protocol for the distances and noise that we typically deal with on these vehicles.  CAN is designed for board to board / module to module communications and is much more noise immune than I2C.

[Andrew Buck]

I'm trying to add a new UAVCAN message that will be sent by a new node I'm creating. I'd like the data from this message to be available in the telemetry stream in Mission Planner. I've added the Mavlink message and I see that message being received by Mission Planner, but I'm struggling trying to populate that message with the data from the UAVCAN message. I've added a dsdl file and I see the generated code from that. I'm also able to log the frame arriving in the uc_dispatcher handleFrame() method, but I can't get the data from there to the Ardupilot library. The layers of publshing and subscribing and the templating are making my head spin. I'm trying to use the node status monitor as my reference, but even then, I'm not sure how to get the data into the Ardupilot library. Can I publish it using ORB directly from the uavcan library or do I need to pass it to the PX4Firmware library first and then publish it to ORB from there? If so, how do I get a pointer to the dispatcher class from PX4Firmware to register for that data type ID?

Thanks for any help anyone can provide. I'm really struggling here.

-Andrew

On Friday, April 3, 2015 at 1:17:53 PM UTC-7, Pavel Kirienko wrote:

[Pavel Kirienko]

Hi Andrew,

First of all, please read libuavcan tutorials available on the UAVCAN documentation website: http://uavcan.org/Libuavcan_tutorials. Pay particular attention to the following ones:

- http://uavcan.org/Libuavcan_tutorials:_Writing_a_simple_publisher_and_subscriber

- http://uavcan.org/Libuavcan_tutorials:_Defining_custom_data_types

I believe this will answer most if not all of your questions.

Then, your task can be solved roughly like that:

1. Define a custom DSDL definition and make sure both your nodes can build against it correctly. You will need to add a path to your DSDL root namespace (i.e. the directory where your DSDL definition is located) on this line: https://github.com/PX4/Firmware/blob/master/src/modules/uavcan/module.mk#L78, e.g.:

$(info $(shell $(LIBUAVCAN_DSDLC) $(UAVCAN_DSDL_DIR) $(PX4_LIB_DIR)/your_namespace))

2. In the PX4 application, you'll need to create an object of class uavcan::Subscriber<your_namespace::YourDataType>, and provide a callback for it that will be invoked by libuavcan automatically every time a new message of your type is received. Please refer to the tutorials I linked above for detailed description of how to do that.

3. In the callback you'll need to populate your MAVLink message with the received data and send it to the MAVLink channel.

That's it. If you have any questions concerning libuavcan or UAVCAN in general, don't hesitate to post to https://groups.google.com/forum/#!forum/uavcan.

Pavel.

[Andrew Buck]

Thanks, Pavel. I had only looked for tutorials on the ardupilot site. I didn't realize there were tutorials on uavcan.org. After implementing some code based on the tutorial, I'm not getting a callback. I made a post about it on the UAVCAN google group that you suggested I use: https://groups.google.com/forum/#!topic/uavcan/BKsqGmocLVc

[Andrew Buck]

I needed to have UAVCAN support while using Ardupilot 3.2, so I backported it to version 3.2, both for the PX4Firmware project and ArduCopter. I have a version now that runs and sens UAVCAN messages, however it seems like setup() in ArduCopter.pde isn't getting called now. I'm having trouble figuring out how it normally gets called. Can anyone point me in the right direction?

Thanks!