AUAV.Next?

[Phillip Kocmoud]

Hi Everyone.

I just shipped out the last 2 AUAV3 boards. Nick and I have gone back and forth on whether to run another batch of AUAVs or just let them rest. Of late there has been a small increase in demand for this board. None of which seem to be end users, mostly colleges and UAV manufacturers.

As I always do, I started thinking of what an AUAV3.1 would look like. 

Do we remove the Mag, Baro, CAN, and / or Flash RAM. Should we add an SD card slot? Switch to PIC32 or an ARM processor with RTOS.

Should we switch to a single Clik-mate ( http://www.molex.com/molex/products/family?key=clikmate_wiretoboard_connectors ) connector with wire harness to break out all of the IO pins?

Create a smaller 2 level stacked board?

I know I am thinking out load, but seriously what are you guys thinking? 

With my involvement with PX4, I now believe that mandatory logging is a huge benefit. This benefits both users and developers. 

I find the onboard MAG on the X2 works well as long as the power wires are not directly next to the board.

The baro seems only useful as a means to rapidly detect a climb or decent.

Flash? I don't know, Rob could you read and write directly to an onboard SD card using FAT32 or NTFS as the PX4 does?

CAN, with Nick and my involvement with the PixhawkESC, I think that should remain. Seems the future might be on the CAN bus.

Come on guys, what do you think? The AUAV boards have never been fully embraced by everyone in this group. What could be done to make everyone happy?

I threw a lot out there, feel free to comment on any or all of my points.

Phil

[Leonardo Garberoglio]

Hi, Phil!

For who of us that like to fly FPV a native OSD is mandatory.

Write to an SD card using NTFS is working rigth now on Nucleo brach (stm32f411)

Move to pic32, I don't think so, you should definitley move to an ARM core.

best wish!

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

[Tom Pittenger]

Baro is a little helpful in USA but in non SBAS countries like Australia it is required.

Certainly the long term answer is to go ARM. Changing to arm changes everything. New ide, new dsp helper functions, new programmer and new debugging. Is everyone ready for that? I'm not so sure.

I agree, after working with ardupilot it quickly became obvious that mandatory log files were a huge benefit. SD card log writing must must must be in there. Also, a tool to plot the log is needed too.

OSD is nice but should be an easy oil pan type plug in module.

Definitely CAN, and we should look into forking uavcan.

Also, definitely github if that was still in question. We all know how to do an interactive rebase, right? Good, that makes a world of difference.

I like the molex idea to bring out every pin like the pixhawk2 and Edison. Great for making daughter boards. Could even be the way OSD is done.

[Philip Giacalone]

Hi Phil,

Agree with everything Tom said. 

Some other thoughts...

It seems likely that there are 2 future markets for low cost autopilots. Those that have many features and greater complexity, and those that are simpler and focused mainly on their IMU role. There's certainly value in both approaches, as well as very different target markets. Also, the ability to successfully build one type vs the other certainly depends on the number of developers. Cost really isn't a big issue for the ARM decision, so it's really about developer time and future plans/requirements. How much processing power is enough? How much is overkill? I'm sure each of us has different thoughts. 

Personally, I still see good value in an autopilot that performs it's main role accurately and reliably, with fewer ancillary features. Less complexity implies less risk, which will be very important in some markets. As long as the autopilot supports integration standards (i.e., mavlink, CAN, etc), other systems can be added to perform other tasks. This approach also fits with Tom's suggestion about daughter boards, rather than a single integrated product. This seems like a portion of the future market for drones -- as mission requirements increase, separate components will be needed to create reliable systems, especially for commercial users. The commercial market will be smaller than consumer, of course, so that's obviously a consideration. But maybe it's a better strategy to stay clear of competing with the 2 elephants in the room? 

You mentioned having UAV Manufactures as customers, which seems really important. What key factors drove their choice of the AUAV over the Pixhawk, DJI or others? What features do they want most in the future? Can you share any insights? 

Best regards,

PhilG

[Peter Hollands]

Hi Phil,

My own inclination is towards "Keep it Simple" and Modularise each computer in the aircraft, with good reliable inter-module communications.

In one aircraft, we already potentially have the following computers:-

• The main Receiver
• The Autopilot (IMU+Control)
• The OpenLog logger
• The Electronic Speed Control
• The GPS Receiver
• The Xbee transmitter / receiver
• The OSD device
• The Camera (e.g. Go Pro)

I don't think we have to mandate logging. We just have to strongly encourage it.

I like the fact that the Openlog is a completely separate and proven device.

I also find it very convenient that the  Openlogger can be mounted in a separate location for easy access to the SD card.

Given that we already have a reliable solution what is the increased benefit / impact of writing all the firmware to do this with our main CPU ?

Surely much better to outsource the task to a dedicated processor and reliable well proven module ?

The above list of computers on board, are all supported today. 

But going forward, I can see an exception to modularisation. It is likely that the IMU will need to be closely integrated with Vision;

to enable additional sensory input to the IMU (Orientation), Positioning (SLAM), and Collision Avoidance. 

This latter architecture may well involve the use of a GPU, to speed up vision processing (and for Neural Network processing).

 Nvidia with their Tegra K1 Processor make an integrated 4 core ARM CPU with GPU (and also in the PX board for driverless cars).

This board by GE is based on the Tegra K1 for UAV work.

 We all should keep a lookout for opensource communities that are pioneering in the area of vision.

I can see that using CAN as an intermodule interface has benefits in some situations. And really PWM as a one way communication protocol is pretty archaic.

Having a bidirectional CAN speed controller that reports back on aspects of RPM and current usage is sensible. And more widely, the use of 

servos driven by CAN protocol etc is a good idea. I can see a need for CAN to glue some of the modules together.

Good Luck with the board design.

Best wishes, Pete

[Mark Whitehorn]

Recent open source work in computer vision is perhaps eliminating the need for GPUs:
http://vision.in.tum.de/research/lsdslam

If I can manage to get ROS working, I'll be experimenting with lsd_slam soon.

I agree that logging is important; however it's done it needs to be reliable, fast and easy to use for development purposes.

--Mark

Mark Whitehorn
kd0...@gmail.com

[Philip Giacalone]

Phil,
Inline with Pete's comments, a separate flight management computer, having a full operating system, and many choices to add s/w and h/w, is great way to support future aircraft features and modularity, while keeping other components, limited and simpler.

So yes, keep AUAV simple.
Best regards,
Phil

[Philip Giacalone]

Hi Mark,

That LSD-SLAM technology is quite amazing! I see they even have it running on an Android phone. But I guess they've limited their open source release to ubuntu with ROS? 

Wondering if you've tried using a Docker image to get the ROS setup? Maybe something like this?

https://github.com/Rayman/docker-images/blob/master/ros-indigo/README.md

Best regards,

PhilG

[Mark Whitehorn]

Phil,

Thanks, I haven't tried Docker yet. But the 2-line install for ROS seemed to work just fine on a 64 bit Ubuntu VM.

Next step is to try to install lsd_slam. I'm told it runs at 10-15Hz on Odroid.

--Mark

[Robert Dickenson]

Please no more dsPIC's. Segmented memory should stay in last century..

I personally like the idea of the board that MattC recently produced.

--

[Gabriel Elkaim]

Hi Phil,

First off, I think there is great value in keeping the AUAV3 line progressing. There is a great deal that can be done here with pushing the software with these low-cost boards and seeing what can be done.

Definitely leave in the Mag, Baro, CAN, and Flash RAM.

Adding in a microSD card hung off of one of the SPI ports would enable some very nice data logging (and while there are other products out there, if you want to capture everything going on at high data rates, they usually have problems keeping up).

Obviously, a differential pressure sensor would be nice for fixed wing, but again that can be put on a breakout board.

I think that the AUAV3 has a nice niche as a small, low-cost board with good capability, especially with the MicroChip Processor. I like the dsPIC processor (and this has some advantages on the MATLAB<-.C code conversion). In terms of upgrading to the PIC32, that is fine, though you lose some of the MATLAB code gen capability. You do gain a great deal in speed.

Just my thoughts.

--G

PS: I am one of the college purchasers, and we are actively developing with the AUAV3.

[Nikolay Arsov]

Hi guys,
This is how I see the AUAV.next:

1. Simple, which means no over engineering;
2. Almost ALLinONE, which means it should have almost everything needed for basic configuration - wide input range DC-DC Buck, dual power input with Schottky ORing, IMU ( MPU6000 or MAX21100 or both .... no MAG ), microSD, USB, simple programmable OSD, enough serial interfaces for GPS, Telemetry, etc., and at least 1xCAN;
3. A benefit will be an integrated ESC ( will explain hereafter );
4. Enough, which means to have everything for basic fixed wing configuration;
5. A new 32bit MCU seems to become a must;
6. A nice looking and user friendly configuration tool with ground control interface is a must.....maybe this is where we must start from.

A perfect solution is an ARM MCU + FPGA, which on its turn leads to Cypress PSoC 5LP as the first approach. The guys from Cypress assured me that this PSoC is powerful enough to fulfill p.1-p.5. It has a powerful FPGA, which can be used for hardware driver of up to 4 ESCs, thus freeing the integrated ARM MU for all other tasks. The Cypress benefits are their awesome development software which includes tons of ready made and tested libraries, modules, visual programming and examples. Another benefit is that any OS can be implemented.
I tried their latest PSoC Creator and do believe me.....this is a brilliant tool!

As mentioned above, a hardware ( FPGA ) driven ESC is easy to implement ( I already have that 4xESC project in my hands ).

These are my preliminary thoughts.

Best regards
Nick

[Lubin Kerhuel]

Hi Phil,

I am developing a Simulink Support package for dsPIC/PIC32 at Microchip, and as a hobbyist, the AUAV3 board is my best target to experiment algorithms to fly a delta-wing gliders (quick-build, quick crash). 

From my limited experiments:

• Adding a microSD card would be great to enable data logging. I did not managed with of the shelf, solution (openlog, testing different firmware...) to log a continuous data stream of 115200kbs or above making it of limited use when you are to log raw sensor values to reuse theses within a simulation.
  
• CTS/RTS control flow pins next to the Rx/Tx pins. It seems helping when bandwidth is pushed (with UART based telemetry - 3DR modules). There are enough pins on the AUAV3 board to find a solution to map a CTS/RTS pin function but it require a splitted connectors.
• I like current 2.54mm standard board connectors that allow making your own connector interfaces. This flexibility would be lost with a dedicated connector. However, dedicated connector might provide a huge gain in space.

For the AUAV3, I tend to think it might worth running another batch:

• dsPIC are widely spread in colleges/university, and the AUAV3 board has no equivalent (dsPIC based) except the UDB 4 and UDB 5 which are in my opinion bellow.
• Microchip released a blockset to target a dsPIC from Simulink model. The free demo version is usually limited to 8 pin I/O but from the v3.36 release, this limitation was removed for 6 chips including the dsPIC33EP512MU810 which make the AUAV3 an easy target to play with model based designed IMU and control from Simulink. Most University student/researcher have access to Mathworks tools. (It seems also that Mathworks is now proposing an “accessible” home edition for Matlab)

For the AUAV3.1 update, PIC32MZ is definitely a good candidate. This would make the board unique with a powerful mcu including all required UAV peripheral and directly programmable from high level graphical tools like Simulink (good to focus on algorithms). I would be pleased to provide Microchip contacts if you wish to design  a board compatible with the newer chip to come.

Best,
Lubin

[Riccardo Kuebler]

Hi Nick,

your proposal sounds good.
I like the idea of integration. I recently bought a Vortex racer quad, mostly for the almost complete integration of the components and the future possible developments (e.g. real/virtual combination of quad racing).

So everything on board is what I put high on the preference. I should take a picture of the mess of my Funcub. That's a really good plane, full of gadgets, but a (well working) mess of periferials and cables. Avoiding cables and connections means avoiding possible failures, reducing possible ground loop issues, RF issues, unwanted connections resistence etc.

Even mags on board have showed to behave well on problematic platforms as multicopters (e.g. Multiwii).

I can agree to have a remote micro card device for accessibility and same for programming the board. But this should not avoid having one on board. Maybe the possibility to bypass it or to stack it as you did with AUAV1 gyro board?

I'm really interested in the integrated OSD and curious about the on board ESC (did I get it right?).
Did you even mention a 4x ESC?

Best regards,
Ric

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

---

Questa e-mail è stata controllata per individuare virus con Avast antivirus. www.avast.com

[Nikolay Arsov]

Hi Ric, Hi my dear friend! Long time not hearing from you!
Yes, I'm learning PSoC 5LP Creator with a project to drive 4xESCs with just one PSoC 5LP chip, and as the motor drivers is a FPGA based, the integrated M3 ARM has enough power to drive the remaining peripherals.
I'm 99% sure this SOC can drive a fixed wing without any other MCUs.....ALLinONE concept.
If this ARM based FPGA is used for fixed wing autopilot, the percentage goes to 100%.
Best regards
Nick

[Riccardo Kuebler]

Hi Nick,

very interesting indeed. Will follow your development very close by.
And if the OSD on board will be followed by a flight controller that can be managed through the OSD itself with a RC controller, e.g. entering menus, changing gains, saving gains profiles (as Cleanflight on the Vortex does), selecting memorized flight plans etc., this will be a winner.
Have a nice Sunday,
Ric

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

[Tom Pittenger]

That would be nice, a built in osd with menu to do pretty much everything that mavlink offers. This for along with another requirement that we should migrate to which is removing option.h  enabling all features and using flash to store the equivalent of all user settings. They could be set via mavlink or the OSD.