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
Comments
I'm looking at following up and working on this for a project, is there still any interest or work being done on this here?
Now I remember the limitation of being connectionless:
No messages can be longer than the CAN data packet.
A data packet longer than a CAN packet has to be split over many CAN messages.
With more than one node communicating, the CAN messages could be interrupted.
Therefore, a communication buffer is required for every connection.
In the worst case of a servo might have a connection with autopilot, failsafe, GCS and flight director.
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.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
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
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 Mattyou 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...
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.
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
-
1
-
2
of 2 Next