New Multiwii Serial Protocol

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Jun 21, 2012 1:17 pm

Alexinparis wrote:
Right, it's possible to do like this, and handle a timer to send regularly unsollicited messages.

But would it be really usefull ?
The OSD or GUI would still have to activate the toggle.
So, if it's possible, it's also possible to request each message.


I really think there is a huge benefit Alex. I am new to FPV but the information sent from the Flight Controller to the OSD during flight is critical. The problem that I am encountering with the new protocol is timing the request. It was very simply sending a single byte, but sending a request string is very time consuming and hard to do not using Interrupt on Serial.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Alexinparis » Thu Jun 21, 2012 1:59 pm

I never had such request from OSD developers

You know, receiving bytes is also something that should rely on interrupts.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Bledi » Thu Jun 21, 2012 2:07 pm

The time is not really critical on OSD. The refresh rate is very slow to have time to read on screen informations.
NOTA : Alex can you upgrade the protocol description on the first page plz ?
User avatar
Bledi
 
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: New Multiwii Serial Protocol

Postby Pyrofer » Thu Jun 21, 2012 3:23 pm

I think having a compile time option, ifdef forcegui = send all data all the time
would be great, sounds like it would solve my needs and that of the OSD developer in question.
No need to send any data to the copter to get it to output for the gui/osd.
It could still happily receive GPS data on the input pin.

In fact, if the incoming messages were parsed based on content rather than assume either gps OR gui, you could have a serial connection to the GUI, check everything out, configure PID etc and just have a simple 2way toggle switch to change the input pin to receive gps data instead.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Jun 21, 2012 3:58 pm

Bledi wrote:The time is not really critical on OSD. The refresh rate is very slow to have time to read on screen informations.
NOTA : Alex can you upgrade the protocol description on the first page plz ?


Timing is critical, you are using a totally different method(MAX7456), we are using a LM1881 to detect the lines and both interrupt handlers are used. Serial.write is useless.
Last edited by copterrichie on Thu Jun 21, 2012 4:11 pm, edited 1 time in total.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Jun 21, 2012 4:03 pm

Pyrofer wrote:I think having a compile time option, ifdef forcegui = send all data all the time
would be great, sounds like it would solve my needs and that of the OSD developer in question.
No need to send any data to the copter to get it to output for the gui/osd.
It could still happily receive GPS data on the input pin.

In fact, if the incoming messages were parsed based on content rather than assume either gps OR gui, you could have a serial connection to the GUI, check everything out, configure PID etc and just have a simple 2way toggle switch to change the input pin to receive gps data instead.


I was thinking a user defined string "header,request, request, etc,footer", this way, each OSD developer can define the information they need and in what order. I have done it before with a data logger and there is very minimum impact on the loop time having the data streaming full time.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Bledi » Thu Jun 21, 2012 4:27 pm

copterrichie wrote:Timing is critical, you are using a totally different method(MAX7456), we are using a LM1881 to detect the lines and both interrupt handlers are used. Serial.write is useless.

For sure with a video synchro you need to have a high refesh rate of video frame.
User avatar
Bledi
 
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: New Multiwii Serial Protocol

Postby kos » Thu Jun 21, 2012 6:49 pm

Alexinparis wrote:
kos wrote:in fact we should add a toggle flag for all requestable . so we can construct any osd , any gui with any refresh rate for any components

we just have to use the unused payload as the toggle flag
Code: Select all
no payload
   // send reply and stop
else
  payload = read8
 // payload == 5 ->send reply @5 hz


Right, it's possible to do like this, and handle a timer to send regularly unsollicited messages.

But would it be really usefull ?
The OSD or GUI would still have to activate the toggle.
So, if it's possible, it's also possible to request each message.


osd dev are lazy .. or incompentent , this would be helpful to them :D


what i have in mind is removing the time required for reading serial char for OSD .. auto toggle will help saving cycletime.

there is a trade-off as the added complexity also increase cycletime , using the payload let the serial protocol unchanged , my 2cents .
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby EOSBandi » Mon Jun 25, 2012 11:07 pm

Hi Alex,
As I progressing with the GPS code and the WinGUI, it seems that there are two additional commands are needed to read and set waypoints (incuding home pos and poshold position)
Here is my proposal:

MSP_GPS_NAV_GET_WP
1 byte payload - the number of the WP to query
Reply : wp#(uint8_t), lat (int32_t), lon(int32_t), alt(uint16_t), flag(uint8_t)
(WP#0 is the home position, WP#16 is the current hold position)

MSP_GPS_NAV_SET_WP
payload
wp#, lat, lon, alt, flag
(WP#0 is the home position, WP#16 is the current hold position)

I'll implement it and commit to shared if you agree. (it could be enclosed in a #define WinGUI till the main gui does not support it)
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby Hamburger » Tue Jun 26, 2012 12:16 am

with current SerialCom() implementation the key input navigation etc. for telemetry is broken. :(

The implementation and calling of
Code: Select all
void oldSerialCom(uint8_t sr) {
got lost with that latest rewrite of the SerialCom() state machine.
Maybe that was a bit too ambitious - where must the calling of oldSerialCom() go in the current SerialCom() , please?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Alexinparis » Tue Jun 26, 2012 7:14 pm

EOSBandi wrote:Hi Alex,
As I progressing with the GPS code and the WinGUI, it seems that there are two additional commands are needed to read and set waypoints (incuding home pos and poshold position)
Here is my proposal:

MSP_GPS_NAV_GET_WP
1 byte payload - the number of the WP to query
Reply : wp#(uint8_t), lat (int32_t), lon(int32_t), alt(uint16_t), flag(uint8_t)
(WP#0 is the home position, WP#16 is the current hold position)

MSP_GPS_NAV_SET_WP
payload
wp#, lat, lon, alt, flag
(WP#0 is the home position, WP#16 is the current hold position)

I'll implement it and commit to shared if you agree. (it could be enclosed in a #define WinGUI till the main gui does not support it)


Hi,
No problem, feel free to commit it.
Instead of #define WinGUI, it can be a more generic term like #define GPS_NAV_WP
This way the flash footprint will still be saved for GPS boards with no use for WP navigation. (critical for 328p + Serial GPS)
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Alexinparis » Tue Jun 26, 2012 7:15 pm

NOTA : Alex can you upgrade the protocol description on the first page plz ?

ok, I will do it.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby EOSBandi » Tue Jun 26, 2012 7:30 pm

Alexinparis wrote:
EOSBandi wrote:Hi Alex,
As I progressing with the GPS code and the WinGUI, it seems that there are two additional commands are needed to read and set waypoints (incuding home pos and poshold position)
Here is my proposal:

MSP_GPS_NAV_GET_WP
1 byte payload - the number of the WP to query
Reply : wp#(uint8_t), lat (int32_t), lon(int32_t), alt(uint16_t), flag(uint8_t)
(WP#0 is the home position, WP#16 is the current hold position)

MSP_GPS_NAV_SET_WP
payload
wp#, lat, lon, alt, flag
(WP#0 is the home position, WP#16 is the current hold position)

I'll implement it and commit to shared if you agree. (it could be enclosed in a #define WinGUI till the main gui does not support it)


Hi,
No problem, feel free to commit it.
Instead of #define WinGUI, it can be a more generic term like #define GPS_NAV_WP
This way the flash footprint will still be saved for GPS boards with no use for WP navigation. (critical for 328p + Serial GPS)


OK, thanx.
It seems that WP navigation will be only possible on 328P with i2cGps. Serial GPS and WP nav will require an atmega1280 or 2560.
Altought I would like to focus on the poshold and rth functions and make them rock solid. This slate full blown WP nav into MultiWii 2.2
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby Hamburger » Wed Jun 27, 2012 11:17 pm

Hi,
I was trying to add transmission for some tunable setup parameters between MWC and GUI, namely gyro.smoothing parameters and servo trims for TRIs, HELI*, FLYING.WING, AIRPLANE. It is rather tiresome, especially as about the same functionality was implemented as part of the LCD code before.

The current protocol implementation / GUI handling looks sub-optimal to me. We currently have 3 types of data for exchange between MWC and GUI
1 - administrative (version-nrs, multitype etc.)
2 - live data (sensor readings, counters)
3 - setup parameters (PIDs, switches, thresholds etc.)
For this last group of data the implementation is split again in PID & checkboxes, for which label text and data are transmitted from MWC; and other parameters for which only values are transmitted.

Now what all setup paramteters (type 3) have in common is,
- they are stored in eeprom,
- they are accessible via LCD configuration,
- label text is stored in LCD code already. The corresponding struct in LCD does even contain some info already on how to manipulate those data (increment, number of decimals).

So I propose we extend the serial protocol implementation to re-use those existing data structures (from EEPROM and/or LCD) and transmit those data including their label text, increment, number of decimals and have the GUI display those dynamically (similar to what was done for checkboxes before).

possible benefits:
- future changes to the set of setup parameters will become easier to implement both in MWC and GUI (could be as simple as extend the struct in LCD which must be done for LCDconfig anyway),
- provide data plus metadata for GUIs (like with checkboxes now) to become even more version independant,
- bring the three spheres (eeprom, lcd, serial transmission) which deal with those same setup data together to work on a common basis.
- maybe join EEPROM and LCD structs (LCD is kindof a superset of EEPROM struct),
- maybe remove redundant strings from protocol and lcd.config implementations

Comments, please?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby AlexM » Thu Jun 28, 2012 2:28 pm

Hi all,

First, big tip of the hat to all for such a great project. Have been following Multiwii for a bout 9 months now and the progress has been amazing. Im currently flying a quad X with a cirrus SE board. I have a UBLOX NEO-6M on order plus a 328p for the I2C-GPS NAV code.

I noticed the recent post from EOSBandi (Nice work with the ardupilot code port btw) regarding setting waypoints via serial. 2 Quick questions :

1, I understand WP 16 isthe pos hold WP, if i put the quad into pos hold and set WP 16 via serial (MSP_WP_SET), will the quad fly off to this new location ?
2, Is there a serial command/message that will output if the craft is at said waypoint or is within the pos hold area ?

Thanks

Alex
AlexM
 
Posts: 1
Joined: Sun Jun 10, 2012 1:34 pm

Re: New Multiwii Serial Protocol

Postby Alexinparis » Thu Jun 28, 2012 10:03 pm

Hi,

Hamburger wrote:So I propose we extend the serial protocol implementation to re-use those existing data structures (from EEPROM and/or LCD) and transmit those data including their label text, increment, number of decimals and have the GUI display those dynamically (similar to what was done for checkboxes before).

The principle of self describing parameters was not currently extended to other parameters because they are more tied to basic functions, and not optional functions.
There is however maybe something to think about a generic configuration message tied to the LCD conf framework.
Of course, after the 2.1 ;)

possible benefits:
- future changes to the set of setup parameters will become easier to implement both in MWC and GUI (could be as simple as extend the struct in LCD which must be done for LCDconfig anyway),
- provide data plus metadata for GUIs (like with checkboxes now) to become even more version independant,
- bring the three spheres (eeprom, lcd, serial transmission) which deal with those same setup data together to work on a common basis.
- maybe join EEPROM and LCD structs (LCD is kindof a superset of EEPROM struct),
- maybe remove redundant strings from protocol and lcd.config implementations

and possible drawbacks:
- flash memory footprint in case of not using LCD
- GUI will either become more complex (text parsing to detect the right parameter to graph at the right place) or less well arranged (assuming all parameters are graphed the same way)
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 29, 2012 8:45 am

Alexinparis wrote:and possible drawbacks:
- flash memory footprint in case of not using LCD
- GUI will either become more complex (text parsing to detect the right parameter to graph at the right place) or less well arranged (assuming all parameters are graphed the same way)

right.
It will become an experiment on tradeoffs.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby timecop » Sat Jun 30, 2012 1:54 pm

So I see the capability bit is there now.
I would like to use the top bit (0x80000000) to mean
#define PLATFORM_32BIT 0x80000000
or something to that effect.

This can be used with android stuff to detect what type of GUI to present (since 32bit stuff has CLI configurable features/settings).
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby sisco21 » Sun Jul 15, 2012 1:49 pm

Have you example how to use the serial for arduino to arduino?

I would read battery level on other arduino!
sisco21
 
Posts: 4
Joined: Fri Jul 13, 2012 12:24 pm

Re: New Multiwii Serial Protocol

Postby treym » Thu Jul 26, 2012 10:47 pm

RFC MSP 2.2


making field mandatory :
  • MSP_IDENT : so it reports the full MWC firmware version number, INCLUDING the patch level

adding new feature
  • MSP_INIT : send a init payload the flight controler
  • MSP_MOCKTX : emulator for TX/RX input for testing

convert some #defines to user configurable items
  • MSP_ tune esc refresh rate
  • MSP_ calib gyro
  • MSP_ configurable servo settings

make generic set/get and leverage the enum,storage decoder for those
  • MSP_ <key>_GET
  • MSP_ <key>_SET
Last edited by treym on Thu Jul 26, 2012 11:13 pm, edited 1 time in total.
User avatar
treym
 
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: New Multiwii Serial Protocol

Postby Tommie » Thu Jul 26, 2012 10:53 pm

What would MSP_INIT actually do? At the moment, the communication is stateless - every request is processed without context.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby treym » Thu Jul 26, 2012 11:05 pm

Tommie wrote:What would MSP_INIT actually do? At the moment, the communication is stateless - every request is processed without context.

MSP_INIT : send an init payload to the flight controler .

the init payload can be used like

Code: Select all
if (armed){
 if (init_payload){
   //do special thing here
   if (init_payload < INIT_MSP_UART2 ) switch the decoder  to uart2
   if (init_payload <INIT_MSP_OSD ) use osd msp decoder
   etc ..
 }
}
User avatar
treym
 
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: New Multiwii Serial Protocol

Postby Alexinparis » Fri Jul 27, 2012 9:52 am

treym wrote:
Tommie wrote:What would MSP_INIT actually do? At the moment, the communication is stateless - every request is processed without context.

MSP_INIT : send an init payload to the flight controler .

the init payload can be used like

Code: Select all
if (armed){
 if (init_payload){
   //do special thing here
   if (init_payload < INIT_MSP_UART2 ) switch the decoder  to uart2
   if (init_payload <INIT_MSP_OSD ) use osd msp decoder
   etc ..
 }
}


One purpose of MSP is to be agnostic to other devices like OSD.
We won't reintroduce particularities
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby treym » Fri Jul 27, 2012 7:38 pm

this was just an exemple , it can be used to set the home position to a specifice value , etc .. i dot not say it nust be include ;)
User avatar
treym
 
Posts: 258
Joined: Sat Jul 21, 2012 12:28 am

Re: New Multiwii Serial Protocol

Postby Mous94 » Fri Aug 24, 2012 9:43 am

hello,

Can you integrate this library in the code multiwii?

Here the library: http://www.billporter.info/easytransfer ... o-library/

I would like to use this library to send commands to multiwii from another arduino by serial link.

Another question:
Now I can not send a command with the method presented here:

here is my code to send commands to multiwii, where is my mistake?



Code: Select all


int Roll;
int Yaw;
int Throt;
int Pitch;
[...]
Serial.println("$");
Serial.println("M");
Serial.println("<");
Serial.println("32");
Serial.println("200");

Serial.println("Pitch") ; //  0 to 255
Serial.println("Roll"); //  0 to 255
Serial.println("Throt"); //  0 to 255
Serial.println("Yaw"); //  0 to 255


Serial.println("random"); //  bitwin 0 and 9


here is my code to send commands to multiwii, where is my mistake?
Mous94
 
Posts: 4
Joined: Fri Aug 17, 2012 5:31 pm

Re: New Multiwii Serial Protocol

Postby lorentz » Fri Sep 14, 2012 12:40 pm

Hello everybody,

May I make a request to add another command to MultiWii protocol for setting IMU data ?
The name could be MSP_SET_RAW_IMU and the code could be 210, currently not used.
Currently I'm implementing MultiWii protocol for STM32 on a home built prototype board:
https://code.google.com/p/cortex-ap/.
The additional protocol command would be useful during simulations.
Sensor data coming from flight simulators as X-Plane would be sent to the board replacing data froma actual sensors.
I did not find a similar request in the posts. Sorry if it's been already asked, anyway.
(as suggested by Hamburger, I copied here the same question posted to the wishlist for v2.2 thread)

Thank you.

Lorentz
lorentz
 
Posts: 8
Joined: Wed Sep 12, 2012 9:39 pm

Re: New Multiwii Serial Protocol / Using

Postby KaiK » Fri Sep 14, 2012 7:37 pm

Hi guys,

I am just implementing an airspeed measurement (differential pressure) into the MWC code and struggling about how to transfer the data (uint16=serialize16) via the serial protocoll. My first tought was transferring it via MSP_MISC which currently is only used by powermeterTrigger1 and has 8 free fields.

What do you think about this? Would it be ok or should we create a new serial protocoll space?

Regards,
Kai
KaiK
 
Posts: 58
Joined: Thu Jul 28, 2011 8:32 pm

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Sep 14, 2012 8:02 pm

Extending that existing command sounds good enough to me.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby timecop » Sat Sep 15, 2012 8:46 am

Why would airspeed need to be in misc msp with power meter junk. if there is no space in imu/sensors one, then make a new one.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby doughboy » Sun Sep 16, 2012 10:27 pm

is there any document that describes the old serial protocol?
I wanted to use LCD_Config (works with UNO with LCD kaypad shield) but it is not compatible with the new serial protocol. I don't think that software is actively maintained anymore so I want to see how much work is needed to update it to work with the new serial protocol.

thanks
doughboy
 
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: New Multiwii Serial Protocol

Postby KaiK » Sat Sep 22, 2012 3:17 pm

Hamburger wrote:Extending that existing command sounds good enough to me.

timecop wrote:Why would airspeed need to be in misc msp with power meter junk. if there is no space in imu/sensors one, then make a new one.


Any consent in this?
KaiK
 
Posts: 58
Joined: Thu Jul 28, 2011 8:32 pm

Re: New Multiwii Serial Protocol

Postby remzibi » Sun Sep 30, 2012 7:52 pm

Alexinparis wrote:MultiWii Serial Protocol

updated 04 July


Multiwii serial protocol was redesigned:
  • to be light, as before
  • to be generic: it can be used transparenlty by a GUI, OSD, telemetry or home made config tool.
    ie no more specific OSD code should be coded in multiwii
  • to be bit wire efficient: only requested data are transmitted in a binary format
  • to be quite secure: data are sent with a checksum, preventing corrupted configuration to be injected.
  • to be header sensitive: as it is designed with a specific header, it can be mixed with other frame, like GPS frame
    ie, it will be possible to connect either a GUI or a GPS on the same serial port without changing the conf
  • to be less sensitive to evolutions:
    ie in case of parameter evolution, the main protocol will remain compatible and the GUI will be much less version dependent.
    variable data length allows to consider only the beginning of a message, leaving the other octets at the end to extend transparently the message (for instance to add a new PID)

I thought first about an implementation of Mavlink, but I think it's not what I was looking for.
Even with a partial implementation, the predefined structures are not light enough for what I have in mind.
Some messages are however inspired from mavlink structure.

The main rule remains: Multiwii never sends something on its own.
A request must be done in each case to retrieve or set data.
Each messages received are acknowledged even if there is no data inside.

There are 2 main messages to consider:
  • request message to multiwii
  • multiwii output message

request message to multiwii
To request simple data without parameters / send a specific command / inject new parameters in multiwii
messages are formated like this:
$M>[data length][code][data][checksum]
1 octet '$'
1 octet 'M'
1 octet '<'
1 octet [data length]
1 octet [code]
several octets [data]
1 octet [checksum]


[data length] can be 0 in case of no param command

multiwii output message
messages are formated like this:
$M>[data length][code][data][checksum]
1 octet '$'
1 octet 'M'
1 octet '>'
1 octet [data length]
1 octet [code]
several octets [data]
1 octet [checksum]


if the message is unknown:
$M|[0][code][checksum]
1 octet '$'
1 octet 'M'
1 octet '|'
1 octet 0
1 octet [unknown code]
1 octet [checksum]



list of message codes
multiwii output message
MSP_IDENT
multitype + version
MSP_STATUS
cycletime & errors_count & sensor present & box activation
MSP_RAW_IMU
9 DOF output
MSP_SERVO
8 servos
MSP_MOTOR
8 motors
MSP_RC
8 rc chan
MSP_RAW_GPS
fix, numsat, lat, lon, alt, speed
MSP_COMP_GPS
distance to home, direction to home
MSP_ATTITUDE
angles and heading
MSP_ALTITUDE
altitude
MSP_BAT
vbat, powermetersum
MSP_RC_TUNING
rc rate, rc expo, rollpitch rate, yaw rate, dyn throttle PID
MSP_PID
table of P I D
MSP_BOX
tabl of checkbox
MSP_MISC
powermeter trig
MSP_MOTOR_PINS
which pins are in use for motors & servos, for GUI
MSP_BOXNAMES
the textual aux switch names (it's a way to build a more generic GUI, allowing an easier extension for future checkbox)
MSP_PIDNAMES
the textual PID names
MSP_WP
get a WP, WP# is in the payload, returns (WP#, lat, lon, alt, flags) WP#0-home, WP#16-poshold
MSP_DEBUG
debug1,debug2,debug3,debug4 variable

multiwii input message
MSP_SET_RAW_RC
8 rc chan: it's a way to command multiwii via a "serial RC transmitter"
MSP_SET_RAW_GPS
fix, numsat, lat, lon, alt, speed: it's a way to inject in multiwii GPS data coming for instance from an OSD with an integrated GPS
MSP_SET_PID
8 P I D
MSP_SET_BOX
11 checkbox
MSP_SET_RC_TUNING
rc rate, rc expo, rollpitch rate, yaw rate, dyn throttle PID
MSP_ACC_CALIBRATION
to calibrate ACC
MSP_MAG_CALIBRATION
to calibrate MAG
MSP_SET_MISC
powermeter trig
MSP_RESET_CONF
to reset all params to default (new feature)
MSP_EEPROM_WRITE
to write current params to EEPROM


Hello and congratulation for super MWC project .

Well I am trying to write firmware to remzibiOSD to cooperate with this new protocol of MWC , but I got "information problem" , probably because I am short of time .
Is anywhere available description of this protocol where MWC is a simply "black box" .
I mean , for me MWC is a "black box" and need to know detailed information what to send including bytes values and what can I expect at answer from MWC .
For example I am sending :
$M< MSP_ATTITUDE - what is MSP_ATTITUDE byte value ? and what expect a MWC respond (as byte values) ?

So question - is anywhere any link where I can download description of this protocol , as MWC is "black box" ?

Maybe basic examples what to send and what to receive to get Artifial Horizon ,
and then also GPS data to display at OSD ?
OSD basically utilize GPS data and AH data only .

MWC as "black box" made on two UART ports can use one for GPS and another for communication - that clear .
MWC as "black box" made on atmega328 have only one UART , can it share this UART used for GPS with other device like OSD (then OSD will use his hardware UART TX and RX for communication only) , or RX line of MWC will for GPS receiving and TX for data sending continously after power-up (like for example FYxx family devices , made connection exremly easy https://sites.google.com/site/remzibios ... remzibiosd or https://sites.google.com/site/remzibios ... remzibiosd ) ? Just for consider .
How to connect mega328 version to OSD ?
remzibi
 
Posts: 2
Joined: Mon Jun 04, 2012 12:15 pm

Re: New Multiwii Serial Protocol

Postby Sebbi » Sun Sep 30, 2012 11:58 pm

Take a look at the GUI code (MultiWiiConf) and Serial.ino from MultiWii ... everything you need to know about the protocol and how to parse it is there.

As I understand it, MultiWii has no mode where it can continuosly send data (attitude and gps is what your need, right?). You can only do that as a patch and maybe it gets included as an config.h option? The problem is basically the same as with other telemetry systems on the 328 µC ... either you use shared serial, software serial (uses some bytes and increases cycle time) or use an I2C GPS. The last option seems to be what people do, because it's easy, cheap and already supported.

It will take a long time until everybody upgrades to the mega2560 (or even fancies µCs) and finally abandons wii sensors (which are awful, admit it already! *g*). Until then people have to be creative with the available code space :/
Sebbi
 
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany

Re: New Multiwii Serial Protocol

Postby dramida » Mon Oct 01, 2012 9:39 am

Hello Mr Remzibi, i salute your initiative.
As a 10 DOF Mega2560 board costs 63 usd ( http://www.rctimer.com/index.php?gOo=go ... oductname= ), i suggest firstly to write a serial OSD only for Mega Flight controllers. A further implementation should be i2C com for 328 FC.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: New Multiwii Serial Protocol

Postby mightyfrog » Thu Oct 18, 2012 7:22 pm

Hi,

I developed a small and opensource Android app to control a vehicle through bluetooth. After I'd see the new protocol for the MWC 2.1, I decided to use this one instead of my own protocol. But as I tested it on my MWC quadrocopter (only with a bluetooth dongle on it), it only works for a couple of seconds and stuck after that. With a testsoftware on my MacBook and a FTDI cable to the MWC it works all the time. I checked the App also and it sends all the time correct packets.

Any ideas?

The software is available here: http://www.mightyfrog.eu/downloads.html
mightyfrog
 
Posts: 1
Joined: Thu Oct 18, 2012 7:16 pm

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Oct 18, 2012 7:25 pm

I have held back saying this because I have not fully tested it yet but there maybe some Bluetooth latency issues with the new protocol

http://www.free2move.se/?page_id=1058
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby werty » Tue Nov 20, 2012 11:33 am

Hi everyone, i have a question.
I'm using MW firmware 2.1 and GUI with a y6 configuration. I want to drive MW with arduino 1280, so i wrote my own arduino library(to be honest i copied some parts from GUI code) for communucation with MW, because arduino need some data like heading,altitude etc. But i have a problem, while arduino reading the data. I wrote the altitude value to the serial monitor via arduino, but it is really unacceptable. I've read the values between -200 and 200,while MWconf reads between 130 and 135. How gui shows this nearly constant value?
I looked to the MWconf GUI codes, and i understood that GUI read altitude data and divide by 100 then write the valus to the screen. Am I right? I couldnt find any filtering algorithm.
Can anyone help me please?
werty
 
Posts: 4
Joined: Wed Oct 17, 2012 1:04 pm

Re: New Multiwii Serial Protocol

Postby werty » Mon Nov 26, 2012 4:59 pm

i solved.
read32 function doesnt work properly in arduino IDE 0.23. Use the functions like this.
Code: Select all
int read32()
  {
     float t=0;
     t+=(inBuf[p++]&0xff);
     t+=((inBuf[p++]&0xff)<<8);
     t+=((inBuf[p++]&0xff)<<16);
     t+=((inBuf[p++]&0xff)<<24);
     return t;
  }
  int read16()
  {
     float t=0;
     t+=(inBuf[p++]&0xff);
     t+=((inBuf[p++]&0xff)<<8);
     return t;
  }
werty
 
Posts: 4
Joined: Wed Oct 17, 2012 1:04 pm

Please insert in the 1. post "Protocol for the ver. 2.1"

Postby Stephan Oldenburg » Thu Jan 03, 2013 11:28 pm

First of all: thank you very much for all the work and the new protocol ! :)

I'm new in this forum and I want to shortly introduce myself:
I'm Stephan an I startet with a friend of mine in the north of Germany (Oldenburg) a Multiwii project with the goal to create a autonomus flying quadrocopter "AQUA". This is the project page: http://www.keten.de

At the moment we try to connect a Raspberry Pi with the FC by serial and use mostly this great threat for making the main program.

When we recieved the FC (MWC Crius SE), the 2.0 software was installed. We thought that the "new serial protocol" as described in the 1. post was also für version 2.0. It costs us some hours to find out that it's not.

Mayby it's a good idea, to write clearly in the 1. post that the new serial protocol it only for verson 2.1.

After flashing the FC to ver. 2.1, it works fine. :)

I don't want to write here more details from our project, because this threat should only be for the protocol. I'll open a new one for everybody who is interested in.

Thank You and sorry for my "german" english! ;-)
Stephan Oldenburg
 
Posts: 25
Joined: Thu Jan 03, 2013 11:04 pm

Re: New Multiwii Serial Protocol

Postby Gimbal » Mon Jan 14, 2013 1:18 pm

Hi, I guess that the new serial is interrupt driven is there any chance to have some kind of priority for the interrupt? ex uart1 for sbus, it's getting out of sync and creates glitches.
I don't have this problem with 2.0
Last edited by Gimbal on Mon Jan 14, 2013 1:43 pm, edited 1 time in total.
Gimbal
 
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: New Multiwii Serial Protocol

Postby timecop » Mon Jan 14, 2013 1:40 pm

AVR has no interrupt priority
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby Gimbal » Mon Jan 14, 2013 1:51 pm

Well thnx that's enlightening, I think that ever since the new serial protocol my sbus been f-up, can i do it some other way "noInterrupts/interrupts" wile sbus are reed ?
Gimbal
 
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: New Multiwii Serial Protocol

Postby copterrichie » Mon Jan 14, 2013 2:29 pm

I think we need to investigate a polling routine for the serial ports verse interrupt driven. Then priorities can be assigned.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Gimbal » Mon Jan 14, 2013 3:01 pm

polling routine sounds interesting will look in to it
Gimbal
 
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: New Multiwii Serial Protocol

Postby Alexinparis » Tue Jan 15, 2013 10:48 am

Gimbal wrote:Hi, I guess that the new serial is interrupt driven is there any chance to have some kind of priority for the interrupt? ex uart1 for sbus, it's getting out of sync and creates glitches.
I don't have this problem with 2.0


I don't think it's a priority problem.
The sbus pace is much lower than what can be decoded on the serial stream

The problem is more deep: when using a sbus receiver, the MSP serial decoding process is not cancelled on this port.
It should be excluded like it's done with Spektrum receivers.
=> need some code rework.

you can try in serial.ino:
while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND) {
=>
while (SerialAvailable(CURRENTPORT) GPS_COND SPEK_COND && CURRENTPORT != 1) {
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Gimbal » Tue Jan 15, 2013 8:24 pm

That's it :-) Thank you so very much, sbus is so smooth now with out glitches. :D

Anders

"if (sbus[24] == 0x0){" need's to be inserted in RX.ino to check stop byte

Code: Select all
sbus[sbusIndex++] = val;
    if(sbusIndex==25){
      sbusIndex=0;
      if (sbus[24] == 0x0){**********************************************

bla
bla

}
Gimbal
 
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: New Multiwii Serial Protocol

Postby Olstyle » Tue Jan 15, 2013 10:56 pm

I am trying to use "Serial1" on an Mega32u4("Leonardo") instead of the USB one for main communication(hoping to be able to use remote config and serialrc via an bluetooth bridge). Is this already possible with the 2.1 codebase? What I tried so far was changing the hardcoded calls to the serial functions from "0" for the port to an define which i then set to 1, but this doesn't seem to be enough.

Reading further, I discovered that those function are using a mix of arduino lib calls and avr lib calls and some seemed to just set the port to zero whenever another port was used to call them. Trying to change those, I created some crazy compile errors. So here I am asking if anyone has done what I am trying to do or can offer advice on it.

EDIT:Looks like the current dev version got this solved(looking at the code, I did not yet try it in reallife).
Olstyle
 
Posts: 4
Joined: Sun Jan 13, 2013 6:29 pm

Re: New Multiwii Serial Protocol

Postby mcashatt » Tue Jan 22, 2013 1:20 am

Hey guys,

I have modified my own copy of MWC 2.1 to check certain flags in every iteration of the main loop and then send a numerical value over Serial1 (I am using a Mega board) to a separate Arduino Nano which is being used to drive LED strips on my quad. That code is attached. On the first line of the main loop you will see 'statusMessages(); ' which calls a method in the "StatusMessages.ino" file.

The flags I get are things like armed status, whether or not the throttle is > throttleMin (i.e. are the props spinning?), hold modes, etc.

This works beautifully when I simply hook the board up to a usb and grab my transmitter to do things like arm, acc hold, etc. The Arduino Nano (my LED driver) reads the incoming serial data perfectly and changes light patterns on the LED strips. No problem.

Unfortunately, today I hooked up the battery (rather than USB) for the first time to run this setup on an actual quad and the LED strips did not behave as expected--there was no response to changing status messages at all. Well, I hooked back up to USB, and it behaved. Battery--fail. Hmmm. . .

I hooked the Nano up to my PC via USB and added a line to write the incoming status messages from my Crius AIOP to my serial monitor and discovered that, when I the Crius is hooked to the battery rather than the USB, all status messages received on the Nano are "-1": no data received.

Does anyone have any ideas why I can get the data I need when the Crius is being run on the USB but not when it is powered by the ESCs/battery?

Thanks,

Matt
Attachments
MultiWii_AIOP_GPS_Lights.zip
(113.72 KiB) Downloaded 76 times
mcashatt
 
Posts: 30
Joined: Sun Sep 30, 2012 7:04 am

Re: New Multiwii Serial Protocol

Postby mcashatt » Tue Jan 22, 2013 1:33 am

UPDATE: Thinking that the problem could be specific to the Crius AIOP, I just tried the same thing with an MWC PRO 2.0 board and had the same problem. It works fine if I hook up the USB or use my Arduino Nano to power the MWC. Status messages are sent from Serial1 to the Nano every time I do something like arm or disarm and all is well. But when I instead power the MWC from the ESCs (i.e. hook up the lipo rather than power from USB), then suddenly Serial1 stops sending messages to my Arduino Nano.

My simple mind is really struggling to understand why this may be happening and any help will make a sane man of me. My baud rate for Serial1 is 115200 if that matters. I set it that high arbitrarily so it can change if necessary.

Thanks!
mcashatt
 
Posts: 30
Joined: Sun Sep 30, 2012 7:04 am

Re: New Multiwii Serial Protocol

Postby mcashatt » Tue Jan 22, 2013 1:56 am

Here is some sample code for the other Arduino (in my case the Nano) that will receive the messages. Please see attached.

Thanks,

Matt
Attachments
MWC_Monitor.zip
(681 Bytes) Downloaded 146 times
mcashatt
 
Posts: 30
Joined: Sun Sep 30, 2012 7:04 am

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 9 guests

cron