Mavlink + extra serial output

[GliderUav]

Hi,  

Here is an idea that i would like ask your comments on.

In some situations, a second serial telemetry port can be helpfull. My reason is that i want to use MAVLINK on the ground and for logging,
as well as a small serial protocol version in flight, so it can be transmitted over FrSky.
With the work Robert has done last year, it is now possible to do this. Looking at this, i found a way to fix MAVLINK in trunk as well.

- Should we call that extra port AUX_PORT?
- Is serial3 a good name to use (in serialIO.c)?
- should we use the new convention for enabling Mavlink, and change options.h to reflect this?
- how can we take into account the plans Robert has for configuring these options without re-compiling?
- some comments need changing; the new way to configure MAVLINK, a typo in port mappings, etc.

Tell me what you think. I would like to create a pull request when we agree on the way to go.

Thanks,
Kees

[Peter Hollands]

Kees,

Thanks  for your detailed patch, and code ideas.

What I would like to do, is move to each feature change / bug fix in your patch being a different pull request from your personal code repository.

I see:- 

• Change of MAVLink default baud rate back to 57600; and ensure MAVLink initialisation is done correctly.
• Introduction of AUX_PORT for the AUV3, providing a 3rd Serial Port.
• Comment Changes.

I think I could demonstrate how to do that with a screencast video, and then I would ask you to see if you could use the Video for proposing the second change (I will have done the MAVLink pull request as part of the Video). I hope that sounds OK. I'm keen to try and ease the transition to using Git and Github for everyone.

From my point of view here are my reactions to your questions:-

 Should we call that extra port AUX_PORT? Yes, that is fine with me. Other Developers may want to comment.
- Is serial3 a good name to use (in serialIO.c)? Yes, that seems fine to me as well. Again comments welcome from other developpers.
- should we use the new convention for enabling Mavlink, and change options.h to reflect this? Not sure what you mean by this.
- how can we take into account the plans Robert has for configuring these options without re-compiling?  Personally I would like us to try and keep the MatrixPilot code pretty simple. Any time you introduce a file system or networking (TCP/IP), I think that they should either be done in a co-processor (running independently) or in an RTOS on a 32 bit computer (e.g. Arm processors). So for now, this is way down my own priority list. I want to see a reliable and tested and reasonably simple Master. (compared to say NuttX functionality). The Microchip code for filesystems is not OpenSource, but is restricted to PIC processor usage.
- some comments need changing; the new way to configure MAVLINK, a typo in port mappings, etc. OK, let's put that in a separate pull request.

Best wishes, Pete

--
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.

[GliderUav]

Pete,

To clarify the "old" and "new" methods:

old: options.h, using  SERIAL_OUTPUT_FORMAT  SERIAL_MAVLINK
new: mavlink_options.h , using USE_MAVLINK 1 (SERIAL_MAVLINK gone)

And, sure i will try out your video, great.

All the bests,
Kees


Op vrijdag 15 april 2016 20:41:38 UTC+2 schreef Pete:

[Robert Dickenson]

On 16 April 2016 at 04:41, Peter Hollands <peter.hollands@gmail.com> wrote:

From my point of view here are my reactions to your questions:-

 Should we call that extra port AUX_PORT? Yes, that is fine with me. Other Developers may want to comment.
- Is serial3 a good name to use (in serialIO.c)? Yes, that seems fine to me as well. Again comments welcome from other developpers.
- should we use the new convention for enabling Mavlink, and change options.h to reflect this? Not sure what you mean by this.

Something I put considerable effort into over the years was trying to introduce a split up options.h system. To this end I introduced the 'Config' directory, which became particularly useful with the automated makefile based build system. However my initial motivation for splitting options.h into functionally independent configuration files was that during the day, and especially with MPLAB-8 (which was never a speedy builder), I was doing hundreds of builds with various configuration options enabled, and a single change in options.h forced a rebuild of almost every source file.
 

- how can we take into account the plans Robert has for configuring these options without re-compiling?

Personally I would like us to try and keep the MatrixPilot code pretty simple. Any time you introduce a file system or networking (TCP/IP), I think that they should either be done in a co-processor (running independently) or in an RTOS on a 32 bit computer (e.g. Arm processors). So for now, this is way down my own priority list. I want to see a reliable and tested and reasonably simple Master. (compared to say NuttX functionality).

The initial goal was to move MatrixPilot towards a simpler user configuration experience, aka, runtime configuration options. I realise this has only seen limited success, but it was undertaken from user feedback in the day from those who criticised MP for not being usable from groundstation programs, like many other autopilot projects seemed to provide.

I agree that networking was reaching a little to far, and I backed off from that direction quite early. However with the introduction of the AUAV3 with a flash storage device in place of the traditional eeprom, emulating the single byte access of the eeprom on the block only erasable flash proved problematic. Therefore I sought to standardise the persistent storage via implementation of a filesystem approach. There is actually code in one of our branches which supports a very tiny filesystem (enough for an ini file) on the UDB4/5 eeprom!

 

The Microchip code for filesystems is not OpenSource, but is restricted to PIC processor usage.

One of my design goals with the filesystem is that it goes through a posix like abstraction layer. Initially this makes the SILSIM and Microchip hardware interface look much the same for the MatrixPilot application. A future benefit is that any filesystem implementation should be able to be dropped in quite readily. This was already realised quite recently with my work with LeoG when porting MP to an STM32_nucleo development board.

- some comments need changing; the new way to configure MAVLINK, a typo in port mappings, etc. OK, let's put that in a separate pull request.

 

Another goal was to convert all device I/O to the posix like read/write/ioctl calls. This was to do away with the custom serial system currently in use for telemetry and MAVLink, as well as make it trivial to map either to any port. Again, there is code in various branches which demonstrate this concept working quite well. I also believe this makes the MatrixPilot architecture simply for new developers to understand (of course with the trade-off that the underlying I/O system become quite complicated).

I also did a fair bit of 'refactoring' with a view to completely decoupling the MatrixPilot/libUDB layers via implementation of several function pointer callback interfaces. Again, I believe this helped to simplify other targets than MatrixPilot itself, such as the RollPitchYaw and LEDTest programs - which would lose the requirement to define a bunch of 'callback' entry points which are not actually used. This was also motivated by my introduction of a build option to run MP as FreeRTOS tasks, which (again, in various branches) works very nicely and helps to clarify in the code architecture that the autopilot really consists of two main almost independent 'tasks'.

Regards, Robert.

[GliderUav]

Hi Rob,

I like the changes made in trunk, but in the short term, we need to fix a few things. Like getting mavlink working again. Maybe that should get more priority, even if it means a little more work in the long term.

Have you looked at the patchfile and what do you think about it?

Thanks.

Kees 

Op zaterdag 16 april 2016 13:58:26 UTC+2 schreef RobD:

[Robert Dickenson]

G'day Kees,

I did take a raw look at your patch. Noted the implementation of traditional serial handling for uart3, however couldn't see exactly what is the inferred problem with MAVLink in trunk right now? Is it just an issue of mapping it to the serial port as used to be done via setting SERIAL_MAVLINK macro?

Regards, Robert.

--

[GliderUav]

Rob,

Yes, the setting of the callback function pointers are missing. In my patch i put that job in mavlink_init(), as well as setting the baudrate for mavlink.

Regards,

Kees

Op zaterdag 16 april 2016 14:23:38 UTC+2 schreef RobD:

[Peter Hollands]

Kees,

I recorded a demo video of the using Github workflow using a program called Sourcetree. . And I enclose a few slides that I used in the video. I hope it will of use to future new developers.

I suspect that you know most of it, but hopefully it will clarify what I think is expected for making a Pull Request.

I did not change the default MAVLink speed in the video, but instead I changed USE_MCU_IDLE back to 1 (something nice and simple).

If you are happy to give it a go, then perhaps you could start with a change to the MAVLink default serial speed, and MAVLink initialisation. 

If you have any issues, do email me one on one if you like, or we can continue here on uavdevboard-dev.

Best wishes, Pete

[GliderUav]

Hi Peter,

I followed your video, and it was clear to me. You convinced me to install SourceTree. I used Git desktop and TortoiseGit before, but at first glance i like SourceTree.
A mistake i made when setting up is that i pulled my own branch, not upstream. I could not see that i was behind. I liked the fact that you explained the names of the branches (upstream vs. origin) very clear (see my remotes settings). After fixing that i noticed i had an extra column in SourceTree to the far left, that confused me a bit. I made the branch and the changes, committed those.

As is, the patch may not be correct yet, i need to test some more. One might be tempted to change SERIAL_OUTPUT_FORMAT, that would not work.

All the best,

Kees

Op vrijdag 22 april 2016 17:52:09 UTC+2 schreef Pete:

[Peter Hollands]

Kees,

That is Super. Thanks for sending in the Pull Request. I will also do some testing.

I have not seen that left hand column in Sourcetree before. In fact, your whole screenshot of Sourcetree (on Windows ?) is different than on my Apple Mac. 

I am now thinking that you are using an older version of Sourcetree. I have reviewed the link that I made further up the post and I see that it went to sourcetreeapp.com. But I think that the better place to download from, is Atlassian.com.  I wonder if you could reinstall from this link:

https://www.atlassian.com/software/sourcetree

and see if the program is more up to date ?

Best wishes, Pete

[Peter Hollands]

Kees,

I have checked the two links .... sourcetreeapp.com and https://www.atlassian.com/software/sourcetree and they both lead to the same identical location for the download. So you will have the correct code which for Windows looks like it is version 1.8.3.

Best wishes, Pete

[GliderUav]

Yep, 1.8.3.0

Op zaterdag 23 april 2016 10:08:04 UTC+2 schreef Pete: