PatrikE wrote:If you adjust the MSP length you need more intelligence on the reciever side.
isn't that the reason for sending the headSerialReply(18);?
The gui expects a preset length and will go nuts if there's missing data. The easiest way is to send fixed values for unused values.
sure
A alternative is to use a MSP_INIT at the connection who informs the gui what to expect. In same manner as the checkBoxes.
that information is already being sent at beginning of MSP response via headSerialReply(xx), so nothing needs to be invented here.
It is something that was left undefined when setting up the NewMSProtocol - has an MSP a predefined length every gui can trust ( then headSerialReply() is superfluous; - or is the length determined at runtime depending on available sensors etc. and thus some trailing values could be omitted and the headSerialReply() be adapted on the fly.
Another undefined behaviour is whether all predefined MSPs must be implemented in an MWC or can MWC reply safely saying 'unknown MSP'? Probably only for some MSPs; which?
Re: New Multiwii Serial Protocol
Posted: Thu Feb 28, 2013 4:38 pm
by PatrikE
Must start with to say The serial communication is nothing i fully understand.
that information is already being sent at beginning of MSP response via headSerialReply(xx), so nothing needs to be invented here.
Tru.. But headSerialReply(xx) only contains the size of the package. No information about the content.
If you have a adaptive MSP and and YY_Data is removed from the Package and adjust headSerialReply(7) to 6. Then it works.
But if you remove II_Data and adjust size to 5 it will not work. Because the gui oly kow the size but not what to expect and read wrong data from the Package.. The gui need to know what data who's removed.
Another way is to make more MSP's with less data in! And use 'unknown MSP'. Mwii will only answer on valid calls. But it will result in a serial.ino that's bigger than miultiwii.ino.
Best would be a smarter headSerialReply that send more info.
Re: New Multiwii Serial Protocol
Posted: Thu Feb 28, 2013 5:44 pm
by Hamburger
You avoidmany such problems if you only allow to remove data from the end backwards but not from the middle.
Re: New Multiwii Serial Protocol
Posted: Tue Mar 05, 2013 1:50 pm
by agama
Back to the question of the common specification of the protocol. I start this work. Don't know how it's useful. If I wrong, correct me.
I think it would be very nice to have a command to start each motor from the gui for maintenance reasons. Imagine a problem with an octocopter with every ESC contact soldered. If you want to do dynamic balancing or find a defective bearing it would be very nice to access every motor with a slider from the gui. One slider would do it with a box to select the motornumber. That's just an idea. Cheers Rob
Re: New Multiwii Serial Protocol
Posted: Sat Mar 09, 2013 8:44 pm
by ezio
Crashpilot1000 wrote:I think it would be very nice to have a command to start each motor from the gui for maintenance reasons. Imagine a problem with an octocopter with every ESC contact soldered. If you want to do dynamic balancing or find a defective bearing it would be very nice to access every motor with a slider from the gui. One slider would do it with a box to select the motornumber. That's just an idea. Cheers Rob
+1
or possibility to control only one motor from the radio
you know, this is great! we should have a documentation like this for everything.
Bart
Re: New Multiwii Serial Protocol
Posted: Sat Mar 09, 2013 11:01 pm
by PatrikE
or possibility to control only one motor from the radio
It was done in V1.7 for dynamical balancing motors from Gui. By Jibeer.
Lots of changes have been made in the project since. But baby it can be updated to support all new boards.
Ps Read Info.txt
Re: New Multiwii Serial Protocol
Posted: Fri Mar 29, 2013 10:37 pm
by Andresc4
Hello guys, im kind of newbie on arduino, and i have a few question about the protocol can anybody show me an example of how to request data from a arduino sketch via rs232 to get the roll/pitch/yaw of the sensors ? because on the command list i saw the raw data, but i would like to get the data that is isued to draw and move the aircraft 3d model im tring to do a vr.headset, im usising vvvv but i can handle the rs232 protocol without any problem viewtopic.php?f=23&t=3321&p=33946#p33946
i just made that post and im really lost here, i dont have much arduino skills at the moment, any help will be appreciated
For example, i have the hardware ready, and the sketch uploaded i can run the multiwii conf and it works just fine
i woluld like to know how i can get that data from the arduino IDE serial monitor,,, i need to make a connection of 115200 baud, and after that, how i compose the string to request the roll/pitch/yaw angles ?
- In 2.1 source code (and also on first page of this thread) is header $M , in doc is M$ - samples are using calculation method where initial crc is 255 so in case of zero lenght is crc calculated as (255 ^ MessageType), but my 2.1 xcopter accept 0^MessageType
- In 2.1 source code (and also on first page of this thread) is header $M , in doc is M$ - samples are using calculation method where initial crc is 255 so in case of zero lenght is crc calculated as (255 ^ MessageType), but my 2.1 xcopter accept 0^MessageType
there are apparently some errors in this pdf. (inversion M and $) initial crc is 0
Re: Odp: New Multiwii Serial Protocol
Posted: Sun Apr 21, 2013 11:04 pm
by Alexinparis
ezio wrote:Maybe someone could implement a possibility to control gimbal pitch and roll via MSP protocol? I have some crazy ideas
Bart
gimbal can be controlled via AUX channel so this is normally possible via RCSERIAL and MSP_SET_RAW_RC message, but in this case you have to control the whole 8 channels, not really ideal. you could maybe adapt MSP_SET_RAW_RC to not update a specific channel is the sent value is 0 for this channel.
Re: Odp: New Multiwii Serial Protocol
Posted: Sun Apr 21, 2013 11:21 pm
by ezio
Alexinparis wrote:
ezio wrote:Maybe someone could implement a possibility to control gimbal pitch and roll via MSP protocol? I have some crazy ideas
Bart
gimbal can be controlled via AUX channel so this is normally possible via RCSERIAL and MSP_SET_RAW_RC message, but in this case you have to control the whole 8 channels, not really ideal. you could maybe adapt MSP_SET_RAW_RC to not update a specific channel is the sent value is 0 for this channel.
Yes I know that I can use RCSERIAL. I tried it but it is no very good. Maybe it will be possible to make MSP command only for control a camera ? Which can overwrite controls from the radio? My knowledge about multiwii code is minimal so I don't want to mess with it. Thanks Bart
Re: New Multiwii Serial Protocol
Posted: Sat Apr 27, 2013 6:24 pm
by PatrikE
I would like to add some more flags in MSP_STATUS:
For the Gui to know what functions is enabled in FC. I have temporarily added some flags to the current struct.
Perfect for me will be comment like this //minthrottle int16 //maxthrottle int16 //lifetime int32 etc
Bart
Re: Odp: New Multiwii Serial Protocol
Posted: Wed May 01, 2013 11:16 pm
by Alexinparis
ezio wrote:
Alexinparis wrote:
ezio wrote:Maybe someone could implement a possibility to control gimbal pitch and roll via MSP protocol? I have some crazy ideas
Bart
gimbal can be controlled via AUX channel so this is normally possible via RCSERIAL and MSP_SET_RAW_RC message, but in this case you have to control the whole 8 channels, not really ideal. you could maybe adapt MSP_SET_RAW_RC to not update a specific channel is the sent value is 0 for this channel.
Yes I know that I can use RCSERIAL. I tried it but it is no very good. Maybe it will be possible to make MSP command only for control a camera ? Which can overwrite controls from the radio? My knowledge about multiwii code is minimal so I don't want to mess with it. Thanks Bart
It's now possible to control only relevant channels via MSP_SET_RAW_RC. just set the other to 0 and the rc values for thoses chans will be used from the legacy RX receiver. example: you want to control gimbal with AUX3 & AUX4, just send 0 / 0 / 0 / 0 / 0 / 0 / AUX3 / AUX4 values via MSP_SET_RAW_RC
Re: New Multiwii Serial Protocol
Posted: Wed May 01, 2013 11:18 pm
by Alexinparis
PatrikE wrote:I would like to add some more flags in MSP_STATUS:
For the Gui to know what functions is enabled in FC. I have temporarily added some flags to the current struct.
st.sensor = ACC|BARO<<1|MAG<<2|GPS<<3|SONAR<<4|DYNBAL<<5|RC_SERIAL<<6|FLAPRNS<<7|FLAP<<8;// Added some extra flags for Gui
A new struct st.functions Containing information for Gui What to show or not. Motors Tab should only be visible if DYNBAL is enabled.
Ex info in settings tab about. Failsafe. GYRO_SMOOTHING. SERVO_TILT SERVO_MIX_TILT
could you list all the functions you have in mind ?
Odp: New Multiwii Serial Protocol
Posted: Fri May 03, 2013 5:18 pm
by ezio
Alexinparis wrote:
ezio wrote:
Alexinparis wrote:[quote="ezio"]Maybe someone could implement a possibility to control gimbal pitch and roll via MSP protocol? I have some crazy ideas
Bart
gimbal can be controlled via AUX channel so this is normally possible via RCSERIAL and MSP_SET_RAW_RC message, but in this case you have to control the whole 8 channels, not really ideal. you could maybe adapt MSP_SET_RAW_RC to not update a specific channel is the sent value is 0 for this channel.
Yes I know that I can use RCSERIAL. I tried it but it is no very good. Maybe it will be possible to make MSP command only for control a camera ? Which can overwrite controls from the radio? My knowledge about multiwii code is minimal so I don't want to mess with it. Thanks Bart
It's now possible to control only relevant channels via MSP_SET_RAW_RC. just set the other to 0 and the rc values for thoses chans will be used from the legacy RX receiver. example: you want to control gimbal with AUX3 & AUX4, just send 0 / 0 / 0 / 0 / 0 / 0 / AUX3 / AUX4 values via MSP_SET_RAW_RC[/quote] Great I will try it. Is it safe to do it in flight?
Re: New Multiwii Serial Protocol
Posted: Tue May 07, 2013 8:19 am
by cGiesen
Hello,
I see in MSP_IDENT I got Version and MSP_Version A good idea! But why is MSP_Version = 0
I aspect perhaps 221 to see thats the new protocol because of the boxes!
Regards Carsten
Re: Odp: New Multiwii Serial Protocol
Posted: Tue May 07, 2013 9:20 am
by Alexinparis
ezio wrote:
It's now possible to control only relevant channels via MSP_SET_RAW_RC. just set the other to 0 and the rc values for thoses chans will be used from the legacy RX receiver. example: you want to control gimbal with AUX3 & AUX4, just send 0 / 0 / 0 / 0 / 0 / 0 / AUX3 / AUX4 values via MSP_SET_RAW_RC
Great I will try it. Is it safe to do it in flight?
yes, it should be safe in flight. It’s the purpose However, the channel value overriding via MSP only lasts around 0.5s. After this delay, the conventional RC values are used. So you must refresh MSP_SET_RAW_RC at a higher pace is you want a permanent overriding of specific channels.
Re: New Multiwii Serial Protocol
Posted: Fri May 10, 2013 8:34 am
by cGiesen
@ALEXINPARIS
Is it possible to get an answer please?
cGiesen wrote:Hello,
I see in MSP_IDENT I got Version and MSP_Version A good idea! But why is MSP_Version = 0
I aspect perhaps 221 to see thats the new protocol because of the boxes!
- In 2.1 source code (and also on first page of this thread) is header $M , in doc is M$ - samples are using calculation method where initial crc is 255 so in case of zero lenght is crc calculated as (255 ^ MessageType), but my 2.1 xcopter accept 0^MessageType
I see in MSP_IDENT I got Version and MSP_Version A good idea! But why is MSP_Version = 0
I aspect perhaps 221 to see thats the new protocol because of the boxes!
Regards Carsten
Hi,
MSP_VERSION has not been used for the moment. We can update it for the next release if it helps to solve ambiguity. About multiwii version, everything after 220 should be considered as dev and unstable
Re: New Multiwii Serial Protocol
Posted: Sat Jun 01, 2013 10:34 am
by mehranpour
I WANT TO impeliment new gui for multiwii with labview can any one say me an example of command to send to arduino? i have sent : $M< MSP_ATTITUDE
is it true?
Re: New Multiwii Serial Protocol
Posted: Thu Jun 06, 2013 1:40 am
by ezio
it MultiWii.ino the comment ("// variometer in cm/s") is wrong:
if you are interested in board communication via LabVIEW, send me a private message. I am sure I have what you want
best greetings from Munich,
Carsten
Re: New Multiwii Serial Protocol
Posted: Tue Jul 23, 2013 8:22 am
by felixrising
Hi,
Haydent has prepared a patch which includes a change to MSP, specifically MSP_ANALOG. The patch outputs Amps, not just the product of amps over time (pMeterSum). It would be good if two sets of battery measurement were available over MSP_ANALOG, namely vbat0,vamp0,vpsum0,rssi,vbat1,vmamp1. Or something like that. This would be good so that OSDs like the Rush OSD (minimosd) can consume and present this info to monitor both main and video battery stats without hardware hacks.
Cheers
Re: New Multiwii Serial Protocol
Posted: Tue Jul 23, 2013 10:38 am
by haydent
thanks felix, hamburger gave me some things to check about my changes and directed me here, once that done ill post back here with the results
Re: New Multiwii Serial Protocol
Posted: Fri Jul 26, 2013 12:55 pm
by Hamburger
the extended MSP is in r1542
Re: New Multiwii Serial Protocol
Posted: Fri Jul 26, 2013 4:20 pm
by icedfusion
Hi,
I am trying to write a small win app for myself just to learn. However, I am really struggling to get communication with my board. I know it works as using mulitwiiconf/wingui work fine.
From looking at the protocol and what is happening in the multiwii conf things like reasonably simple. All I want to get is the raw imu data - so I send the following message:
I would then expect to read the serial port and see the response?
As this did not work in my app, I opened up a serial program (Hercules) and tried to send the same data and see if I got a response - just to see if my program was at fault , but I still do not get anything. I have read through alot of this thread but apart from post 1 there is not much to go on.
Is my simple request created correctly? Any pointers greatly appreciated.
Cheers
ice.
Re: New Multiwii Serial Protocol
Posted: Fri Jul 26, 2013 10:03 pm
by icedfusion
Thanks to nicodh, I think i have found my issue.
ice.
Re: New Multiwii Serial Protocol
Posted: Tue Aug 06, 2013 1:49 am
by dfruehwald
I was searching all day for this info and then just randomly stumbled on it tonight.
This is cool. I discovered Red Bear Lab makes an Arduino BT 4.0 interface that works with iOS Core Bluetooth without having to jump through the Apple MFI hoops. Kinda hoping either I or some other industrious iPad/iPhone hacker can make an iOS app like the Android one.
Re: New Multiwii Serial Protocol
Posted: Fri Aug 09, 2013 7:35 pm
by scanman
if you want to see whats going on with the msp the easiest thing is to download a serial port monitor program and run it on the serial port that multiwii gui is using to talk to the board you can then see exactly the commands coming and going it saves a lot of time you can also run it when your program is running and you can see the difference between what your program is sending and what multiwii gui is sending and you will often see you are sending crlf or some other character that the board doesnt understand then correct your code and and keep trying till you are sending the correct data most of these serial port monitor programs show you in hex ascii and decimal most of them are free for limited time which is enough to get you going just google serial port monitor program
Re: New Multiwii Serial Protocol
Posted: Thu Oct 31, 2013 11:34 pm
by haydent
Hamburger wrote:the extended MSP is in r1542
hope its not too late to squeeze this into 2.3, but here is a patch to add amperage display to the GUI
Hi guys, I'm trying to write a small communication app with my multiwii board. But information on the protocol is very scattered allover the thread and internet... Can someone provide me with a valid link to MultiwiiSerialProtocol(draft)v04.pdf document? Above links are invalid :/
Also is there any change in the protocol, because I'm sniffing between multiwii and the gui and I get this:
How could that request be valid? I'm sending the same request after that as a single command and can't receive anything... Help is much appreciated.
Re: New Multiwii Serial Protocol
Posted: Wed Feb 04, 2015 11:06 am
by panji
how to parse the sensor data multiwii ? in com serial arduino
Re: New Multiwii Serial Protocol
Posted: Wed Feb 04, 2015 4:23 pm
by waltr
There is basic info on the MSP in the multiwii wiki. The command table is not up to date therefore you will need to study the source code to get all of the Valid commands and how they are used.
Re: New Multiwii Serial Protocol
Posted: Mon Mar 16, 2015 12:38 am
by eyalhe
hey, will I be able to use a raspberry pi to control my FC threw serial protocol (using usb port)? and is there any better guide to all the functions as not everything is clear here, thanks!
Re: New Multiwii Serial Protocol
Posted: Mon Mar 16, 2015 2:39 am
by waltr
Unfortunately the only other guide is the source code.
This would be a way to control the FC from an R-Pi. You will need to work out how to use the MSP. A look at the multiwiconf.exe source code may help.
Re: New Multiwii Serial Protocol
Posted: Fri May 15, 2015 5:25 pm
by Luft
Hey everyone. I've used MSP_SET_RAW_RC to great effect in the past... but I'm running into some issues and was wondering if anyone could weigh in on this! I was under the impression that MultiWii keeps the last raw RC values you send it. MultiWii seems to act on every packet I send it, but only for a split second. For example, I will sent it an arm command, and it will arm but the throttle will be high. When I arm and fly it around via transmitter, then send it raw RC commands over serial (high thrust), it will act on the command and seem to "reset" to a different, lower thrust in a split second. I have not experienced this behavior and was wondering if anyone has any idea of what's going on.
Here is a sample arm packet that my code constructs: Arm: 24 4D 3C 10 C8 DC 05 DC 05 DC 05 E8 03 D0 07 E8 03 E8 03 E8 03 D6 (1500, 1500, 1500, 1000, 2000, 1000, 1000, 1000) with MultiWii being configured to arm when AUX1 = HIGH (2000).
Why would MultiWii not be holding the previous RC values until specified otherwise? I've additionally disabled all failsafes.
Thanks all.
Re: New Multiwii Serial Protocol
Posted: Fri May 15, 2015 6:25 pm
by waltr
Is there another RC input that is being read and used?
You really need to look at the code. My guess is that it is still reading the RC channel input pins.
Re: New Multiwii Serial Protocol
Posted: Mon May 18, 2015 12:22 am
by jaysonragasa
Hi, I about this MSP_SET_RAW_RC. I am also using this with my Windows Phone application to control the multiwii flight with its virtual joystick.
watch here
I am using MultiWii 2.4 by the way.
I made this possible by suppressing all the values coming in from the Rx
if I did not do this, it will have the same issue with @Luft posts
MultiWii seems to act on every packet I send it, but only for a split second
which is true and readRawRC will still dominate the control.
so now that the I was able to suppress the values from Rx, I can use all 8 channels. that includes 4 AUX
pros: I can control my quad smoothly using the virtual joystick
cons: If I lost the BT signal, I will not be able to gain my control back even if using my Tx. I am currently updating my code to make a workaround.
Re: New Multiwii Serial Protocol
Posted: Mon May 18, 2015 10:55 pm
by Alexinparis
Hi,
jaysonragasa wrote:
MultiWii seems to act on every packet I send it, but only for a split second
which is true and readRawRC will still dominate the control.
This is exactly what is expected. MSP_SET_RAW_RC should be sent nearly the same way as a normal TX flow (20ms), in fact at a pace which is compatible with a full remote control. 1s is clearly not enough.
cons: If I lost the BT signal, I will not be able to gain my control back even if using my Tx. I am currently updating my code to make a workaround.
That's why in the current implementation, if the MSP_SET_RAW_RC flow is lost more than a second then readRawRC replaces the valid TX signal. Consider it as a failsafe to still be able to control the multi if UART system has a problem. Imagine the situation where you loose the BT signal + full throttle + horizon mode
Alexinparis wrote:This is exactly what is expected. MSP_SET_RAW_RC should be sent nearly the same way as a normal TX flow (20ms), in fact at a pace which is compatible with a full remote control. 1s is clearly not enough.
If I do not suppress the signal coming in from Rx, what will happen is whenever I send a values using my virtual joystick, the signal coming in from Rx dominates the response. That means, I have no control over my virtual joystick. That's the reason why I had to suppress it.
Imagine the situation where you loose the BT signal + full throttle + horizon mode