Re: Nick's new board

[William Premerlani]

Nick,

I suggest you send out a note to the uavdevboard-dev group to see if there is any interest in supporting your proposed new UDB design. There are too many changes in the design for your proposed board to use MatrixPilot with only minor changes.

In order to get the software developed for the sort of board that you are proposing, you will need help from the community. And without the availability of software for your board, there will not be much of a market.

Best regards,

Bill

On Sat, Feb 25, 2012 at 2:58 PM, Nikolay Arsov <nick...@gmail.com> wrote:

Hi Bill,
Many thanks for your quick reply.
Yes, I could use the UDB4 dsPIC, but the EPxxxMU806 is almost the same with the bonus that you could remap most of the pins as you like according the PCB design....for easyest routing. I'll try to use the UDB4 dsPIC but if the board becomes too difficult for routing I'll discard it. I'm sure there's no problem to jump from dsPIC33FJ to dsPIC33EPxxxMU806.
You are right - there are some firmware problems concerning additional features of the new design. I think problems like jumping from analog to digital data manipulating is not a real problem for the team, but some firm for additional features should be written later. This new board will be our responce to ArduPilot Mega 2 - the purple one.... ;-)
If I could rely on the UDB comunity, I'll finish the design.

Best regards
Nick

[Nikolay Arsov]

Hi friends,

I have to explain my new design:

Two main reasons for the new design:

1. After 1-st of March, Invensense will not offer gyros with analog output;
2. I and Bill have searched for and found no replacements;
3. MatrixPilot needs a new board as a responce to ArduPilot Mega 2 - the purple one.... ;-).

I made some sketches for AUAV2 - MPU-6050 ( 3 gyros+3 acceleros ), HMC5883L, LPS331AP - absolute baro pressure sensor, Honeywell TruStability SSC RR diferencial speed sensor ( optional - pcb pattern will be onboard, but soldering will be optional ), MT3339 GPS without antenna( just connector for external antenna ), Micro USB, MicroSD card connector, 8-9 inputs, 8 outputs, 2xSerial ( Tx/Rx ), 2xI2C connectors, 2xSPI connectors, 2xAnalog connectors, 3,3V 1A LDO, MPU - dsPIC33EPxxxMU806........all these again on 30 x 45 x 16mm. ( 2pcb wafer ). I almost designed the boards roughly. I found this MCU very suitable because with a few code rows one could remap most of the pins as suitable for PCB design and the architecture you know very well.

Dear friends, could I rely on your support and make my best to finish the design ?

Best regards
Nick

P.S. Some explanations on why I look at dsPIC33EPxxxMU806 - the EPxxxMU806 is almost the same with the bonus that you could remap most of the pins as you like according the PCB design....for easyest routing. I'll try to use the UDB4 dsPIC but if the board becomes too difficult for routing I'll discard it. I'm sure there's no problem to jump from dsPIC33FJ to dsPIC33EPxxxMU806.

[crashmatt]

Nick,

There is much talk among the developers about use of I2C ports.  Much
of it about compatibility between devices.  The magnetometer is know
for having "mood swings" and locking up the I2C bus.  Not good if you
depend on the bus for the IMU.  If you can get a gyro/accelerometer
sensor onto the SPI port we would trust it much more.

Good idea to change to the dsPIC33 series for better long term
support. Moving to the 710A will mean very little development effort
and more likely support from the team.
My suggestion would be to test alternative sensors on a UDB4 before
you commit to a design.

Do not underestimate how much effort is required to use the data from
a new sensor. Plugging it in and getting data is only half the story.

Regards Matt

On Feb 25, 9:30 pm, Nikolay Arsov <nickar...@gmail.com> wrote:
> Hi friends,
>
> I have to explain my new design:
>
> Two main reasons for the new design:
>
> 1. After 1-st of March, Invensense will not offer gyros with analog output;
> 2. I and Bill have searched for and found no replacements;
> 3. MatrixPilot needs a new board as a responce to ArduPilot Mega 2 - the
> purple one.... ;-).
>
> I made some sketches for AUAV2 - MPU-6050 ( 3 gyros+3 acceleros ),
> HMC5883L, LPS331AP - absolute baro pressure sensor, Honeywell TruStability
> SSC RR diferencial speed sensor ( optional - pcb pattern will be onboard,
> but soldering will be optional ), MT3339 GPS without antenna( just
> connector for external antenna ), Micro USB, MicroSD card connector, 8-9
> inputs, 8 outputs, 2xSerial ( Tx/Rx ), 2xI2C connectors, 2xSPI connectors,
> 2xAnalog connectors, 3,3V 1A LDO, MPU - dsPIC33EPxxxMU806........all these
> again on 30 x 45 x 16mm. ( 2pcb wafer ). I almost designed the boards
> roughly. I found this MCU very suitable because with a few code rows one
> could remap most of the pins as suitable for PCB design and the
> architecture you know very well.
>

> *Dear friends, could I rely on your support and make my best to finish the
> design ?*

[Nikolay Arsov]

Hi Matt,

Thanks for your reply.

Yes, you are right, I'd better choose MPU-6000 for it has SPI interface and additional auxilary I2C own interface for compass as 5883 and pressure sensor. About the MCU - again you are right, so I discarded MU806 and I choosed dsPIC33FJxxxGP708 ( 80 pin version of 710 ) as there will be many analog inputs from gyros and acceleros left free.
I have a few questions:
1. Is it better to use the AUX I2C of the MPU-6000 for 5883 and LPS331 or tie them to the separate I2C?
2. Should I tie USB to the AUAV2 at all?
3. Should I tie the MicroSD card to the dsPIC or use another MCU to simulate the DataLogger? If I tie the MicroSD to the dsPIC, a lot of firm should be written for serving the flash. Otherwise I'll just add a small mcu to serve the flash and communicate with the dsPIC via the serial interface ( Tx/Rx like the DataLogger ).
4. Could I move I1-I8 from RD8-RD15 to RB8-RB15 ?....I think it wouln't be a problem.
5. I'll totaly discard the crystal....will work with the internal 7.37.

About the alternative sensors for UDB4, we discussed some ST gyros with Bill, but all of them have too low mechanical resonant frequences which is too bad. As an addition, the Invensense stops manufacturing all 2 axes analog sensors - too bad.

If you have any remarks, please advice.

Best regards

Nick

["Daniel Müller"]

Hello,

I am more of a consumer and follower than a developer so bare with me if I am totally out of line here, but if the dsPics don't have an easy way to write to SD cards and support FAT/32, or if it would mean to write a lot of firmware, you could always incorporate an existing logger, e.g. openlog into the hardware, I don't mean using a header, more like entirely integrate openlog harware onto the UDB board. this coudl save design and development time, free mcu resources but needs more hardware components, i guess.

just my 0.0000002 cents :)

Dan

-------- Original-Nachricht --------
Datum: Tue, 28 Feb 2012 06:39:21 -0800 (PST)
Von: Nikolay Arsov <nick...@gmail.com>
An: uavdevb...@googlegroups.com
Betreff: [UDB-dev] Re: Nick's new board

[Nikolay Arsov]

Hi Dan,

You are right! Using the original Atmega+SD socket will reduce the dsPIC load, but will occupy one serial port and as they are only 2, no serial left free.
That's the only reason to think of direct connecting the SD to the dsPIC, but on the other hand the dsPIC overload is not to be ignored.....have to think about.

Best regards
Nick

["Daniel Müller"]

i do a bit of tinkering with arduinos and there are libraries to emulate serial on any GPIO in software, maybe something like that is available for dsPics.

alternatively, openlog is open source, so i guess, one could "easily" modify it to source its log data from a different bus, maybe I2C?

Dan

-------- Original-Nachricht --------
Datum: Tue, 28 Feb 2012 07:27:55 -0800 (PST)

Von: Nikolay Arsov <nick...@gmail.com>
An: uavdevb...@googlegroups.com

Betreff: Re: [UDB-dev] Re: Nick's new board

[Wouter van Verre]

Hi Nick,

I like the design you propose. The extra onboard sensors and logging capability will probably prove useful to a lot of people. I guess it will be hard to squeeze onto your small design, but I was wondering if you have looked at integrating a current and voltage sensor?

I looked into using the SparkFun Sensor Stick (three I2C sensors on a very small pcb), about a year ago. Two of the things I was wondering about back then were:
- Most of these devices provide some level of filtering. I wonder how this would influence the DCM calculations?
- The MatrixPilot software currently uses a high degree of oversampling (I believe that the sensors a sampled at 8800Hz?). I doubt that a 400 KHz I2C bus is capable of outputting that much raw data. (And then I am assuming that the digital sensor is capable of outputting meaningful data at these rates...). If we cannot get raw data at these rates, how bad would that be for the DCM calculations?

Maybe someone in this group can shed some light on these questions?

Kind regards,
Wouter van Verre

Sent from my iPad

[crashmatt]

Nick,

Good question about the aux I2C. The magnetometer code is setup for a
specific I2C port. We do not know if the magnetometer can reliably
share an I2C port with anything else. Best to keep it away from the
MPU-6000 to avoid confusion.

Do not discard the crystal yet. We have some communication problems
caused by the onboard oscillator. I don't fully understand the issue
but please read around this first.

Bit bashing UART is not possible. The UDB does time critical PWM
outputs which have highest priority. There is no capacity for another
time critical operation.
There is the MAX14830 for UARTs to SPI. There is also a 4 port UART
version.

I suspect that the number of users needing both data logging and
telemetry is quite small. There is a cheat where openlog can be put
in parallel with the telemetry and record the mavlink data packets.
The openlog also allows you to mount the SD card where you can get to
it.

USB: Is may not always be possible to get the USB connector to the
autopilot board? Many autopilot boards are mounted with no access to
the connectors.

CANbus is another idea to throw into the mix. I will discuss this
later.

Business idea: Ask yourself what APM does badly and what it does
well. Try to compete by playing on the APM weaknesses, not by trying
to copy it. Ask yourself what you are doing well that people like and
try to stick to that.

Regards Matt

On Feb 28, 4:40 pm, "Daniel Müller" <Daniel.Muel...@gmx.com> wrote:
> i do a bit of tinkering with arduinos and there are libraries to emulate
> serial on any GPIO in software, maybe something like that is available for
> dsPics.
>
> alternatively, openlog is open source, so i guess, one could "easily"
> modify it to source its log data from a different bus, maybe I2C?
>
> Dan
>
>
>
>
>
>
>
>
>
> > -------- Original-Nachricht --------
> > Datum: Tue, 28 Feb 2012 07:27:55 -0800 (PST)

> > Von: Nikolay Arsov <nickar...@gmail.com>

[Nikolay Arsov]

Hi Matt,

Nice and very instructive post....I highly appresciate it. Thank you !

1. I'll keep the compass to the port already dedicated. The same port could also serve the pressure sensor.
2. I have some place for ceramic resonator, so I'll leave it as is.
3. It would be merely impossible to find place for additional UART....maybe I'll stay as is ( I still think to offer 30 x 45mm. board ! ).
4. About the OpenLog....I'm thinking to implement it as is ( ATmega+SD socket ) to the AUAV2....but still thinking on....
5. CAN bus....interesting idea....let's discuss it.
6. About the business idea - nice advice....I like it....great ! What I'm doing well - I'm trying to make good, small, a bit cheaper and reliable electronics....I'll make my best in the new AUAV2 too. Also I couldn't immagine that UDB will die after Invensense stop manufacturing IDG-500.

It is pleasure for me to discuss with you the new AUAV !

Best regards

Nick

> > An: uavdevboard-dev@googlegroups.com

[crashmatt]

Nick,

#6 I agree that the small size of your design is a strong feature
which competes well with APM2.
APM is focused on quadcopters where everything is in one place. This
is great if you want it but not so great if you do not.

#4 - Openlog
You could experiment with driving an SD card using the microchip
libraries and the existing UDB4. Then a user could choose to add an
SD card holder on a breakout board if they need it. It would be the
lowest cost, smallest and easiest to implement option for you.
If you don't put an eeprom onboard, the calibration and settings
storage would need re-writing for the SD card.

#5 CANbus can give you a completely different concept. You could make
many small boards that you connect with CAN to communicate. This
keeps the main autopilot board very simple but also gives you great
expansion and modular opportunities. It is not easy to implement and
carries considerable risk. I did a CANbus interface project for UDB
which failed for various reasons. I still believe that CAN is an
excellent expansion interface option.

I am very curious to see where your decisions take AUAV2

Regards Matt

> > > > An: uavdevb...@googlegroups.com

[Nikolay Arsov]

Matt,

I think to put SD socket onboard as I have provided space needed and it's cheap - just wonder to overhead the dsPIC or not?
I forgot to mention that I had implemented an EEPROM.

About the CAN - at this stage I'll forget about.
In a few days I'll post the preliminary schematics here and a week later - some 3D of the PCB.

Best regards
Nick

[crashmatt]

Nick,

The SD card services would need to go at the lowest interrupt priority
level with the eeprom services. That way there is no possibility that
they take too much processor time. They will take some ram but we
have quite a bit of space.

If you can keep the CAN connections free for use that will enable us
to do something with it in future.

Regards Matt

[Nikolay Arsov]

Hi Wouter,

I wouldn't implement current sensor because it's better for high currents be away from noise sensitive devices. For that reason I developed another very small APOWER Board which implements 90A current sensor, voltage sensor, 10A 5V servo power supply, 5A 5V power supply for different devices as receiver, AUAV...etc, 12V 1A for camera, video transmitter...etc., 9 inputs and 9 outputs for servos......again very small board 30 x 60mm.

About the sampling rate, I connected the MPU-6000 to the SPI. Thus we could sample it times faster than I2C.

Hi Matt,

The next question is to you:

 I use one SPI for MPU-6000. The problem is that there's one more left for OSD, MicroSD and any other device. How to proceed? I didn't find an SPI HUB in the net.
....any ideas to solve the problem ....?

Best regards

Nick

[Nikolay Arsov]

Matt,

I solved the problem by using the CS pins of the devices. Just have to check if the simple OSD has CS. Please advice which two devices to put together?

Best regards

Nick

[Nikolay Arsov]

Hi again,

Maybe the right solution is to have SD card and OSD work on the same SPI bus as both devices have low refresh rates.

Nick

[Nikolay Arsov]

Hi friends,

As I promised, here's the preliminary schematics of AUAV2 for discussions.

Please sketch over with red pen and post your remarks. Thanks in advance.

Best regards

Nick

[crashmatt]

Nick,

I doubt that MPU-6000 could ever share its port with anything else.
If the other item on the port takes too much time it would be a
disaster. The SD card would be a problem.

You might also look at the data converter port. I have not read much
about so I don't know if it might help. This port is not wired out on
the UDB4.

You would need a driver to share the SD and OSD off one SPI port. The
SD code would need to be compatible and the OSD code would need
modification.
SPI can run in one of 4 different modes so the driver has to take care
of this.

All said, if the drivers are written well, devices can be moved around
different ports without a problem. The SD card drivers might be a
good place to start.

Regards Matt

[Nikolay Arsov]

Hi Matt,

At the present moment I share the SD with the OSD ISP port but I have some space left and could insert an additional MCU to drive the SD and thus there will be SPI for 6000 and SPI for OSD and no additional drivers and code have to be written. The only bad think is that we have to use one of the UARTs. But this is not so great problem at all...;-)

Best regards
Nick

[crashmatt]

Nick,

I forgot to mention. The MPU-6000 sensors have a low pass filter at
250Hz. There may not be much benefit sampling them above 1kHz.

I disagree about committing the UART to the SD card only. MAVlink is
used through the UART for communications. It is how autopilot tuning
and waypoint changes are done at the flying field.

Regards Matt

[Nikolay Arsov]

Hi Matt,
As I understand the best for the moment is to share the SD with OSD via the SPI. I think both devices are not so fast and one SPI could handle both....am I right?
Are there any remarks on the applied schematics ( some post above ) ?

Best regards
Nick

[Nikolay Arsov]

Hi,

I found a problem in my sch - RB8-RB15 should not be used for Inputs as they are not 5V tolerant......so I have to swap inputs with outputs.

Sorry for that mistake.

Nick

[Nikolay Arsov]

Hi team,

2 questions:

What do you think, will there be a problem if I use different dsPIC33FJ256GP710 pins as of the UDB4 for easy routing the PCB ? I mean some analog and input/ouput pins ( it not concerns the I2C, SPI, UARTs ). I observ the 5V tolerant pins for inputs from the receiver, but it is not mandatory for servo outs. I know the mcu pins are assigned during initialisation of the mcu, so it will be not so difficult to reassign some pins in the firmware.

What do you think of using 3 single axis analog gyros ISZ-505 instead of any other Invensense digital gyro or combo? I could put them on a small Hybrid ICs...say 8x8 or 10x10mm. which will be easy to solder on the main pcb as through hole components. Each of them will have 5 pins - GND, +3.3, Analog out, Auto zero out, Int temp sensor our ( optional ).

Please advice.

Best regards

Nick

[Nikolay Arsov]

Hi friends,

I think I found an alternative gyro - L3G3250A - it's a ST 3 axes analog gyro with 625deg/s and over 20kHz mechanical resonant frequency.
After a week of thoughts I decided to implement it on the AUAV2 on my risk. I use the Good Old accelero MMA7361L . Also I'll put an additional alternative headers for alternatives if any in the future. Thus the board becomes more flexible to gyro market. The PCB ( UDB4 clone ) is almost routed.....30x45mm !!! ( MicroSD+absolute pressure sensor+compass included ).

Have a nice weekend with best regards

Nick

[Peter Hollands]

Nick,

If new board is using daughter board for gyros like previous board then would be good idea to route an i2c signal and or SPI up to the daughter board.

This would allow easier swap out of daughter boards for experimentation with digitally interfaced gyros and acceleration in the future.(as has been done with hot glue by Mark Cutler on UDB4) .

The world of gyros is changing quickly.

Best wishes Pete

[Nikolay Arsov]

Hi Pete,
RIGHT! That's the idea! There will be replaceable daughter board for any experiments.
Best regards
Nick