CAN bus on Micro Air Vehicles - Join the MAVLink discussion

The MAVLink mailing list is currently very actively discussing which route to take to CAN-MAVLink integration. Especially engineers working in their day jobs on ARINC 825 or CANaerospace could bring important feedback to the table, so please share your knowledge.


Google Groups MAVLink CAN discussion


 Since this design will be very likely the reference design not only for the first 2-3 autopilots implementing it, but might also become the DIYDrones community standard, I'd like to invite all potential developers and adopter to join the discussion (on the mailing list please, not in the comments).


Further reading:
http://de.wikipedia.org/wiki/CANaerospace

http://en.wikipedia.org/wiki/ARINC_825

Views: 1771


Moderator
Comment by Roberto Navoni on March 8, 2011 at 7:34am

That is good , Multipilot 32 have a can bus available . So we can implement the protocol interface on it :) Great !! :)

I add this task to Official Roadmap that will be present thusday http://www.virtualrobotix.com/events/mp32-roadmap-presentation-and

Best Roberto

 

Comment by robert bouwens on March 8, 2011 at 12:21pm

it does not make too much sense to map a wireless protocoll into the can space.

we are not going to lift an airbus 350 - or am i wrong :)

i also see no requirement to have multiple can buses on a micro air vehicle.

ok, let's say someone has a octopussy and each arm has two motors.

that is nice amount of nodes on a can bus but still ok. from 32 on i expect noise will be an issue on the bus which will result in some sort of segmenting.

on the other side i expect that a user should not be confronted with the hassles assigning a node id to a specific node. replacement of of a node should also be in such a way that no master degree is required.

here we have other requirements as those driving the arinc standard.

robert

Comment by pixhawk on March 8, 2011 at 1:27pm
This is absolute right Robert, which is also why I wanted feedback from engineers working with the standard - usually those know the downsides best. I think most developers prefer a MAV-specific, small and easy solution. We just should make sure to carefully check to not reinvent the wheel, this is what this is all about.
Comment by robert bouwens on March 8, 2011 at 1:50pm

hi lorenz,

we should start writing the requirements.

areas to cover:

 - address management

 - firmwareupdate

 - motor commands

 - you name it

after doing this we can estimate how many bits are used for commands and opcodes and those 'build' the can id bits. i would opt for can 2.0b because there are already a few devices which cannot handle 11 bits anymore.

 

i am eagerly waiting for a board which has the lpc 11c14 as mcu - this one has build in can drivers ;-)

 

robert

Comment by Matthew Coleman on March 8, 2011 at 2:02pm

Robert, good thought about making this usable.

 

Say the user adds a new servo over CAN.  Many nodes need to know how to get to the new servo.

 How do the autopilot, groundstation and failsafe systems discover the new servo?

 How is the servo assigned a radio channel?

 What happens if the servo must be changed in the field?

There could be a CAN node with several servos and sensors attached.  How would that node be managed?

 

Apologies to pixhawk for having the conversation here instead in the MAVlink discussion group, it just seemed appropriate.

Comment by robert bouwens on March 8, 2011 at 2:49pm

you need an std::can_bus iterator :-)

if you go back to the copter, then the mixer needs to know where to send a motor command.

in essence the mixer needs a service interface to talk with - it needs to establish a relation between mixer output commands and  can bus motor-type commands.

when the mixer is getting operational it searches its clients - aka motor nodes.

 

it would spend a mac address for each can node.

the marriage could be done as:

 - in cli motor setup, pressing elevator up (front motor) -> send marriage request for front motor

 - the user has a magnet (and the can bus client a hall sensor)

 - now all clients see a marriage command but only one 'feels' the magnet - this client now sends his mac address on the bus.

 

this way you could establish a communication between the mixer and the can bus client.

stupid use case ...

robert

btw: the front motor should not send an ack in terms of spinning up the motor - that would be too painfull.

my fingers already do hurt...

Comment by Matthew Coleman on March 8, 2011 at 3:25pm

Nice idea with the magnet.

 

Are you suggesting

  A resources manager in the system that holds the keys to everything onboard?

  The cli programs the node with its logical/radio channel.

 

There are too many different aircraft configurations for an action to determine which node is to be identified.

A slight alternative:

  The cli lists all available nodes.

  A node can be asked to identify itself by lighting a LED.

  Waving the magnet over the node prompts the cli to flag activation.

  The cli could be used to add a human friendly alias to the node for future reference.

 

Multi I/O nodes might still be a problem

Does the node have multiple MACs that it responds to for each function/resource?

  Does the user have to tell the controller what resources the node has?

  Does the node advertise the capability of each resource to the controller?

 

Regards Matt
Comment by robert bouwens on March 9, 2011 at 5:16am

the bus needs to be managed.

you can add dipswitches for all nodes if you like.

then there is no need to think - all is hardcoded.

 

assigning a device to a functionality is easy - you need to process bind and bind response messages.

sw only (blinking leds) leads to trial and error. you just iterate n-times over the bus. or you write a table on a paper showing node address and location.

ehh, what year do we write...

 

multi nodes are easy - add a 'services' supported call - all devices are kean to respond.

generating multiple messages per node is a pain as performance goes down.

 

the bus-iterator provides me with the information needed.

you wanna type a list of nodes within cli?

the iterator tells you what's available.

 

i would suggest a node is passive only.

you might be interested in information about the load. this would be dynamic.

the resource controller would tell a device to send the current load in a given interval.

 

not really difficult - just logical steps.

you are still confronted with the usual problems like having 3 motor controllers on the bus and 4 are needed for a quad copter.

 

in essence the resource controlle has an array of n-devices providing:

 - short address (each node will query for a address at startup time)

 - device capabilities (all service supported by this device, a simple bitmap)

 - services binded (front motor, back motor ... )

 - status (what ever needs to be coded)

 

regards

robert

Comment by robert bouwens on March 9, 2011 at 7:10am

streaming support

can is connection less - but not everything is connectionless in the real world.

any node could ask another node to 'open' a data channel for streaming purposes.

the 'ack' from the other node would include a channel-number which will be part of the last few canid bits.

that way multiple channels could be opened to 'stream' data.

robert

Comment by Matthew Coleman on March 9, 2011 at 12:59pm

Some form of hardware based identification would be easiest.  If the node is too small it will have to be set in software or EEPROM, no big problem.

 

The scanning iterator makes sense.

The supported services make sense.

 

The following statements are my opinion right now.  I could change my mind in the next 10 minutes.


I disagree a little about connections:

For a basic autopilot system, dynamic node connections are not necessary.

  It is enough for sensors to broadcast data at regular, pre-programmed intervals.

  It is acceptable for actuator commands to be broadcast without knowing what will use the command.

  Some form of connection status monitoring is required.  This is quite easy.

 

I disagree about an autopilot system having to request sensor data.  It seems a waste of bandwidth.  The sensor should be automatically sending time stamped data.

 

I agree with connections:

Ad hoc connections from a GCS are necessary.

A mechanism for asynchronous read from or write to a node is necessary.

If there is ever more than one CAN network, the destination must be known if messages are to cross between CAN nets.

 

Ad hoc connections may not need to extend through to every CAN node.  Is it possible for the MAVlink telemetry interface processor to maintain the connection? It would then translate the messages onto its CAN subnet.

 

I am going to have to write code to support my own CAN project.  I would very much appreciate keeping this simple.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service