Welcome new user! You can search existing questions and answers without registering, but please register to post new questions and receive answers. Note that due to large amounts of spam attempts, your first three posts will be manually moderated, so please be patient.
We have moved to a new forum at http://jevois.usc.edu, please check it out. The forum at jevois.org/qa will not allow new user registrations but is maintained alive for its useful past questions and answers.

MAVLink on Hard Serial

+1 vote


Trying to integrate MAVLink on Jevois. I'm keeping it abstract from core implementation and only attached to a jevoisbase component, then inherite/methods override in module, but I need exclusive access to Hard Serial. Here is my initial plan, I'd like to get your quick input on it, and is there a less invasive method you can think of?

A. Set a flag in initscript to switch between regular serout/serlog and MAVLink. 

B. In my MAVLink implementation, access serial commands directly via Serial class

C. Switching would mute any system serial commands on the hard serial and give control of hard serial to MAVLink


Correction made: Serial class instead of StdioInterface class



I'll just disable serlog and keep serout on hard serial, then use the module class implementation of sendSerial and parseSerial inherited from Engine and extend them my MAVLink implementation. Since the received serial commands are passed down to module if not catched upstream. 

asked Apr 3, 2017 in Programmer Questions by alsaibie (740 points)
edited Apr 3, 2017 by alsaibie

2 Answers

+1 vote
Best answer

Sounds like a great plan overall, just one suggestion:

>>> before your update:

initscript.cfg is run after everything else has been initialized, and hence the serialdev parameter has disappeared by then (it disappears because one should not try to change serial device while running).

So instead, you can use params.cfg (in JEVOIS:/config/ on your microSD, source is in ~/jevois/Config/), this one is parsed before any other inits, and in there you can add a line


to not use any serial device in the JeVois Engine. For more info, see the preInit() and postInit() of jevois::Engine, and see the general doc of jevois::Component for init sequence.

In your module, you would then indeed just addSubComponent() with a new Serial component. On the platform hardware, the hardware serial port is /dev/ttyS0

Then I would recommend readSome() and writeString() on the serial to communicate in a non-blocking mode.

>>> after your update:

that is even easier if MAVLink does not conflict with any of the JeVois commands. For example, if it sends "info" or "help", the JeVois Engine would parse that and not forward it to your module. The list of commands parsed by the Engine is here:


and in Engine.C of the jevois github.

If you find some conflicts, we could implement an additional option on Engine which is to just forward everything and to stop parsing (this would be a terminal command until the next reboot). I think it might be useful in a number of scenarios similar to yours.

answered Apr 4, 2017 by JeVois (46,580 points)
selected Apr 4, 2017 by alsaibie
Thanks. I think I'll go with the first option to ensure sole operation of serial with MAVLink.
I have a draft code here (not tested and debugged yet) - MAVLink Branch of Jevoisbase:
One Q:
I'd like to access serialdev parameter in Engine.h within MAVLinkCommunication constructor and destructor (MAVLinkComm inherits a component class). The idea is that onParamChange(Serialdev = "") will ultimately be called when MAVLinkComm is constructed, turning the serialdev off from Engine and onParamChange(Serialdev="dev/tty...") will ultimately be called when MAVLinkComm is destructed, turning the serialdev back on. This is more of a C++ question, how do I access it?
hehe, we have been trying to discourage this kind of stuff (one component messing with another's parameters), except in parent-child configurations (a parent can easily access its childrens' parameters). In practice, I am guessing you will not be changing video modes (and modules) on the fly when you want to use the MAVLink module, as it will run on a JeVois camera attached to a drone, and, thus, being able to switch on the fly to DemoSaliency or other would not be useful?

If so, please first try this:

- on the SD card for your drone, you would add "serialdev=" to JEVOIS:/config/params.cfg - this will turn off serial comms on the Engine. Note that this parameter later gets "frozen", i.e., you cannot change it at runtime. The goal was to avoid having to lock a mutex protecting our list of serial ports each time we want to access the ports at runtime. But this could be modified in the long term if really you have a strong need to turn Engine serial on/off at runtime.

- in the directory of your module, create another params.cfg where you would just say "serial:devname=/dev/ttyS0" - this will set the device name of the Serial sub-component of your component. You can add more settings here like baud rate, etc

Then you do not need a serialdev parameter in your MAVLinkCommunication class, and in the constructor of that class, just add your serial sub-component and you are done (no need to set its devname).
Yep, I don't expect to change video modes really at all. I was just trying to make the MAVLink application stand-alone without needing any special modifications outside on params, in case it's used by others in the future. But changing a few parameters in /config shouldn't be a big deal in any case. I'll just do that.

Thanks for pointing out the second point, it's more straight forward. I assume params.cfg is called by default if present in a module directory?
yes, params.cfg is used by default if present, and parameter descriptors in there are relative to your module (hence serial:devname if for the serial port in your module)

yes, just explain in the doxygen docs for your module what people have to do (turn off the Engine serial in JEVOIS:/config/params.cfg) and then anyone can easily use your module.
0 votes

Is the MavLINK implemation is working ?

I am really interested to try ,

answered May 3, 2017 by patrickpoirier (360 points)
Hi Patrick,

Unfortunately, I was away from this MAVLink project for a while and just got back to working on it, will definitely share any successful results I get.

- Ali
Great, I will give it a try , thanks for this :-)