Rushduino OSD - Multiwii based open software osd

timecop · Post by **timecop** » Thu Feb 09, 2012 7:55 am

The code mostly is, and hardware has been working for months. So yes.

kataventos · Post by **kataventos** » Fri Feb 10, 2012 2:00 am

@Ziss_dm @ Dongs

Hi,

both of you are right and well informed but we all have to start on some point. I am not advocating Gab but he started here at this point using this tech and dedicating it to multiwii, of course that this project (Multiwii) fortunately never stop and always looking for something innovator. Of course that we all can just close the door to Multiwii and buy open pilot, but this is not the idea, I feel like I have this family to... (Multiwii Family... probably this gives a good bad song...

) the idea is defend and help each other showing new directions instead of killing what could in the future be more advanced than the future itself, everything is possible we just need to believe and work for it.

At this time I dont know if I believe or not in this project (Rushduino OSD) because of the V6. I am not using the Rushduino anymore because Gab say´s that dont have time for it... he is working on I2c GPS (I just have it mounted on my quad for a month). This is something that I did not expect! In the beginning I saw an urge that unfortunately seems to fade a little each day.

@ Gab :I just hope my new OSD is not obsolete in one month because of the software! I wish I could code to get it working for me and to the others with the same piece of hardware...

Cheers,
Henrique

JohnyGab · Post by **JohnyGab** » Fri Feb 10, 2012 4:34 am

I'm working on the OSD Kataventos

..and some time I also watch Tv......and talk a walk with my dog too. Its just hard to make a software based on another software that is always moving on.

GPS is a relatively new feature in the multiwii code ( supported since 20december 2011 ). But GPS is one of the most wanted feature...so there is a need to see those data on the screen. Problem is, multiwii have only one serial port when using the atmega328p, so having both a GPS and OSD on the same serial port due to the low level of the communication protocol between multiwii and PC or OSD. GPS have to be on another port, or on another interface( I2c this time ).

For all other, jumping in here and saying that my work is obsolete, go for you. Its easy to go somewhere, doing nothings to make things better and faster, and just telling, "this is crap", "this is useless", "you should have done this that way", "hey look here, he did far away better than you". But i'm doing things, i'm doing it so the average Joe is able to read my code and understand it and modify it. Your not interested, dont loose your time....and go do something else.

Thats my last post about that, and if that kind of discution continue here, i'll start my own forum, where i'll be able to delete unwanted talk that are useless for people who want to follow the project.

JohnyGab · Post by **JohnyGab** » Fri Feb 10, 2012 4:37 am

For those who tried V6 and are disapointed, when I uploaded the version, I wrote this into the description : "This is a not perfect release, but i'm formating my PC and...I need to save it at a safe place!" Please, understand that i'll do all I can to make the next rev better

JohnyGab · Post by **JohnyGab** » Sat Feb 11, 2012 3:55 am

For those who are waiting, tonight I tested V6 and I need to agree, its hard to make it work.

I just reused V5, and started there.

Now, I'm Trying to only use the 'M' command, like the GUI is doing. so there will be NO code to add to multiwii code.

every new multiwii version will generate a new section in the OSD file, that will be made to match multiwii M command.

Trying to get that working nice this week end

kataventos · Post by **kataventos** » Sat Feb 11, 2012 4:22 am

Great, you know... I have already thought about that but... who am I to speak about coding, I thought it was a stupid idea!

V5 works great with 1.9 the problem is that dont have the new "solved" bugs, RC exp and rate, the baro mag and autolevel signs and the new armed / not armed motors, GPS support (home arrow) etc... I have a friend that is a good coder and I am going to ask him if he want to give some help and fresh ideas, he is a little busy but we never know... even with the new graphic chip stm32, Rushduino will give a jump one of this days and I will ride with it on a new hardware, but for now let´s just use it as it is, I can buy another but I like this one... working :mrgreen:

! Good luck with that this weekend!

Cheers,
Henrique

JohnyGab · Post by **JohnyGab** » Sat Feb 11, 2012 7:22 pm

Kataventos, you have to understand something.

Rushduino OSD is using a Atmega328P processor that talk with a Max7456 video incrustator, problem is that the Max7456 cost around 16$US each and ATMEGA328P is about 5$US. The atmega328P is a 8bits processor that run at 16mhz.

When people talk about STM32 that can draw better graphic,....STM32 is not a video incrustator, its a really more powerfull 32bits processor, that can run at 72mhz. and its lot cheaper because, the STM32 is powerfull enought to generate is own graphic on the screen.

Problem is, its not as easy as with Arduino ( in fact, STM32 does not work with arduino at all ), it does required another software than Arudino, and its not easy to program like the Arduino project. Arduino is a much greater choice because of all the documentation available online.

Anyway, i'm using Atmega328P + Max7456 because its easier for everybody.

kataventos · Post by **kataventos** » Sun Feb 12, 2012 12:44 am

Hi Gab,

everything explicit now! I´m sure that it is not just one man working on the STM32 code and to make it communicate with the FC. At this time I let´s just explore to the last byte this setup with our eyes on a most advanced situation and on a way to link what we have with what we want to have in a near future

.

I did not have the chance to talk with my coder friend, but I wil next week.

How is V6 at this time?
I´m using 1.9 again because I need the OSD, just using the AH, BATvoltage, RSSI and flight time, but I must say that the few info is realy stable and reliable, the most important after PID tunning etc, is that I can realy see what IMU feels, so I can say that if anyone have a need for a a stable OSD with most wanted info on a multiwii setup, at this time this is the one. :mrgreen:

Cheers,
Henrique

JohnyGab · Post by **JohnyGab** » Mon Feb 13, 2012 5:07 am

Got it to work well with the M command of MultiWii_dev_20120203
I hope i'll make it reliable, so i'll let it work on my bench for the next 8h, see how many error i have

Then i'll start re-adding some function.

Alexinparis · Post by **Alexinparis** » Mon Feb 13, 2012 1:49 pm

Hi Gab,

If you relly want something which is version independent, we can still define a new command like the 'O'.
But it would become quite obsolete sooner or latter, because of new functionalities.

I'm agree with your point of view about Rushduino and the hardware it uses.
It' maybe not the up-to-date techno choice, but the arduino environment is THE argument. It's a must to allow users to customize it without big computing background. Who really need to graph other things than text info ?
Things could change rapidly with cheap 32 bit processors, but to my mind there is nothing better than arduino regarding user knowledge reachability.
For a closed source project, choices would have been different for sure.
Please don't loose your motivation

JohnyGab · Post by **JohnyGab** » Mon Feb 13, 2012 2:02 pm

Thanks for you support Alex !

By the way Alex, I think i'll need help.

After serval hour, my program as detected serval communication problem using the 'M' command,.....because the 'M' command is long, its like if we are not both working at 115200.
Sometime, When asking M, I receive 106 Bytes, other time, 107 bytes.

Its strange. When I was working with the 'O' command, its 100% reliable, no glitch, but with the 'M', its about 30% error, because the string is too long?

Code: Select all

void SerialRx()
{
  if(Serial.available()>0)
  {
  char xx;
  xx = (char)Serial.read();
  
  if((xx=='M')&&(!SerialMReceiving)) {SerialMReceiving=1;SerialMStringOK=0;}
  
  SerialBuffer[ReceiverIndex++]=xx;
  
  if((xx=='M')&&(SerialMReceiving)) {SerialMReceiving=0;SerialMStringOK=1;ReceiverIndex=0;if(SerialDrop==-1)SerialDrop=0;}
  
  }
  // Discard data if expected software version does not match current 
  if(SerialBuffer[0]!=ExpectedVersion){ SerialMReceiving=0;SerialMStringOK=0;ReceiverIndex=0;if(SerialDrop>=0)SerialDrop++;}
  
  if(SerialMStringOK) SerialMCheck();
}

and this to analyse the string, only when SerialMString is true

Code: Select all

#if defined(MultiWii_dev_20120203)
        //read8();
        MwVersion = read8();   
        for(i=0;i<3;i++) MwAccSmooth[i] = read16(); 
        for(i=0;i<3;i++) MwGyroSmooth[i] = read16();
        for(i=0;i<3;i++) read16();  // this dump 3 Mag data
        MwAltitude = read16()/1000; 
        MwHeading = read16(); 
        for(i=0;i<8;i++) read16();  // dumping servo data
        for(i=0;i<8;i++) MwMotor[i] = read16();
        for(i=0;i<8;i++) MwRcData[i] = read16();
        MwSensorPresent = read8();
        MwSensorActive = read8();
        read16(); // dump cycle time
        for(i=0;i<2;i++) MwAngle[i] = read16(); 
        read8(); // dump multitype
        for(i=0;i<8;i++) {P8[i]=read8();I8[i]=read8();D8[i]=read8();}
        rcRate8 = read8(); 
        rcExpo8 = read8();
        rollPitchRate = read8();
        yawRate = read8(); //22
        dynThrPID = read8(); //23
        for(i=0;i<11;i++) read8();  //dump check box data      
        read16();  // distance to home
        read16();  // direction to home
        read8();  // number of sat
        read8();  // gps fix
        read8();  // gps update
        read16();  // power meter sum
        read16();  // power trigger
        read8();  // vbat
        read16();  // debug1
        read16();  // debug2
        read16();  // debug3
        read16();  // debug 4
        read8(); // dump the 'M'        
      #endif
      SerialMStringOK=0;

kataventos · Post by **kataventos** » Mon Feb 13, 2012 9:37 pm

Hi Gab,

found a new bug on v5. If I try to trim the ACC (full trhotle), in my case I wanted to give some pitch trimming and it enter on the menu for PID adjustment, page1!

Cheers,
Henrique

JohnyGab · Post by **JohnyGab** » Tue Feb 14, 2012 4:59 am

Noted, allow config menu only when Throttle is at Throttle min

Alexinparis · Post by **Alexinparis** » Tue Feb 14, 2012 6:00 pm

Hi,

I think the problem comes from this function:

Code: Select all

Serial.read()

Generally speaking, when you want to read a char, you need to be sure a char is available.
Otherwise you will get rubish data (Serial.read() won't wait for a char, but instead will return nothing usefull is the buffer is empty)

=> just tune if(Serial.available()>0) with the right number instead of 0

JohnyGab wrote:Thanks for you support Alex !

By the way Alex, I think i'll need help.

After serval hour, my program as detected serval communication problem using the 'M' command,.....because the 'M' command is long, its like if we are not both working at 115200.
Sometime, When asking M, I receive 106 Bytes, other time, 107 bytes.

Its strange. When I was working with the 'O' command, its 100% reliable, no glitch, but with the 'M', its about 30% error, because the string is too long?

Code: Select all

void SerialRx()
{
  if(Serial.available()>0)
  {
  char xx;
  xx = (char)Serial.read();
  
  if((xx=='M')&&(!SerialMReceiving)) {SerialMReceiving=1;SerialMStringOK=0;}
  
  SerialBuffer[ReceiverIndex++]=xx;
  
  if((xx=='M')&&(SerialMReceiving)) {SerialMReceiving=0;SerialMStringOK=1;ReceiverIndex=0;if(SerialDrop==-1)SerialDrop=0;}
  
  }
  // Discard data if expected software version does not match current 
  if(SerialBuffer[0]!=ExpectedVersion){ SerialMReceiving=0;SerialMStringOK=0;ReceiverIndex=0;if(SerialDrop>=0)SerialDrop++;}
  
  if(SerialMStringOK) SerialMCheck();
}

and this to analyse the string, only when SerialMString is true

Code: Select all

#if defined(MultiWii_dev_20120203)
        //read8();
        MwVersion = read8();   
        for(i=0;i<3;i++) MwAccSmooth[i] = read16(); 
        for(i=0;i<3;i++) MwGyroSmooth[i] = read16();
        for(i=0;i<3;i++) read16();  // this dump 3 Mag data
        MwAltitude = read16()/1000; 
        MwHeading = read16(); 
        for(i=0;i<8;i++) read16();  // dumping servo data
        for(i=0;i<8;i++) MwMotor[i] = read16();
        for(i=0;i<8;i++) MwRcData[i] = read16();
        MwSensorPresent = read8();
        MwSensorActive = read8();
        read16(); // dump cycle time
        for(i=0;i<2;i++) MwAngle[i] = read16(); 
        read8(); // dump multitype
        for(i=0;i<8;i++) {P8[i]=read8();I8[i]=read8();D8[i]=read8();}
        rcRate8 = read8(); 
        rcExpo8 = read8();
        rollPitchRate = read8();
        yawRate = read8(); //22
        dynThrPID = read8(); //23
        for(i=0;i<11;i++) read8();  //dump check box data      
        read16();  // distance to home
        read16();  // direction to home
        read8();  // number of sat
        read8();  // gps fix
        read8();  // gps update
        read16();  // power meter sum
        read16();  // power trigger
        read8();  // vbat
        read16();  // debug1
        read16();  // debug2
        read16();  // debug3
        read16();  // debug 4
        read8(); // dump the 'M'        
      #endif
      SerialMStringOK=0;

Hamburger · Post by **Hamburger** » Tue Feb 14, 2012 6:30 pm

please be aware the M-command corresponds to the most frequently changing set of data, practically with almost every new feature.
Even if your s/w does not need the extra data (most often appended or existing chunks like checkboxitems enlarged), the total amount of bytes per sequence is not a constant.

Bledi · Post by **Bledi** » Tue Feb 14, 2012 7:00 pm

you are true Hamburger but so what is the best solution ? :
- Add special message in the Multiwii code for the OSD (it is the old solution)
- Using the "normal" M message and do not need modifications in the Multiwii code ?

Is the best solution is not to describe the M message in a .h and use it on the 3 codes (Multiwii, Multiwiiconf and Rushduino or other OSD) ?

JohnyGab · Post by **JohnyGab** » Wed Feb 15, 2012 1:40 am

Ok well. look like its a non-concessus subject.

Anyway, both way will work, and I say, because the most important things is to focus on getting functionality and because its not hard to add 3 sections in the serial file of the multiwii by the end user ( as manipulation of multiwii code is Always required ), lets keep going with O, Y and Z, so OSD will be multiwii version independent.

Because V6 was only a backup of my PC, ( like I said on google code repository ), lets make it work the way it should.

JohnyGab · Post by **JohnyGab** » Wed Feb 15, 2012 3:28 am

I just found the problem that all of you had with V6

I modified the O section so it have more data in it

Code: Select all

    case 'O':  // OSD to arduino data - contribution from JohnyGab (rushduino.com)
      serialize8('O');
      for(i=0;i<3;i++) serialize16(accSmooth[i]);
      for(i=0;i<3;i++) serialize16(gyroData[i]);
      serialize16(EstAlt*10.0f);
      serialize16(heading); // compass - 16 bytes
      for(i=0;i<2;i++) serialize16(angle[i]); //20
      for(i=0;i<6;i++) serialize16(motor[i]); //32
      for(i=0;i<6;i++) {serialize16(rcData[i]);} //44
      serialize8(nunchuk|ACC<<1|BARO<<2|MAG<<3);
      serialize8(accMode|baroMode<<1|magMode<<2);
      serialize8(vbat);     // Vbatt 47
      serialize8(VERSION);  // MultiWii Firmware version    
      serialize8(armed);
[b]      serialize16(GPS_distanceToHome);
      serialize16(GPS_directionToHome);
      serialize16(GPS_numSat);
      serialize8(GPS_fix);
      serialize8(GPS_update);   [/b]    
      serialize8('O'); //49
      UartSendData();
      break;

But all the bold section was not present in the described modification to add to the multiwii code

JohnyGab · Post by **JohnyGab** » Wed Feb 15, 2012 3:57 am

I have to say, there is some bug in the current V6 in the menu, but i'm remaking it another way so modification to match multiwii will be easy

JohnyGab · Post by **JohnyGab** » Wed Feb 15, 2012 5:09 am

Its 23h08 here, i'm sleeping

But V7 is out, and a lot better

take a look http://code.google.com/p/rushduino-osd/ ... akechanges

and DONT forget to modify your multiwii code with this :

Code: Select all

      case 'Y':  // RUSHDUINO OSD TO Arduino - contribution from JohnyGab (rushduino.com)
      serialize8('Y');
      for(i=0;i<8;i++) 
      {
        serialize8(P8[i]);
        serialize8(I8[i]);
        serialize8(D8[i]);
      }
      serialize8(rcRate8);
      serialize8(rcExpo8);
      serialize8(rollPitchRate);
      serialize8(yawRate);
      serialize8(dynThrPID);
      serialize8('Y');
      UartSendData();
      break;

      case 'Z':  // arduino to OSD data - contribution from JohnyGab (rushduino.com)
      while (SerialAvailable(0)<30) {}
      for(i=0;i<8;i++) 
      {
        P8[i]=SerialRead(0);
        I8[i]=SerialRead(0);
        D8[i]=SerialRead(0);
      }
      rcRate8 = SerialRead(0);
      rcExpo8 = SerialRead(0); //20
      rollPitchRate = SerialRead(0);
      yawRate = SerialRead(0); //22
      dynThrPID = SerialRead(0); //23
      writeParams();
      break;
    case 'O':  // OSD to arduino data - contribution from JohnyGab (rushduino.com)
      serialize8('O');
      for(i=0;i<3;i++) serialize16(accSmooth[i]);
      for(i=0;i<3;i++) serialize16(gyroData[i]);
      serialize16(EstAlt*10.0f);
      serialize16(heading); // compass - 16 bytes
      for(i=0;i<2;i++) serialize16(angle[i]); //20
      for(i=0;i<6;i++) serialize16(motor[i]); //32
      for(i=0;i<6;i++) {serialize16(rcData[i]);} //44
      serialize8(nunchuk|ACC<<1|BARO<<2|MAG<<3);
      serialize8(accMode|baroMode<<1|magMode<<2);
      serialize8(vbat);     // Vbatt 47
      serialize8(VERSION);  // MultiWii Firmware version    
      serialize8(armed);
      serialize16(GPS_distanceToHome);
      serialize16(GPS_directionToHome);
      serialize16(GPS_numSat);
      serialize8(GPS_fix);
      serialize8(GPS_update);       
      serialize8('O'); //49
      UartSendData();
      break;

JohnyGab · Post by **JohnyGab** » Wed Feb 15, 2012 12:20 pm

Just had 7.5h of communication between OSD and multiwii with 0 problem!

Bledi · Post by **Bledi** » Wed Feb 15, 2012 1:16 pm

you are a Boss !

kataventos · Post by **kataventos** » Thu Feb 16, 2012 3:32 am

Great Gab, you´re the Boss like Bledi says

I will fly and report ASAP!

Cheers,
Henrique

JohnyGab · Post by **JohnyGab** » Thu Feb 16, 2012 4:20 am

It will be nice if tou can post a video!

I hope there is not as much bug as with V6
You will notice that
- you cant go into config while motor armed
- you cant go into menu if throttle is too high , so no false menu activation if you trimming the acc
- Armed warning is there
- Pid parameter are there and should all work well

Next thing i'll make will be
-altitude based on barometric sensor
-assension meter ( climbing rate indicator )
-Acc calibration activated by the osd
-Current monitor
-batery remaning power with adjustable capacity
-adjustable voltage warning

kataventos · Post by **kataventos** » Fri Feb 17, 2012 5:04 pm

Hi Gab,

I only had the chance to bench test it and it works almost great!

I say this because everything works just fine as expected, until I try to trim my ACC... it´s like the V5 on 1.9 like I reported before.

As for your Ideas

no words!

Cheers,
Henrique

PS: I will try to make the video this weekend, I have to get my hands on a SD Card stand alone recorder to capture everything I see on my googles (I just record on the GO Pro), and I dont know were to get it in such a short time but I will try, posting a good video is something that I need to do, it´s like a big thanks for your work and persistence!

JohnyGab · Post by **JohnyGab** » Sat Feb 18, 2012 1:38 am

Lol, is a combinasion of factor that is the problem.....and thats why V8 to go nto menu will be Mid throttle, yaw right and Full pitch

Anyway v8 will have so much more. ......

kataventos · Post by **kataventos** » Sat Feb 18, 2012 2:48 am

Hi Gab,

Fast bench test on RushduinoV7, Multiwii dedicated OSD. The screen on config is narrow and seems out of place (to much to the right), in fact, this is not what you see, but to make this video I use a 14€ EasyCap (get it today) to try to use it on the field with my PC. I use a GoPro and usualy in PAL mode, but because of this (not) excelent video Capture device

I just could get everything on screen in NTSC and I repeat, this is not what I see on my googles, everything is well displaced (time and voltage on the screen borders top and bottom Etc...) I use WIDE view on OSD config. Anyway, with this video everyone can get the Idea that it works great.

http://www.youtube.com/watch?v=8b3XXbMe ... e=youtu.be

Cheers,
Henrique

copterrichie · Post by **copterrichie** » Sat Feb 18, 2012 6:54 pm

Johnny, I am curious, will this GLB ODS (Copy) work with your firmware? It uses a MAX7456 also.

http://www.goodluckbuy.com/minimosd-ard ... tocol.html

JohnyGab · Post by **JohnyGab** » Sat Feb 18, 2012 10:14 pm

Yes and no
Its the same processor, same video driver, so it will display something. But, you sill need to modify hardware to have voltage/rsssi/current mesurement. Also some code modification sill be required to make spi communication between max7456 and atmega328p

So, directly no, but if you ask me "johny, with that hardware ...are you able to make it work" i'll have to say yes. But, shy dont you want to encourage me by buying mine ?

JohnyGab · Post by **JohnyGab** » Tue Feb 21, 2012 4:31 am

Just to let you know guys, I'm still working on V8, it will worth the wait!

copterrichie · Post by **copterrichie** » Tue Feb 21, 2012 4:47 am

I have no intention of buying one of them, I was just curious. Seems many of the designs lately have ended up being copied etc.

JohnyGab · Post by **JohnyGab** » Tue Feb 21, 2012 5:15 am

If the OSD became popular enough, it will be copied. Be before that appen, the only things i'm selling its an easy way to get an OSD on your multiwii

JohnyGab · Post by **JohnyGab** » Tue Feb 21, 2012 2:46 pm

JohnyGab wrote:
Next thing i'll make will be
-altitude based on barometric sensor -Display coded, but will be improved for V9
-assension meter ( climbing rate indicator ) -Display coded, but will be improved for V9
-Acc calibration activated by the osd -Done
-Current monitor -Done, but not tested with real current sensor
-batery remaning power with adjustable capacity -Display coded, but will be improved for V9
-adjustable voltage warning

-Done

+ did This
-Heading shown in degree
-Heading shown into a little graph
-Display Flight Time
-Display On Time
-New Voltage logo
-New Rssi logo
-New logo for sensors presence
-Better and more intuitive way to show wich sensor is used
-Flying mode display ( stable or acro, GPStohome,GpsHold logos )
-Better management of PAL vs NTSC
-Code clarification and better variable position in code
-Easier way to adjust what to display where for the average guy
-Multiwii logo splash screen
-New Max7456 file

I have to give credit to FlyFlow for this post and his files ( viewtopic.php?f=7&t=1121 )
and to Bledi to helping me to adapt the MAX7456 file.

but, I still need to do some test before I release this version.

kataventos · Post by **kataventos** » Tue Feb 21, 2012 9:50 pm

Hi Gab,

Good job! :idea:

Can you make the timer start just when the motors are armed? I think that this shows a real flight time.

Cheers,
Henrique

Bledi · Post by **Bledi** » Tue Feb 21, 2012 11:15 pm

It is ...

JohnyGab · Post by **JohnyGab** » Wed Feb 22, 2012 1:58 am

kataventos wrote:Hi Gab,

Good job! Can you make the timer start just when the motors are armed? I think that this shows a real flight time.

Cheers,
Henrique

There will be 2 timer, one for the timer since powered, on that count flight time

JohnyGab · Post by **JohnyGab** » Fri Feb 24, 2012 4:57 am

test flight tonight!

almost ok for release

http://vimeo.com/37355008

dramida · Post by **dramida** » Tue Mar 06, 2012 11:57 am

Looking verry promising this Multiwii osd.
I want to wire this osd on a breadboard, where can i find the schematic?
Why you named this OSD as a Arduino project if you not release the schematic? If is based on Arduino, it should have an open licence.
Hiding the schematic will make your project evolve slower because few people can afford to risk buying an evolving product but are many who would build it by themself as a project and participate in testing and improving. After this stage, they will be your customers, not willing to fly with a bunch of DiY wires.
Also Remzibi made his hardware public, there are few people who built it by themself ( i don't know anyone actually). And being cloned by Chinese is a recognition of your eventual success Also "they" don't need your explicit schematic. For a "trained eye" the pictures you posted and open software are enough to reverse-engineer your work. Not speaking about the case of owning a such OSD.
/Mihai

timecop · Post by **timecop** » Tue Mar 06, 2012 12:49 pm

Has this actually added anything that remzibi osd didn't have already?
Anyway I bought Cyclops osd and even that uses stm32, so much better hardware is readily available yet people keep rehashing same ol' shiet.

shikra · Post by **shikra** » Tue Mar 06, 2012 12:58 pm

Johhny - love the OSD development.
A couple of suggestions for consideration;

1 Throttle setting. A vertical bar indicating the throttle position I could see of having some value. Especially up high - help guage better climb / descent rate. usefull if not having GPS onboard
2 Next to altitude - "^" or "v" to show if climbing/descending
2 Pseudo current sensor - map throttle setting to current draw. Used accumulated run time* throttlle setting/divisor to give indication of how much battery is used / remaining - without use of current sensor.

shikra · Post by **shikra** » Tue Mar 06, 2012 1:07 pm

It's good old shiet though!!

At its base it is like many other good OSD's. Nice to have one being developed for Multiwii. one extra...
On screen config......

Cyclops - Nice OSD, great processor, but IR sensors instead of IMU - WTF??? I don't get it.
I guess that's not an issue on a multi, but seem like not a good match.

dongs wrote:Has this actually added anything that remzibi osd didn't have already?
Anyway I bought Cyclops osd and even that uses stm32, so much better hardware is readily available yet people keep rehashing same ol' shiet.

JohnyGab · Post by **JohnyGab** » Tue Mar 06, 2012 2:32 pm

Just want to say, new code soon, problem is that outside here, its kind of crazy ( freezing -20 Deg C,.....or rain ??WTF??, or...freaking wind at 60mph ). Want to try again if everything look ok.

Shikra, you are the second person who ask me for a throttle indicator...I guest I have to make it now

Pseudo current sensor is a nice idea, but i'm not sure how can it be reliable....better a real current sensor (

)

shikra · Post by **shikra** » Tue Mar 06, 2012 3:22 pm

Batt volts is my number one. Everything else is nice to have
I would probably use the current one more. I like the pseudo current idea - no sensor needed = less weight / wiring complexity. I think it could be accurate enough to use as a "fuel gauge"

.
I think it would be good enough accuracy. And probably quite easy to implement

Bledi · Post by **Bledi** » Tue Mar 06, 2012 3:33 pm

The solution is to use the soft power meter of the multiwii no ?

shikra · Post by **shikra** » Tue Mar 06, 2012 6:19 pm

LOl - never used that, but yes I forgot - most work is done

kataventos · Post by **kataventos** » Tue Mar 06, 2012 6:39 pm

Bledi wrote:The solution is to use the soft power meter of the multiwii no ?

+1

Hamburger · Post by **Hamburger** » Tue Mar 06, 2012 7:46 pm

shikra wrote:2 Pseudo current sensor - map throttle setting to current draw. Used accumulated run time* throttlle setting/divisor to give indication of how much battery is used / remaining - without use of current sensor.

do not do that, it will be useless. Use the output from MultiWii for POWERMETER_HARD or _SOFT instead.

dramida · Post by **dramida** » Wed Mar 07, 2012 1:20 am

schematics please.... It's arduino based and i want to test it.

JohnyGab · Post by **JohnyGab** » Wed Mar 07, 2012 1:34 am

Hamburger wrote:
shikra wrote:2 Pseudo current sensor - map throttle setting to current draw. Used accumulated run time* throttlle setting/divisor to give indication of how much battery is used / remaining - without use of current sensor.

do not do that, it will be useless. Use the output from MultiWii for POWERMETER_HARD or _SOFT instead.

I clearly dont understand how power meter work, but i'm willing to try to integrate it too into the osd, i will take a look at that.

timecop · Post by **timecop** » Wed Mar 07, 2012 2:41 am

dramida wrote:schematics please.... It's arduino based and i want to test it.

geez how much schematics do you want.
its just max7455 or whatever + standard tarduino pinout.
hint: max chip goes to SPI