Comment by Michael Pursifull on November 19, 2011 at 4:59pm

Why the interest in using a joystick? You have essentially reduced what is a fairly well designed solution using at least four channels, and two sticks to handle all three axis and power, down to a two or three channels, with a stick and a lever. What benefits are you seeking by reducing your controls and increasing (significantly) the potential points of failure (usb drivers, joystick drivers, operating system latency, APM Mission Planner event loops, event encoding and messaging, FTDI drivers, Xbee radio buffers, MAVlink encoding/decoding, adding significantly more MAVlink commands to an already saturated link, etc)

 

I am not dismissing your goal, you may have many thoughts about the benefits, or it might be "just because", and I am curious about these ideas.

Comment by Ellison Chan on November 19, 2011 at 5:02pm

I don't know about Farooq, but the reason why I wanted to used wireless instead of the RC was because, I thought it would be good redundancy to have both and the range of the APC220 is supposed to be 2KM, so theoretically longer than my Turniqy 9x.

Comment by Michael Pursifull on November 19, 2011 at 5:04pm

@Ellison - no, you will not catch me saying that, I don't think that is fair to say at all. It can certainly be flown w/ a joystick. Windows OS performance, any AV or other programs running, these can have a very big effect on latency (and watch out for forced patch reboots! You don't want to be flying by joystick when windows insists that you will reboot now, and you miss the "delay by 10 minutes" button! Been there, thankfully I did not actually need Mission Planner during that flight. I was not looking at the screen, I was looking at the ArduCopter at the time, and I saw the screen just a second before it rebooted.)

 

 

Comment by Michael Pursifull on November 19, 2011 at 5:05pm

In this case, I do not think that the performance/latency is because of a saturated link, most of it is most likely from windows... the trouble is it can take a lot of maintenance to try to ensure that windows is running well, for each flight to reduce this latency ... and even then there are no guarantees. 

Comment by Michael Pursifull on November 19, 2011 at 5:10pm

If you have done a lot of video editing on windows, you will know what I mean. A lot of windows commercial video editing software (not always written to deal with real time very well) suffers badly with OS latency. You often see issues such as the audio track and video becoming badly matched, for example. Keeping the disk defraged is very important in such cases, making sure you don't have greedy processes, turning your AV program so it is not performing deep inspection on your streaming data, watching out for path reboots and guarding against DLL conflicts, viruses, spyware, keeping snapshots (ideally).... 

Comment by Ellison Chan on November 19, 2011 at 5:11pm

No, I don't buy it.  I play games on windows all the time, using directX, and directInput should be no problem with getting real time data from a joystick.  It may be the way that MP is getting data from the joystick.  Would be nice to see that code, I might be able to help optimize it.  If it's not using directInput, that could explain it.  MP is not polling the joystick input manually, I hope.

Comment by Michael Pursifull on November 19, 2011 at 5:12pm

@Ellison - redundancy, to me, does not mean mixing all controls into the same wireless link ;) but I understand what (I think) you mean, having the option to use RC & joystick at the same time. 

Comment by Ellison Chan on November 19, 2011 at 5:14pm

I ran mine on a clean install of Windows with Dual Core, Nvidia Hardware accelerated laptop with 4gb of memory, using XP, not Vista or Windows 7.  I'm pretty sure it's mission planner that's not using an optimised method of getting joystick input.  I did notice that my computer became very slow once I enabled the joystick interface.

Comment by Michael Pursifull on November 19, 2011 at 5:21pm

You don't have to buy it, of course. But games do a lot of tricks to keep the impact of latency down, it is a very complex art, especially for online gaming, very interesting stuff. Even so, certainly there can be improvements, yes. 

 

But the serial nature of latency impact on these systems is different from locked turns, anticipated results, and simultaneous, contingent client and server deconfliction of out of sync timed events that address network latency in modern games. This is a real system, not one with complex timing locks, it might get far more complex on the APM side than a simple micro controller like APM can handle well, to perform some of the techniques used by online games to address latency.

 

That being said, I'm sure it could be improved, by adding priority queuing in MAVlink, ensuring you have a true duplex radio telemetry link, addressing any messaging or event handling performance issues within APM (Michael O, I'm not saying they exist) and finding other ways to limit the impact of other processes on the event handling involved in APMs joystick message handling.

Comment by Michael Pursifull on November 19, 2011 at 5:27pm

@Ellison - feel free to get out your debugger and do some performance analysis of Mission Planner. Not only would Michael Oborne not be offended (I'd wager) I'm going to guess that he'd welcome the help - and any performance benefits in Mission Planner would be welcomed by all. It is very easy for performance issues to creep into modern software projects like Mission Planner where for a small development team to achieve any progress you need to rely on a lot of system and third-party components (maps, GUI toolkits, third-party communication libraries, etc)

Comment

• ‹ Previous
• 1
• 2
• 3
• 4
• …
• 12
• Next ›
• Page