Servers by jDrones

Morse 3D simulator with ArduPilot

simulator

(rmackay9) #1

Over the past few days @tridge has added support for the Morse robotics simulator which uses the Blender game engine to produce high quality 3D renderings of the environment. It also supports many different sensors including 360 lidar so this will be a good testing environment for work on object avoidance.

For developers interested in giving it a try, the setup instructions are here. So far it works only on Linux/Ubuntu environments. If you run into troubles feel free to reach out to us in the ArduPilot Gitter chat.

The simulator has been tested with Copters and Rovers but it is likely that more vehicles will be added in the future (submarines perhaps?).


(Fi156) #2

In addition to that:
Its fairly easy to load your own terrain data into Blender.
Have a look at “BlenderGIS”:


(tridge) #3

Interesting! Would you be able to do some docs on how to use that with ArduPilot?
For example, having the CMAC SITL location as data we can load would be great. Or a real village.
Cheers, Tridge


(Stephen) #4

I’ve managed to get Morse running natively in Windows. Required a few patches though (see https://github.com/stephendade/morse/tree/winfix). Full details for the build are in the “winbuild.bat” file in the repo - it’s a bit tricky requiring the exact same python version in Blender and the user’s system.

Besides the patches, I’ve noticed that Morse doesn’t appear to be sending proximity sensor data to Ardupilot and the camera controls are a bit … wild.


(tridge) #5

great, well done!

are you planning to PR those to the morse project?

try “telnet localhost 60000” and see if the proximity sensor data is showing up there
Cheers, Tridge


(Stephen) #6

Yep, doing that now :slight_smile:

Yeah, it’s coming through on there


(tridge) #7

ok, then could either be parameter settings for proximity sensor, or parsing in SIM_Morse.cpp
See this code for parsing:


maybe add some printf() calls to debug that, or step through it with gdb


(Stephen) #8

So I’ve setup Morse on Ubuntu too, with the same (non-avoidance) behaviour as I saw on Windows. So could be something with the rover_scanner.parm file?

For reference, here’s the mission I’ve been running - it runs quite nicely into a tree at the moment! dodge1.txt (495 Bytes)


(tridge) #9

do you know that copter and rover don’t do avoidance in AUTO mode at the moment? That is waiting on us integration our mission avoidance code from OBC2018


(Stephen) #10

The rover documentation appears to say otherwise: http://ardupilot.org/rover/docs/rover-object-avoidance.html:


(rmackay9) #11

Stephen,
Actually the issue is that Rover does “dodge” but only using forward facing lidar. It cannot use proximity sensors for dodge. I’ll update the docs and/or allow proximity to be used.


(Stephen) #12

It might be worth mentioning in the documentation that only some sensors can be used for dodge. The way I understood before was that any ranged sensor(s) could be used for avoidance.


(tridge) #13

we should also add a fwd looking lidars to the Morse simulation


(rmackay9) #14

@stephendade, I’ve added a warning in the rover object avoidance wiki page to specify that “dodge” avoidance only works with 1D lidar.

I spent quite a bit of time yesterday trying to make dodge work with the proximity sensors. I suspect I got it working as well as it does with regular lidar but it still doesn’t work well. The real solution is to have an AC_Avoid::adjust_waypoint that shifts the target around so that the vehicle avoids obstacles. This is pretty much what Tridge & Co’s OBC avoidance library does.