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
copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Interesting, thank you.

However, I was thinking more along the likes of checking a flag or an Interrupt.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Question, using this example "UCSR0B |= (1<<UDRIE0);", how would I send data to Serial Port 3?

Thank you.

Edited: I got it now. :D

I need to add something similar to this to handle the port.

This is for Serial0, so I need to duplicate it for Serial3

Code: Select all

ISR_UART {
    if (headTX != tailTX) UDR0 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR0B &= ~(1<<UDRIE0); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }


Code: Select all

#if !defined(PROMICRO)
  ISR_UART {
    if (headTX != tailTX) UDR0 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR0B &= ~(1<<UDRIE0); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }
#if defined(MEGA)
  ISR_UART3 {
    if (headTX != tailTX) UDR3 = bufTX[tailTX++];  // Transmit next byte in the ring
    if (tailTX == headTX) UCSR3B &= ~(1<<UDRIE3); // Check if all data is transmitted . if yes disable transmitter UDRE interrupt
  }
#endif

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Here is a copy of the draft Serial.ino, bench testing on Serial0 and Serial3. In theory, it can be configured to work on all of the four serials but there is only coded for Serial0 and Serial3.

Config.h File:

Code: Select all

// Serial Telemery Information Sent to another serial port (Mega)
#define TELEMERY_SERIAL 3
#define TELEMERY_BAUD 115200


Main File under Setup:

Code: Select all

#if defined(TELEMERY_SERIAL)
   SerialOpen(TELEMERY_SERIAL,TELEMERY_BAUD);
  #endif


And the attached Serial.ino file.
Attachments
MegaSerial.zip
Telemetry on Serial3
(4.69 KiB) Downloaded 323 times

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: New Multiwii Serial Protocol

Post by msev »

So this mod enables telemetry on serial 3 right? Are you going to send that data to yourself with bluetooth or what are you going to use it for?

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

msev wrote:So this mod enables telemetry on serial 3 right? Are you going to send that data to yourself with bluetooth or what are you going to use it for?


No, it is going to the onboard Arduino nano for ODS and for Antenna tracking.

viewtopic.php?f=6&t=1611

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: New Multiwii Serial Protocol

Post by Katch »

msev wrote:Sorry for the slight off-topic question, but on a MEGA board which has I think 3 serial ports, is it possible for using multiple at once,..

For example one for connecting an osd to the board, another for connecting and using a bluetooth board and the third for connecting the GPS for rth and position hold (gps would be shared between osd and multiwii).


This seems to have been overlooked. I'm also interested as I've started flying MEGAs and would like to make better use of its serial channels. Is this re-write going to enable xbee telemetry or at least the ability to pass serial communications off to a BT module on serial 2 or 3 (0 is standard and 1 is tied up with PPM SUM).

If this is not the intended functionality then I may start tinkering myself but I don't want to work something that is already being attended to.

With the now very functional and maturing GPS code I think telemetry is going to become more and more important as waypoint navigation becomes possible.

PS - very exciting time for MultiWii - my favourite and first choice for flying robots.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: New Multiwii Serial Protocol

Post by LuFa »

Hi , :)

i try to Controll the Mwii via the new Protocol .
i can read datas from multiwii without any proplems :) but i cant send anythink to Mwii .
Can anyone tell me how i have to calculate the Checksum for send datas to Mwii ?
i use a second arduino to do this , a example code will be also very nice :mrgreen:
Thanks !

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

you can grab the code from multiwii , look at serializeN() function


$M<[payloadlenght][mspId][payload][cheksum]

payloadlenght = payload / 8
cheksum = for (char c :payload){ checksum ^= int(c); }

ex : with mspId = MSP_SET_RC_TUNING the payload lenght is 7

here is java implementation that i use in myMultiWiiConf.pde, a liitle readable than the previous checksum calculation

Code: Select all

 // MSP_SET_RC_TUNING
      payload = new ArrayList<Character>();
      payload.add(char( round(confRC_RATE.value()*100)) );
      payload.add(char( round(confRC_EXPO.value()*100)) );
      payload.add(char( round(rollPitchRate.value()*100)) );
      payload.add(char( round(yawRate.value()*100)) );
      payload.add(char( round(dynamic_THR_PID.value()*100)) );
      payload.add(char( round(throttle_MID.value()*100)) );
      payload.add(char( round(throttle_EXPO.value()*100)) );
      requestMSP(MSP_SET_RC_TUNING,payload.toArray( new Character[payload.size()]) );


Code: Select all

//send with/without payload
void requestMSP(int msp, Character[] payload) {
  if(msp < 0) {
    return;
  }
  StringBuffer bf = new StringBuffer().append(MSP_HEADER);
 
  if (payload != null){
    bf.append(char(payload.length)).append(char(msp));
    byte checksum=0;
    for (char c :payload){
      bf.append(c);
      checksum ^= int(c);
    }
    bf.append(char(int(checksum)));
  }else{
    bf.append(char(msp));
  }

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Post by nicodh »

Hello,
May I make a request for adding MSP_INFO to the protocol?

What I need, is to be able to diferentiate the type of board (8bits or 32bits) and maybe the firmware release (at least the date of compilation for example).

For example create a variable like boardtype that would be 8 or 32 depending on the type of processor.
I know that change the revision number would be a pain, so instead you could add the compilation date, which is included by the compiler at build time.

This way it would be possible to show or hide features (like the command line interpreter for 32bits version) in my android development and my all in one windows configurator.

I would really appreciate this. Thanks.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

HI,
I commited a small change in the serial.ino, now it is able to process single commands. Perviously to finish a command processing it needed the first byte of the next command to come in.
EOSBandi

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

EOSBandi wrote:HI,
I commited a small change in the serial.ino, now it is able to process single commands. Perviously to finish a command processing it needed the first byte of the next command to come in.
EOSBandi


EOSandi, AWE! This makes sense and explains allot.

Thank you.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned :-)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned :-)


Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

Alexinparis wrote:
Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned :-)


Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.


Hi Alex,
Even it's not addressed to me, I have some ideas about the GUI, pid's and checkboxes. What i'm currently working on is to make the gui (wingui) parameterized. I think about a def file which can be fed into the gui and which defines the PID's and the checkboxes. So if you change the code on the FC (reorder PIDs, checkboxes, add new ones), you only have to change the parameter file. Currently it's something like this :

Code: Select all

<?xml version="1.0" encoding="us-ascii"?>
<!-- This a config file for RC options for latest dev MultiWii Code-->
<CONFIG>
   <AUX_OPTION id="0"  name="LEVEL"    desc="Auto Leveling mode" />
   <AUX_OPTION id="1"  name="ALTHOLD"  desc="Altitude hold" />
   <AUX_OPTION id="2"  name="MAG"      desc="Heading hold with compass" />
   <AUX_OPTION id="3"  name="CAMSTAB"  desc="Camera Stabilisation" />
   <AUX_OPTION id="4"  name="CAMTRIG"  desc="Camera Trigger" />
   <AUX_OPTION id="5"  name="ARM"      desc="Arm motors" />
   <AUX_OPTION id="6"  name="RTH"      desc="Return to home" />
   <AUX_OPTION id="7"  name="POSHOLD"  desc="Position hold" />
   <AUX_OPTION id="8"  name="PASSTHRU" desc="Passthru for flying wings" />
   <AUX_OPTION id="9"  name="HEADFREE" desc="Head free mode" />
   <AUX_OPTION id="10" name="BEEPER"   desc="Activate beeper" />
   <AUX_OPTION id="11" name="LEDMAX"   desc="Maximum illumination" />
   <AUX_OPTION id="12" name="LANDLIGHT"   desc="Landing Lights" />
   
   <PID id="0" name="Roll" desc="Roll Rate control" />
     <P id="0" shown="true" min="0" max="20.0" prec="10" />
     <I id="0" shown="true" min="0" max="0.250" prec="1000" />
     <D id="0" shown="true" min="0" max="100" prec="1" />

    <PID id="1" name="Pitch" desc="Pitch Rate control" />
     <P id="1" shown="true" min="0" max="20.0" prec="10" />
     <I id="1" shown="true" min="0" max="0.250" prec="1000" />
     <D id="1" shown="true" min="0" max="100" prec="1" />
   
   <PID id="2" name="Yaw" desc="Yaw Rate control" />
     <P id="2" shown="true" min="0" max="20.0" prec="10" />
     <I id="2" shown="true" min="0" max="0.250" prec="1000" />
     <D id="2" shown="true" min="0" max="100" prec="1" />
   
   <PID id="3" name="Altitude" desc="Altitude hold control" />
     <P id="3" shown="true" min="0" max="20.0" prec="10" />
     <I id="3" shown="true" min="0" max="0.250" prec="1000" />
     <D id="3" shown="true" min="0" max="100" prec="1" />
    
   <PID id="4" name="PosHold" desc="Position Hold control" />
     <P id="4" shown="true" min="0" max="2.54" prec="100" />
     <I id="4" shown="true" min="0" max="2.54" prec="100" />
     <D id="4" shown="false" min="0" max="100" prec="1" />
    
   <PID id="5" name="PosHoldRate" desc="Position Hold Rate control" />
     <P id="5" shown="true" min="0" max="20.0" prec="10" />
     <I id="5" shown="true" min="0" max="2.54" prec="100" />
     <D id="5" shown="true" min="0" max="0.254" prec="1000" />
    
   <PID id="6" name="Navigation Rate" desc="Navigation Rate control" />
     <P id="6" shown="true" min="0" max="20.0" prec="10" />
     <I id="6" shown="true" min="0" max="2.54" prec="100" />
     <D id="6" shown="true" min="0" max="0.254" prec="1000" />
    
   <PID id="7" name="Level" desc="Autolevel control" />
     <P id="7" shown="true" min="0" max="20.0" prec="10" />
     <I id="7" shown="true" min="0" max="2.54" prec="100" />
     <D id="7" shown="true" min="0" max="100" prec="1" />
    
   <PID id="8" name="Mag" desc="Heading hold control" />
     <P id="8" shown="true" min="0" max="20.0" prec="10" />
     <I id="8" shown="false" min="0" max="2.54" prec="100" />
     <D id="8" shown="false" min="0" max="100" prec="1" />

    <PID id="9" name="Velocity" desc="Velocity control for Altitude hold" />
     <P id="9" shown="true" min="0" max="20.0" prec="10" />
     <I id="9" shown="true" min="0" max="2.54" prec="100" />
     <D id="9" shown="true" min="0" max="100" prec="1" />
    
</CONFIG>


Adding these definitions to the FC code and make them queryable also could work but will definitely cost a huge amount of memory (no AtMega328 any more for sure).

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

Don't you dare leave the 328 out of this!
I will hunt you down and slap you silly if you do :p

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: New Multiwii Serial Protocol

Post by Katch »

with Mega boards appearing out of china for $70 complete with 10 DOF it's not a bad time for people to think about upgrading.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

Alexinparis wrote:
Tommie wrote:I just started to write a few small improvements to the serial protocol and state machine to straighten out a few shortcomings. Stay tuned :-)


Hi,
Could you explain basically the mod principles ?
Have you also some idea about the way to code a non aware checkbox index gui ? (with strings inside the sketch)
I see the last changes you made, and I think we will have to think about it if the number grows too much.


the gui can construct the gui base on what is found in the uploaded config.h
the gui can also construct all elements based on the recived msp messages

from my point of view : the difficult parts is changing how the params are stored and arranged in the eeprom and upgrading the serial code the efficient way ... the gui is the easy part

waiting for your technical design to adjust the gui

edit : we could also upload the firmware from the gui , that would ease the above technical proposal .
Last edited by kos on Thu Jun 07, 2012 9:41 pm, edited 2 times in total.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

With DIY, only limitation is one's imagination.

This is an ATmega1280 with a Nano on a project board to handle all of the house-keeping tasks. viewtopic.php?f=6&t=1611

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

I bought an all in one board with a 328p on it, if we lose that I have to buy a new controller and imu, or another all in one, that's not cheap.

I imagine there are a lot of people that couldn't afford the change.

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Post by nicodh »

Hi, well, after some mail discussion with tommie, I added the new checkboxes to my android app and at the same I manage to just show what is stored in the board. I mean, my app is basically designed for naze32 (multiwii 32bits port) so the latest tommie changes are not yet taken into account. So I decided to not show these 3 new checkboxes using the 3 byte from the serial code. It give me the number of checkbox items so I can erase the latest in case of diferent firmware.

For the upload firmware, I have a naze32 gui AIO that does exactly the same things as the android app, but for windows. It fetch the latest firmware from svn and update the board.

I can share my code of course, but it's visual basic, and it's not very clean.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

visual basic is not cross platform

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Post by nicodh »

Yes I know, but I couldn't code in anything else, sorry. I would love to do it in something more platform friendly but I know how to code in vb, so I code in vb.

If i was intelligent I would code it python or java, but I'm not. That's life.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

The idea is to decouple firmware changes from GUI changes. If new items are added, every GUI has to be adapted; this is clearly unacceptable. The copter should be able to tell how many switchable functions are available and what their names are;This is what I am working on, and during this process, I am straightening out and cleaning the state machine handling the serial communication. The number of switch items is (sadly) limited, and therefore it should be _easy_ to remove unneeded functions from ones firmware without breaking every GUI on the planet. I do not need PASSTHRU, other people do not own GPS devices, but perhaps want additional servos etc. This can only be achieved by making GUI and firmware independent from each other.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

I always thought it was possible to have the serial structure as an .ini or something similar and the GUI could read this file for the format of of the serial stream. Thereby not requiring a GUI update for each new Firmware release. Also this .ini file could be used by any third party creating OSD and other useful tools.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

Tommie wrote:The idea is to decouple firmware changes from GUI changes. If new items are added, every GUI has to be adapted; this is clearly unacceptable. The copter should be able to tell how many switchable functions are available and what their names are;This is what I am working on, and during this process, I am straightening out and cleaning the state machine handling the serial communication. The number of switch items is (sadly) limited, and therefore it should be _easy_ to remove unneeded functions from ones firmware without breaking every GUI on the planet. I do not need PASSTHRU, other people do not own GPS devices, but perhaps want additional servos etc. This can only be achieved by making GUI and firmware independent from each other.


Ok, there are two use cases :
First:
User sets in config which function is needed and which one is not, then not only the unneccessary code segments are removed but the checkboxes from the GUI also. From my point of view it's only a convinience function. Which helps declutter the GUI.

Second:
During development, spare the time and work spent for updating the GUI each time when a new checkitem or pid or other parameter is added.

We can add such functionality into the FC code itself, but if we consider all parameters (checkItems, Pid's, other params) there will be definitely a memory issue. So I still recommend to use an external ini file which can be parsed by the GUI.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Depending upon the available free memory in EEPROM, the Serial Stream data(Class) structure could be stored there and send to the GUI or other application upon boot up or request. The only problem I foresee is, it would be a two step flash process.

1. flash erase the EEPROM and write data structure.
2. Flash new firmware.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

EOSBandi wrote: During development, spare the time and work spent for updating the GUI each time when a new checkitem or pid or other parameter is added.

You are referring to GUI as if there were only a single one available; adding a new function to the copter firmware requires *all* GUIs to be updated, processing, android, swing etc.
Custom additions are made very difficult by this circumstance.
We can add such functionality into the FC code itself, but if we consider all parameters (checkItems, Pid's, other params) there will be definitely a memory issue. So I still recommend to use an external ini file which can be parsed by the GUI.

Some GUIs will be able to parse INI files, others won't. People having several copters probably do not want to juggle with multiple config files.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

I rewrote the state machine and generalized the protocol; I also added the names of the switchables to the copter firmware for testing purposes; here are my changes:
Firmware:
https://github.com/wertarbyte/multiwii- ... al_rewrite
GUI:
https://github.com/wertarbyte/multiwii- ... al_rewrite

Now every request has the following format:

$M<xyP*c

x: payload size
y: command type
P*: x bytes of arbitrary payload data
c: XOR checksum of {x,y,P*}

I abandoned requests without payload length specification to simplify the parser; it also allows the transfer of up to 255 bytes of data. I also included command type and payload size into the checksum to ensure a safer transmission.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

about decoupling GUI and firmware

I do understand the motives; dealing with a multilanguage (>=2) environment most often implies duplicate data, logic and other implementation details. It is error prone and feels 'unwanted'; the urge to avoid it almost always arises.
From past experience whichever way one decides on is a tradeoff between
- resource limitations ( strong influence for MWii)
- choice of environment, where the (single) master implementation goes into
- stretchability of the build environment (could do lots of code creation during the build )

Btw. it is/was good GUI practice to only grey out unused GUI items, _not_ hide them - look at the drop down menus of any serious program. It is about orientation. Think of people with more than one copter with different sensors & features.

Currently the discussion seems limited to the checkboxitems. I think if we strive for a real good solution, it should not stop here but include all GUI items (like various PIDs). At least all data that get stored in eeprom are likely candidates. Besides, for all of these the describing strings are present in the LCD code already.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

OK, I just finished the dynamic generation of the switch table in the GUI. Please check the links again I posted above and please test the code; it is working great on my copter, but I'd like a confirmation of that :-)

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

let me ask again:
what do you think does make the checkboxitems special in that exactly those get special treatment? See my post above.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

The checkbox stuff is the thing that I needed; feel free to add code for the other items as well.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

I checked compiled file sizes, due to the new serial code the resulting firmware is actually smaller than before, even when including the strings for aux labels.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:The checkbox stuff is the thing that I needed; feel free to add code for the other items as well.

sure, I've been following the later development. No need to tell me I can add code.

Question is: is this current approach suitable to be applied to _all_ parameters stored in eeprom or is it an isolated partial solution to an imminent problem you (like others before you) stumbled upon during a specific feature implementation.
I would much rather see the former, but I am not sure if resources are sufficient.

minor side effect
With your code, we now have about the same strings twice in the code, once for serial, once for lcd. not good. I guess that needs fixing before code goes productive.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:I checked compiled file sizes, due to the new serial code the resulting firmware is actually smaller than before, even when including the strings for aux labels.

:) good sales strategy; mixing two independent modifications' effects.
Care to guess how this will evolve when the strings-to-mwii-approach gets applied to all tunable parameters, that is everything stored in eeprom? To make it clear - I would like to see that, but I am not sure the resources are sufficient. That approach is pushing the memory burden to the weakest component - the tiny limited mcu.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

The question is: How many people will add new tunable parameters to the multiwii codebase? And how many will connect additional devices (camera, flashlight, rocket launcher) to their copter and want to control these additions via their TXs? I think it's far more desirable to add new component to the I²C bus, apply a patch to the firmware to access the new device and have new option appear magically in _every_ GUI, be it processing, android or whatever. It's not perfect solution, because ressources are limited, but it's whatn known in OSS circles as "scratching an itch".

The two modifications aren't completely independent as well; I did not want to rewrite the serial parser and protocol at first, but due to its completely pointless limitations (payload must be <100 Byte? Why?) and caveats (4th byte might be command type _or_ payload size? commnd not included in checksum? WTF?), I had to to facilitate my primary goal of adding the switch names.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:The question is: How many people will add new tunable parameters to the multiwii codebase? And how many will connect additional devices (camera, flashlight, rocket launcher) to their copter and want to control these additions via their TXs? I think it's far more desirable to add new component to the I²C bus, apply a patch to the firmware to access the new device and have new option appear magically in _every_ GUI, be it processing, android or whatever. It's not perfect solution, because ressources are limited, but it's whatn known in OSS circles as "scratching an itch".

neither you nor I know where the load of future additions will occcur. My guess would be tunable parameters for whatever comes. It will not be limited to additional checkboxitems.
I think we should strive for a solution that fits general purpose, that is solve the dilemma of tunable parameters for unknown GUIs. You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.
The two modifications aren't completely independent as well; I did not want to rewrite the serial parser and protocol at first, but due to its completely pointless limitations (payload must be <100 Byte? Why?) and caveats (4th byte might be command type _or_ payload size? commnd not included in checksum? WTF?), I had to to facilitate my primary goal of adding the switch names.

I cannot comment on either of the implementations, not my beef.

The latest r864 gives me a GUI without the copter graphics, sensor values get hardly updated if at all.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still and wait for the ATMega328p to magically grow an additional flash memory circuit?

Regarding the latest SVN release, did you update your GUI as well?

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:
You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still?

to answer in that tone of yours when you want to go to the moon climbing on a tree is your first step and your last
Did you update your GUI as well?

Yes, I can see the checkboxlabels.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.
Every path does not need to be the final one. Otherwise I will just lay down in my coffin now and cut out all that wasted time in between.

It's dev, for trying things. If it doesn't work it will get replaced or fixed when it comes to it, just like the serial code did.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

Hamburger wrote:
Tommie wrote:
You did a first step in that direction, but I find it incomplete and based on limited resources we probably cannot apply it to the entire realm of tunable parameters ('same itch'). That is why I do not like it.

So instead of taking a first step in the right direction, you are preferring to stand still?

to answer in that tone of yours when you want to go to the moon climbing on a tree is your first step and your last

But sitting in the tree (which is pretty fun, with or without gear, you should try it) I am nearer to the moon than someone standing on the ground, am I not? Both in terms of altitude and adventuresness.
Did you update your GUI as well?

Yes, I can see the checkboxlabels.

And since you cannot see the other stuff, you are probably not uing the latest version (which would be r865).

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.

the proverb is about going TO the moon, not getting CLOSER.
Every path does not need to be the final one

to that I agree.

For the time being I will stay away from current revisions and revert that copter back to an older version.

Cheers.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:And since you cannot see the other stuff, you are probably not uing the latest version (which would be r865).

my updating the tree produced r864, it is only two hours later you submitted r865 'fix checksum calculation'. I can see now you bumped revs up to 868.

Have fun

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

Hamburger wrote:
I had much fun climbing trees in my younger years, and yes it DID get me closer to the moon.

the proverb is about going TO the moon, not getting CLOSER.

Right. That's why Apollo 1 went straight for the moon. Boy, I remember Virgil Grissom being the first man on Earths natural satellite back in 1967; truly a day to remember.
For the time being I will stay away from current revisions and revert that copter back to an older version.

Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?


I do not always like spending time fiddling with non-working revisions. The fix you eventually provided came after I had already struggled with the code. Seems code is currently undergoing major conversion,so I am just staying away this time and leave all the fun to you.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

If you want a stable code release, and to not have to fiddle, staying with the stable release and not using 'dev' is probably a good idea.

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

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:Because getting a matching pair of firmware and GUI is totally impossible? You are whining about size issues, the new code is actually smaller than the old one. If you have eny technical reasons for staying with the old version, feel free to discuss. You might not like the new functionality, but in how far does it impact your use?

So long as you keep submitting non working sets of code I will stay away from the trunk, yes.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

It was a working set of code. The missing items in the GUI resulted from an issue regarding checksum calculation that only affected specific messages, not the core functionality - and only because someone thought re-introducing Strings into the serial communication of the Processing GUI (I removed them and explained in details why they were bad) was a good idea. Therefore, Java did calculate faulty checksums. It was a bug, something that happens during development.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

To get back to the technical issues at hand, I just shrunk the serial transmit and receive buffers; it's probably not a good idea to waste 256+256+128 Byte just for serial communication if your controller only offers 2kB; I encountered a few memory overflows today that did not only make the memory overflow, but the copter fly away as well since the entire TX/RX routines were nuked; I had to throw myself into its path before it had a chance to shred any furniture. I reduced the buffer sizes for everyone not using a serial GPS; I do not have one, so I cannot test it, but the GUI communication works flawlessly with rather small buffers:

https://github.com/wertarbyte/multiwii- ... e826452872
Last edited by Tommie on Fri Jun 08, 2012 8:32 pm, edited 1 time in total.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

Tommie wrote: someone thought re-introducing Strings into the serial communication of the Processing GUI

i think this is me .. ?

i do not beleive the issue is in the String, ... it is working with String in the two latest dev release ;)

http://code.google.com/p/multiwii/sourc ... iiConf.pde

this is what help , i use something equal ..

Code: Select all

    synchronized public static void decode(final byte input) {
        char c = (char) input;
                    checksum ^= c;
                inBuf[offset++] = (byte) (c);



edit : using String the way it was proposed is ok , the way you dot it now i ok .. the only point is not calling serial.write() for individual char in a for .. it will slow the gui too much

Post Reply