Comment by Phil Sammons on March 20, 2011 at 7:50am

Hey Happy,

Is there a way to remove the APM from the Hardware in the loop simulation such that the GCS controls Flightgear instead of the APM autopilot?

Cheers
Phil

Comment by Peter Seddon on March 20, 2011 at 8:02am

I think this has been asked before - my apologies.

Will the map work without being connected to the internet when you are flying?

Peter

Comment by Paul Mather on March 20, 2011 at 10:08am

Phil, what would be the point? A ground control station controlling a 3D representation of a plane? That doesn't make sense. Who's the brains of the operation?

 

You can try my GPS emulator if you want. I don't know if Flightgear can take GPS inputs....it will also emulate ArduPilot legacy commands.

 

Peter, no, offline maps do not work.

Comment by Phil Sammons on March 20, 2011 at 4:15pm

The point would be to be able to develop and test the ground station and control side of things without having to plug in the APM.  In the same way that you can use a flight simulator to make it think it is in the air. the Idea is to take out the APM and make the ground control station think it is talking to the APM when it is actually talking to the flight simulator.

Assuming there is nothing like this available, can you point me in the direction of the communication to and from the APM. I'm guessing I'm going to have to make an intermediate middleware program...

Comment by Phil Sammons on March 20, 2011 at 4:19pm

and in case i missed your point about who's in control. I would be using the flight simulator 's autopilot and way-point stack. If there are things that i'm missing that APM does that the flight sim can't, then that would have to be done by a middleware program

Comment by Paul Mather on March 20, 2011 at 5:20pm

So what kind of output stream can the flight sim generate? Would it come out a serial port? A socket? UDP? TCP?

 

If you're just looking for a way to steer the plane you see on the GCS, my GPS Emulator will do that...Start, All Programs, HappyKillmore, GPS Emulator. You'll need to click the button to add the com0com drivers and create a feedback port (all this can be done in the emulator).

Comment by Andrus Kangro on March 24, 2011 at 11:14am

Hi Happykillmore, you are doing amazing job with your GCS, its such a nice software.

 

Let me point out one issue you might not be aware of. You wrote:

@Krzysztof, I will investigate today. There is currently an issue with ArduPilot Mega and UTC time. The MAVlink protocol requires a long integer since January of 1970...in milliseconds.  Which is actually an overflow for today's date. Doug Weibel is working with the guys from MAVlink on this issue and I'm hoping to have this sorted out shortly.

 

This is not correct. Mavlink protocol expects date not in milliseconds, but microseconds (and is using long long data format). Look at http://pixhawk.ethz.ch/wiki/mavlink/ , every time or timestamp has format:

usec

uint64_t

Timestamp (microseconds since unix epoch)

 

I would not mind using milliseconds (my uav's timer ticks milliseconds anyway), but I'm worried about incompatibility with protocol.

Comment by Paul Mather on March 24, 2011 at 1:43pm

Andrus, my statement was not correct. We figured out what needs to be done and Doug has plans to implement it, but hasn't yet. The PIXHAWK guys added message #4 for us, but that doesn't solve the problem completely. I believe NMEA, SiRF and MediaTek all use a UTC time/date. uBlox is the only one (or maybe SiRF does too) that uses a number since an epoch... so the trouble becomes that Doug has to convert it one way or the other....everything to UTC or everything to epoch. What he's going to do is convert the first valid message from the GPS using his routine (it will be slow) and then simply add on the time that has passed since that conversion. So I think he's going to be using message #2 (SYSTEM_TIME) when he does it. And yes, it will be microseconds.

Comment

• ‹ Previous
• 1
• …
• 3
• 4
• 5
• Next ›
• Page