Version 2 project launched

[Crashmatt]

Now launching version 2 of the interface board.

Tha mission of the project in priority order:
1. Capable of offloading telemetry communication from UDB3/4 to the
interface board.
2. Smaller (target 50 * 30mm)
3. Build a small number of prototypes for a few users
4. Improve robustness
5. Better access to ADC channels

Features to add
Protection resistors on all input/output channels
Onboard linear voltage regulator for the processor (TBD)
Status indicator LEDs
4 layer board to reduce size
Mini ICSP programming connector
Reduced servo connector pitch (0.15" to 0.1")
Reduce size of all board connectors.

Possible features to add
An extra input channel
More output channels

[Riccardo Kuebler]

Hi Matt,

I'm very interested in this project, so take me in account.

Best regards,

Ric

2010/9/15 Crashmatt <crash...@hotmail.com>

[Crashmatt]

Thanks Ric

Please let me know what you prefer on the connectors and what are
critical features for you.

I am looking at the molex connectors that pete suggested but the
cables are very expensive or difficult to construct.

Regards Matt

[Riccardo Kuebler]

Hi Matt,

in principle my goal is to minimize cable amount on plane, increase channels input and output (but this means having the UDB firmware using them too).

About connections I prefer standard 0.1" connections. I already have plenty of tools and connectors to crimp them, from 1 up to 8 poles. For connecting the transceivers what about using JST connectors ? There are some dimensions and they are generally available. Here too I already have tools and connectors. Generally I prefer bigger connectors (like servos connectors). They are more sure and easy to manage, isn't it. I don't like very much things like GPS connectors, camera tiny connectors etc. They seems so fragile to me and I am not so sure about their connection safety. Video link is vital as it should be transceivers link.

But anyway I will be happy with anything you decide to use and anyway I'm still trying to understand which is the real potential of this system, other than servos number (extra sensors like magnetometers, rpm, A meter etc ? telemetry ? video link, I'm an  ?)

Thanks and best regards,

Ric

2010/9/15 Crashmatt <crash...@hotmail.com>

Thanks Ric

[vwyoda]

On Sep 15, 12:30 am, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Hi Matt,
>
> in principle my goal is to minimize cable amount on plane, increase channels
> input and output (but this means having the UDB firmware using them too).
>
> About connections I prefer standard 0.1" connections. I already have plenty
> of tools and connectors to crimp them, from 1 up to 8 poles. For connecting
> the transceivers what about using JST connectors ? There are some dimensions
> and they are generally available. Here too I already have tools and
> connectors. Generally I prefer bigger connectors (like servos connectors).
> They are more sure and easy to manage, isn't it. I don't like very much
> things like GPS connectors, camera tiny connectors etc. They seems so
> fragile to me and I am not so sure about their connection safety. Video link
> is vital as it should be transceivers link.
>
> But anyway I will be happy with anything you decide to use and anyway I'm
> still trying to understand which is the real potential of this system, other
> than servos number (extra sensors like magnetometers, rpm, A meter etc ?
> telemetry ? video link, I'm an  ?)
>
> Thanks and best regards,
>
> Ric
>

> 2010/9/15 Crashmatt <crash__m...@hotmail.com>

>
> > Thanks Ric
>
> > Please let me know what you prefer on the connectors and what are
> > critical features for you.
>
> > I am looking at the molex connectors that pete suggested but the
> > cables are very expensive or difficult to construct.
>
> > Regards Matt

Hey Matt to answer your questions about the overo the daughterboard
the overo is hooked up has a i2c or CANbus connection, I can go either
way there really is no different needs that what your already planning
do to with the UDB :) Thats why I was excited to read about it as it
seemed like a simple solution, that I could make work and have my
overo do all video and camera tracking with the DSP. There is already
6 PWM outputs on the daughterboard and working over the code a little
should be easy to make it work with the linux it runs onboard. Though
I would have to use a logic level converter to drop it down to 1.8v
for the overo. Though I would say the CANbus connection should have
its own ground. If you need to know any other specifics about anything
please let me know and I can be more detailed, but from what I have
been reading I do not think there is any real issues other than me
getting the code to work with the overo instead of the UDB on the one
for the overo. And hey if it takes a long while for me to figure it
out no worries :) Part of the fun.

Thanks
Jeremy

[tshado]

Hello Matt,

I have an UDB2 board
I started to learn an it will be installed in my first UAV (Skywalker
airplane)
You have a very nice project !
I am interested by your project and would like to get one of your
version 2 Interface board

Best regards,
Jean-Claude

[Crashmatt]

Ric,

Thanks for the direction on this.

I do not really wish to specialise the board much beyond the servo
interface function. There are too many options for different setups.
Modification becomes a problem if more functions are integrated.

If the board breaks out as many connections as possible, people can
add on however they need to.

I agree about those little connectors. I dont know if anybody is
having a real problem with them. Do you know if anyone is having
problems with the GPS connector failing?

If you are thinking of the charger/balancer JST connectors, they are
on 0.1" pitch so they do not save any space. Is there a different JST
connector you are thinking of?

Regards Matt

[Crashmatt]

[Crashmatt]

Jeremy,

I think we should aim to use CANbus if possible. There is only one
I2C on the interface board processor. Mixing the I2C between the
critical servo communication and other sensors does not feel like a
good idea.

CANbus has a wide common mode operating range. The standard is -2V to
7V but many tranceivers have a wider range. There is no real need to
connect a specific ground for CAN which would add another ground loop.

The size has expanded to 55mm*35mm. It looks like I can fit in most
of the digital connections but no analog measurement channels.

Regards Matt

[Crashmatt]

Jean-Claude,

Please tell us a little more about your project. I am interested to
know your requirements for the servo interface.

Regards Matt

[tshado]

Hello Matt,

I plan to add later more servos to my UAV that's why I am interested
by your CAN RC servo interface.
The feature to add other sensors on a reliable bus is also a key
feature.
Finally I plan to connect to the UDB through your Interface a Linux
Embedded Board.
I am evaluating a SBC with an IMX27 from Freescale which can have a
CAN bus controller (MCP2515) and a 3,3V Transceiver (SN65HVD234)
If you would like more details don't hesitate to ask.
This Linux could be used for IP Video downlink as IMX 27 has a
hardware built in camera-interface.
Jeremy is doing a great job with the Gumstix overo/Open Embedded
linux , but I miss his software skills...

Concerning the servos interface, standart connections 0,1" (like UDB
V2) connectors is fine with me.

I would like to ask you some questions :
- for UDB2/UDB3, what is the easiest way to connect a CAN
transceiver ?
-do you recommand MCP2551 ( discussed by Adan if I remember ..)
-what do you mean by "better ADC channels access" in your version2 ?
-I have to learn more CAN bus topology , but is it better to connect
my Linux board to the other CAN Bus interface ?

[Crashmatt]

Jean-Claude,

The UDB4 might solve your servo expansion and sensors problem if you
are willing to wait for it. I would not wish for you to invest
innecessary time on the servo interface if there is an equally good
fix coming soon.

Your MCP2515 should be ok. It is CAN 2.0B compliant so it is
compatible. It looks like the same CANbus module the dsPIC30
processor has.

Most CANbus trancievers will do the job. I used MCP2551 but am looking
for something smaller.

I will be making some small CAN tranceiver boards to go with the
interface so do not worry about this.

UDB2/3 CANbus comes out of the LED status indicators. The PIC CANbus
module overides all other I/O to those pins. Pretty simple.

If you can use the libraries that we write, you will not need to worry
too much about the CANbus detail. Make sure you get involved with
defining what you want it to do.

I had not intended to use CANbus to connect the interface board to the
telemetry or flight director. My plan was to use UART for one simple
reason. My first plan is to use the groundstation to do flight
direction. Once the groundstation software is useful and stable, the
flight director could be transfered to a linux procesor board. If the
communication is through UART, the change will be transparent to the
UDB and interface.

The CANbus message broadcast is quite suited to sending data in any
direction accross the network. We need to be careful to get the
message format right and to keep the bandwidth requirement sensible.

My version 1 prototype had some very limited connections to the ADC
channels. I thought to improve this if possible. Do you think you
need this?

I will sketch out the variations on the communication setup and post
them in the files.

Regards Matt

[Pete]

My main requirements relating to CANbus are :-
1) Immediate: I need more inputs and output for Servos (This I need
for the Cularis with camera targetting because it has 4 flight
surfaces on the main wing).
2) Soon: I would like to reduce the amount of wiring around my
aircraft.
3) Future brainstorming: I want a fast bi-directional link to the
UDB, that can potentially be used by a small in-flight computer.
(probably Overo running Linux).
The flight computer likely to be
a) Receiving
up to 30 frames / second of USB HD Video and
should be combining the telemetry into every frame. Ideally, the
flight computer will be receiving telemetry at 40 times / second. I'm
considering the Mavlink protocol for the UDB to Flight Computer bi-
directional link over CANbus.
The expected transmission rates (and formula) for Mavlink are posted
here.

b) transmitting to the UDB In the other direction.
I expect it may send LOGO. It may also command roll, pitch, and
yaw to the plane
from the in-flight computer. Although I say roll, pitch, and yaw,
I really mean a Direction Cosine Matrix Orientation,
and requested angular velocities in roll, pitch and yaw.
The flight computer may also command throttle and air speed.

I envisage a heart beat protocol between the UDB and the in-flight
computer. If the heart beat fails, then the UDB will
fall back to it's full automatic capabilities. In a failed heart
beat scenario the UDB will probably move to a
a Return to Landing state, if autonomous mode is commanded. In
stabilized and manual mode, the UDB will
act as usual in the normal way.

Best wishes, Pete

[Crashmatt]

Thanks for the inputs Pete.

Please take a look through this linked document. It shows some
possibilities on how we could connect the flight computer (flight
director as I call it) to the interface and autopilot.

http://rc-servo-interface.googlegroups.com/web/Version+2+System+description+-+V02.pdf?gda=AcD8SVkAAADTCbOyoFv9XDIvMOn2bk5zLNGkA1OeX0ctaaZaIblD-R5mgeYCakXbbRK4s-EJXXrIyNzjX5WUOOJz3fqmIZaMaU1s9yUIn5xpR0GfJPiS6oQIqBBuatoZ3GVm6VpieyE&gsc=KEX2qQsAAAAIge0OK6Qyvc-oSJUdTDoT

MAVLink has issues with CANbus because the MAVLink data frame are
variable size where the CANbus frames are limited to 16bytes. This
means a bunch of data splitting and re-assembling may need to be
done. If we can find a low resource solution to this then I am all
for using MAVLink.


Layout is going pretty well. Ric got his way will the 0.1" headers.
It turns out that layout is more efficient with them than little SMD
conenctors.

At the moment, the board does not have a voltage regulator for the
processor. If voltage regulation (4.5V) is critical to you, please
let me know.

Here is the unfinished board layout:

http://groups.google.com/group/rc-servo-interface/web/ServoInterface.brd.pdf

Regards Matt

[Riccardo]

Hi Matt,

there are 1mm, 1.25mm and 1.5mm connectors too, but those are the tiny
camera connectors, or like the GPS ones.

About bad GPS connectors I read only one time from a UDB user about a
oxidized (?) connector.

It depends on which use the connectors are supposed to be. GPS
connector probably is used 10 times in the life of the board. Servos
connectors probably a little higher, power connectors are used each
flight, but I guess this is not a problem for your board. Anyway
normal servos connector seems to be designed for a life of about 100
cycles, not that much.

Connectors are one of the weak point of a circuit, but you sure
already know about this ;D
Personally I would not speculate on this, especially for servos, power
and video (if flying FPV) connections, which are vital, even at cost
of a little bigger board.

Best ragards,

Ric

[Crashmatt]

Ric,

It turned out that the 0.1" connectors took less space to place and
route out than the surface mount connectors.

The board is mostly laid out. Here is a link to the eagle files if
you wish to review it.

http://groups.google.com/group/rc-servo-interface/web/ServoInterface%20V2%20-%20V005.zip

The board is very simple, just the processor, decoupling, resonator
and protection resistors. Features were removed in favour of more
connections.

I might be able to squeeze a 4.5V regulator on if anybody thinks we
need it.

Regards Matt

[Riccardo Kuebler]

Matt,

I'm not able to open the zip folder (damaged).

Could you please check it (or am I doing it wrong ?) ?

Thanks,

Ric

2010/9/19 Crashmatt <crash...@hotmail.com>

[tshado]

Hello Matt,

Thanks for your comments

"If you can use the libraries that we write, you will not need to
worry
too much about the CANbus detail. Make sure you get involved with
defining what you want it to do."

---> you mean I need to define which commands must be executed on
CANbus :
1) From Linux Board Computer to UDB
2) UDB to Linux Board Computer

"My version 1 prototype had some very limited connections to the ADC
channels. I thought to improve this if possible. Do you think you
need this?"

----> I saw that there are 16 Inputs for the 10 bits ADC
No I don't have a special need at this moment.
The other menbers could also give their inputs about that
If wiring and adding a 16 pins connector isn't too complicated it
could be a possible feature

"I will sketch out the variations on the communication setup and post
them in the files."

------->Thanks for that .It will for sure help me to better understand
the CANBus communication priciples


I will read your doc http://rc-servo-interface.googlegroups.com/web/Version+2+System+descr...
It seems to cover what is the best way to attach Linux computer board
to UDB
Using Mavlink protocol and its CGS appears to me a robust technical
solution for using a CGS with UDB if
Canbus can handle the Mavlink messages as you pointed out.

Best regards,
Jean-Claude

On 19 sep, 23:20, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Matt,
>
> I'm not able to open the zip folder (damaged).
> Could you please check it (or am I doing it wrong ?) ?
>
> Thanks,
>
> Ric
>

> 2010/9/19 Crashmatt <crash__m...@hotmail.com>

>
> > Ric,
>
> > It turned out that the 0.1" connectors took less space to place and
> > route out than the surface mount connectors.
>
> > The board is mostly laid out.  Here is a link to the eagle files if
> > you wish to review it.
>

> >http://groups.google.com/group/rc-servo-interface/web/ServoInterface%...

[tshado]

Hello Matt,

I read your document : http://rc-servo-interface.googlegroups.com/web/Version+2+System+descr...
I have some comments for the last part "Summary"
1)In the table, what is the difference between "Yes" and "ok" ? ( I
suppose YES is "stronger than ok...)
2)For last line of the table (correspnding to fig 7)
Flight Director attaches to CANbus2
Telemetry attaches to Flight Director
3)I undestand that 1st and 4th topologies (Fig 3 and 6) are not a good
choice
So remains 3 topologies instead of 2 as written .
I suppose you selected the 2 topologies from fig 5 and 7 , and want to
further investigate them
4)Due to the fact that CANBus is limited to 16 bytes messages, isn't
it easier to use topology from fig 5.
In this case there is only CANbus1 interface between Autopilot ans
Interface.

One more question :
For Drawing (Fig) 7 , can you please explain what means " with some
isolation" ?

Best regards,
Jean-Claude

On 20 sep, 09:52, tshado <kanume...@gmail.com> wrote:
> Hello Matt,
>
> Thanks for your comments
>
> "If you can use the libraries that we write, you will not need to
> worry
> too much about the CANbus detail.  Make sure you get involved with
> defining what you want it to do."
>
> ---> you mean I need to define which commands must be executed on
> CANbus :
> 1) From Linux Board Computer to UDB
> 2) UDB to Linux Board Computer
>
> "My version 1 prototype had some very limited connections to the ADC
> channels.  I thought to improve this if possible.  Do you think you
> need this?"
>
> ----> I saw that there are 16 Inputs for the 10 bits ADC
> No I don't have a special  need at this moment.
> The other menbers could also give their inputs about that
> If wiring and adding a 16 pins connector isn't too complicated it
> could be a possible feature
>
> "I will sketch out the variations on the communication setup and post
> them in the files."
>
> ------->Thanks for that .It will for sure help me to better understand
> the CANBus communication priciples
>

> I will read your dochttp://rc-servo-interface.googlegroups.com/web/Version+2+System+descr...

[Crashmatt]

Jean-Claude,

Thanks for reading through this. Inserted comments below

> I read your document :http://rc-servo-interface.googlegroups.com/web/Version+2+System+descr...
> I have some comments for the last part "Summary"
> 1)In the table, what is the difference between "Yes" and  "ok" ?  ( I
> suppose YES is "stronger than ok...)

That correct. This analysis was only based on my opinion of it.
PLease feel free to argue any point another way.

> 2)For last line of the table (correspnding to fig 7)
> Flight Director attaches to CANbus2
> Telemetry attaches to Flight Director

Good point, thanks for the correction.

> 3)I undestand that 1st and 4th topologies (Fig 3 and 6) are not a good
> choice
> So remains 3 topologies instead of 2 as written .
> I suppose you selected the 2 topologies from fig 5 and 7 , and want to
> further investigate them

Another good correction. I added a topology but didnt update all the
text.
I would like to consider topologies from figs 4 and 5.

One important consideration is what happens when someone adopts a
flight director processor that does not have CANbus. Fig 4 and 7 are
no longer compatible.

fig 4 is good since the interface does not have to handle any of the
telemetry data. The flight director communicates directly.

I considered fig 7 to be the highest bandwidth solution but fig 4 is
better since it is more direct.
Debugging dual CANbus would be a horror we do not want. It also needs
more interfaces.

> 4)Due to the fact that CANBus is limited to 16 bytes messages, isn't
> it easier to use topology from fig 5.
> In this case there is only CANbus1 interface between Autopilot ans
> Interface.

I am really not sure which is the best of fig4 or fig 5.

Something somewhere needs to translate between the native bytes of the
autopilot code and put them into some format.

My gut feeling is that transfering native bytes accross CANbus is
best.
If you wish to use MAVlink, the code packing autopilot data into
MAVlink can be anywhere BUT it is best kept away from the autopilot to
reduce resource loading.

The difference between fig 4 and fig 5 is where you might put the
MAVlink code.
The code for MAVLink and the code for the CANbus protocol will be the
same libraries regardless of where it is located.

It would then be the users choice to wire up the system as fig4 or fig
5.

We must put MAVLInk into the interface to support the most basic setup
from fig 1. So Fig 5 must be supported.

Please tell me if I have any of this wrong.

> One more question :
> For Drawing (Fig) 7 , can you please explain what means " with some
> isolation" ?

Isolation -> isolated=separated: The two busses are separate from each
other and therefore more robust.