SITL JSON Interface not working?

ArduCopter Copter 4.0
1

Hi,

I am trying to get the JSON interface for SITL working with a custom physics end. Right now I am trying to match sure the data exchange between sim and arducopter is correct. I am not using a custom physics end yet, I have a temporary interface to mimic this (sending constant data). I have followed the instructions at:

So far, I can receive the data coming from ArduCopter:

  uint16 magic = 18458
  uint16 frame_rate
  uint32 frame_count
  uint16 pwm[16]

I can also seen that as soon as I send the sim data as a JSON to the ArduCopter, for example:

{"timestamp":2500,"imu":{"gyro":[0,0,0],"accel_body":[0,0,0]},"position":[0,0,0],"attitude":[0,0,0],"velocity":[0,0,0]}

MAVProxy shows SITL starting up correctly as you would expect. I can also confirm that The physics data I am sending to ArduCopter are making through to the autopilot correctly because I can log these received values on the autopilot side to /tmp/ArduCopter.log and confirm the values I send and that JSON is received. Additionally, through Mission Planner I can see the same values showing up in the MAVLink Inspector under SimState. So far so good.

The problem is that:

  • if I send attitude = 0,0,0 (roll, pitch, yaw)
    Mission Planner shows a non-zero attitude that makes no sense. The non-zero attitude can also be seen in the MAVLink inspector under ATTITUDE. Why do these not match? It is as if it is ignoring the attitude being sent from the simulator or the EKF was doing something that I am unaware of. What am I doing wrong? Right now I am sending all zero for everything (not just attitude) so i would expect the GCS on mission planner to show zeros and a level orientation

  • The same happens for position, I try to start with some altitude, it does not reflect in Mission Planner or anywhere else except for SimState under MAVLink inspector.

  • I can see that when I arm, the aircraft is trying to stabilize (I think), because if I command some throttle I can see the output of the roll/pitch channels changing above/below 1500, but I have not connected it yet to the simulator.

It seems as if I am missing some setting somewhere? Any help would be greatly appreciated!

Thanks in advance

2

Try with AHRS_EKF_TYPE = 10.

By default the EKF is run on the incoming data from the sim. This means that all your data must be physically consistent. If you just update the attitude but not the acceleration vector, for example, the EKF ends up somewhere in between. For real sensors in the real world this is important. For the SITL you can just tell it to use the attitude directly from the backed with AHRS_EKF_TYPE = 10.

I should probably add a note to the readme…

3

@iampete that makes sense. I completely forgot that the EKF is actually expecting “gravity” as the IMU acceleration. Therefore, when using AHRS_EKF_TYPE = 2 (what I originally had), I am now always sending the gravity vector even for a non-moving vehicle (the actual sim will send this too) and it works for EKF type 2 just fine. I also tried type 10 as you suggested and that also works right away - so that is great to know too. My intention however, is to have it run as real as possible so a non-type 10 is really what I am after I guess. In any event, it is working now after your explanation on the EKF requirements. I knew it had to be something silly… thanks @iampete

What about the position? I seems that if I try to send an initial position with an altitude other than 0 it also ignores it, but if I disconnect the sim and restart it again (with SITL still running) sometimes it will update the altitude to what I send (relative).

Do you happen to know what should be the rate at which the SIM and the autopilot should be exchanging messages? I know there is mention about frame_rate in the wiki, but I am not sure how this applies in practice as the wiki says that the SIM can ignore this value. Currently, the received autopilot messages show frame_rate at 1200Hz (not sure if this values is even good enough - seems high). I have noticed that SITL behaves differently depending on how fast I exchange these messages through the JSON interface. If I go too fast the MAVProxy console and Mission Planner GCS will freeze and get bogged down to the point that when I send a MAVProxy command it does not show up on the GCS until 5-10 seconds later. In fact, the MAVProxy console will show the number of received packets under Link1 increasing very fast when using the JSON interface and freezing every 5 sec. Under this circumstances I can get several thousand packets in just a few secs, but freezing often. When I run SITL normally, without JSON interface, I notice that the packets increment about 100 packets every second or so. I am still trying to gauge the right values on this to make it smooth… Thanks @iampete!

4

The altitude you see in the HUD is altitude relative to ground, AP assumes ground is where it was first switched on. If you find the absolute altitude reading I think it should work. I have not tested tho. The issue here is that you send a position in meters that AP then converts in a latitude, longitude and altitude. To do the conversion AP assusmes it know were you were to start with. You should be able to change this with the -l command in SITL.

This depends on your physics sim, you will have to pick some time step that is small enough to accurately resolve the physics. In most cases 400hz is a good pick, this is a slow as you can go and still be faster the default loop rate on copter. The value sent back in the JSON backend is just a convenient way to link up with the AP param so it works just as it does with standard SITL. There is a handy line you can comment in for getting a better idea of how AP is keeping up.

5

Thanks @iampete! Where does that line print out to? Logger? MAVProxy Console? Cygwin terminal? I don’t see it anywhere that’s why I ask. Also do you happen to know where can I get a hold of the AP Logger generated files?

6

You should see a new window open when you start AP (as well as MAVProxy) , it will print there. If your not seeing it you need to install xterm to Cygwin. Log files are saved to ardupilot/logs.

7

@iampete this is strange. I have xterm installed. When I run AP in SITL I see:

  • map ( if I use --map)
  • MAVProxy UI (the small UI showing the messages and state of aircraft)
  • MAVProxy command line terminal (same terminal you get when you run Mavproxy.exe)
  • cygwin terminal (which I use to start SITL)

I do:
…/Tools/autotest/sim_vehicle.py -v ArduCopter -f JSON:127.0.0.1 --console --map

I do not see another terminal for xterm. I am sure xterm was installed and when it is not, the cygwin terminal will say that xterm is missing upon starting SITL. It does not say this. It only complains about osascript missing and also says at the end RiTW: Window access not found, logging to /tmp/ArduCopter.log. It used to also complain about gnome-terminal and konsole missing, but I installed those and the errors went away. I wonder what am I missing to not see the xterm terminal…

I have performed the SITL installation now over 12 times over a course of weeks and I have never seen another terminal for xterm. Could I, or the wiki, be missing something about this?

8

This its the window your looking to see. You will have to setup a x-server on windows. Of course you could also just look at the log file it gives instead. It should be posible to install all the things its complains about and run with no or very few warnings. If your on Windows 10 WSL is much more straight forward to setup.

9

@iampete that is what I thought! - I would be seeing it in ArduCopter.log anyways, but I am not seeing the printf statement from SIM_Aircraft.cpp that you suggested to uncomment. If I try to print anything on that method i does not show up on ArduCopter.log. It is seeing that I changed the code and rebuilding on upon SITL startup, but no printouts. All I am doing is starting SITL and the external sim interface. I can see them sending data back and forth, but no printouts from SIM_Aircraft.cpp on ArduCopter.log.

Also, it is quite strange because if I try to send data at over 50Hz to the AP, the MAVProxy console, terminal and Mission Planner struggle a lot. For example, at 100Hz, if I try to send a flight mode change through MAVProxy terminal it takes about 5-10sec to show up on Mission Planner and MAV proxy Console. So even without the prinout not working it seems that the AP or some components in there is struggling to keep up, buffering too many packets that take effect late. It is only usable if I drop the rate to under 50Hz, but the flight controller is running at 400Hz. Have you ever seen this behavior? Sorry to be a PITA, but I am trying to understand it correctly so that I can interface with it properly…

10

Need to see how the frame rate is doing, you can see the window in this vid, it tells you how well the physics is keeping up with AP.