NASA competition - suitability of AQ6 or M4

[Kisssys]

You do have 2 Uarts available on each if you count Uart1 which is what I would assume you would talk to the FC with. Then you have Uart2 on the the AQ6 and Uart6 on the M4.

On the M4 you have USB communication to mavlink, telemetry and the gps. It also gives you access to the uSD card in it's plugged in.

Do you really need 3 uarts?

[flomartel]

Thanks for your prompt response.

I need an interface to a flight computer onboard the UAS, which seems most convenient to be achieved through one of the USARTs/UARTs. Can I hook up USART1 to a flight computer while keeping the QGC capability?

When you talk about the M4 having USB to mavlink, are you referring to the ability to hook up a USB cable directly between the M4 and a computer running QGC? By the way, is there a serial console on the AQ6.1 or M4, or is CrossWorks the only debugging method available? For my own information about capabilities, where can I find more information about the different "commStreamTypes" (a basic search through the forum and website documents was fruitless)?

When you talk about the M4 having telemetry, are you referring to mavlink communication through USART1?

Thanks.

[joebar.rc]

There will be another option for additional uarts, the autoquad pdb will be released in a while and there will be a couple of com ports available that can be virtually mapped via de can bus from aq6/m4 to that pdb.

So, on the AQ FC side you can have more uarts than physical available on the fc.
From the top of my head, you can have at least 2 additional on the pdb, one on xbee connector and one simply on external pads ..

That will give you 3 uarts to use, you only have to wait for the pdb release...

Menno

[Kisssys]

As Max mentioned the PDB does a lot and would give you what you need port wise but you add another STM32F407 processor in the mix to gain a serial port. It would gain you a spare CAN bus for communication and distribution for the motor CAN bus and a OSD. A lot of the coding is not complete but it greatly expands a simple M4 board beyond any other FC out their.

The AQ6 board has UART6 available on the VN100 pads you see distributed around the IMU components. So you have 3 or 4 uarts available if you lift the GPS or the ferite beads feeding it.

When the USB port on the M4 is enumerated, depending on the baud rate selected you gain simultaneous access to Uart1( the coder will have to explain ), Bills telemetry which I know nothing about and access to the GPS. The access you need to substitute the GPS could surely be done here but the coding may be an issue. I'm already over my heading describing its use.

The AQ6 has what you need already with the least amount of work to make it play. You have a SPI buss also available on the epansion headers.

[flomartel]

Thanks for the feedback.

On AQ6.1, as Steve mentioned, I can use the solder pads to access USART2 and USART6. That will be sifficient to provide the necessary capabilities for now.

Does the AQ6.1 or M4 have a serial console (intended to be used for initial debugging purposes) or is CrossWorks the only debugging method available?

[Kisssys]

I've only used Xworks, The STM discovery board for the 407 has a wealth of information and searching it's resources you may find what you need. Xworks works very well, I tried IAR stuff a little to compile something I couldn't get Xworks to compile and it works well but is much more expensive.

[Max]

Hello Florent,

Nice to "meet" you here. I've heard a lot about your project from Larry. It would be great to see AQ help you succeed in the competition.

SWD debugging is the best method I've found so far. Xworks has a debug_printf() (or something like that) but I haven't found it very useful (you need to be connected via SWD anyway). To monitor some value while running, it's usually easier (for me) to send it via mavlink and view/graph it with QGC or some other mavlink client (which I usually have already running anyway).

For breakpoints, pausing, examining variables at runtime, etc, SWD is the way to go. The tools aren't limited to XWorks -- I use Eclipse/CDT for example, with a separate GDB (debug) "server." XWorks is hard to beat in terms of initial setup (it mostly "just works"). But there are several other IDE choices out there (some free/OS), and good tutorials for setting up Eclipse (the debug setup is the hardest part). A lot depends on which computer op. sys. you prefer.

The STM32F4 discovery board is a great value, especially if you need an ST-LINK interface anyway.

BTW, any particular reason you want to use the M4 vs. the AQ6 w/DIMU?

Cheers,
-Max

[flomartel]

Hi Max,

I didn't expect any less from Larry!

Thanks Steve and Max about suggesting the discovery board. Indeed great value... Considering the amount of changes I'll need to make to the code, I probably could use more feedback than values displayed through MavLink, but there's a good chance I'll start with MavLink initially as it will also allow me to learn more about it (essentially,even though there are other options out there, I plan on using MavLink anyways to retrieve telemetry information - needed by the collision avoidance algorithm - and to send commands to the autopilot).

I guess the choice of development tool is a matter of personal preference, and although I've used Eclipse before, it's been a while (never used SWD or programmed STM32F4s before though)... From a cursory search query, it looks like there is support for ST-LINK/V2 in Linux, but if I can just get by using Windows, then that's probably what I'll prefer. So, do you recommend the STM32F4Discovery with STM32F407VG processor model?

Great question about the M4 vs. the AQ6 w/DIMU. I don't know enough yet about the differences (essentially same source code?) to make a judgment call, so I'm tempted to turn the question back to you. I'm candidly struggling to find information about the hardware and interfaces besides a few pictures and diagrams lying around... So, which one do you think would be most suitable given what you know about my project? For reference, my project is a continuation of this one:

Also, I would like to know the state of development and possible pinout/user guide information about the PDB. It would greatly simplify my design requirements if I could run the collision avoidance code directly on the PDB's STM32F405. Now I feel like I'm overly demanding...

Random question: has there been any discussion about interfacing the ESC32v3 with other autopilots? I know that would require code changes on those autopilots, but I believe some could be convinced by some of its features...

[flomartel]

One more thing. Is the source code for the PDB available? If so, where can I find it?

[bn999]

The PDB code is here:

https://github.com/bn999/pdb