The following warning may be important.
PreArm: Motors: Check frame class and type
The following warning may be important.
PreArm: Motors: Check frame class and type
Hi John,
Just so I can get a baseline, did you manage to run the truck-quadplane-landing.sh
example as is, or is that not working for you either. It’s been a while since I’ve reviewed this, but have just checked the script and it’s running with the latest plugins etc (I’m now using Gazebo Harmonic, but that should not be a factor in whether the example works or not).
I’ll try to replicate your proposed example next.
Hi Rhys,
I ran the truck-quadplane-runway.sh example. Then I compared model.sdf file to model.sdf.erb to identify the process needed to create .erb from .sdf. Then I applied the process to the iris quadcopter. Also tried to switch from plane to copter. One thing I didn’t do is create a config.param file for iris.
Rhys, the goal is to model two cameras mounted on a gremsy t3 v3 gimbal, on a quad copter.
I used gazebo garden.
My guess is either somewhere I’m still using plane instead copter or I need the config.param file for iris to specify the frame class and type.
John
Hi John,
Ok - that’s good as it means the system’s working (just saw the discord post as well).
I’ll see if I can get the example you want up and running and maybe add a PR with the extra scripts needed. So it’s two iris quads with gimbal on the truck trailer. I think the landing script is quadplane only - but that’s not the immediate problem, we’ll start with getting all the vehicles present and visible in mavproxy and take it from there.
Fantastic. But it’s two cameras on one vehicle, 3 axis gimbal. The cameras have lens with different focal lengths. But, I will fly two UAV at once to reduce clock time required. So you can implement two iris on the back of the truck. Later this has to be implemented on a harbour tug, instead of a truck at an airport, in rough seas.
Hi John,
Ok - got it working (mostly). Need to update the launch script to set the copter defaults. Sub in this for the last section.
#--------------------------------------------------------------------
# Copter 1
COPTER1_NAME=iris
mkdir -p sitl/$COPTER1_NAME
COPTER_DEFAULTS="$ROOTDIR/Tools/autotest/default_params/gazebo-iris.parm"
# additional parameter file for the iris
cat <<EOF > sitl/$COPTER1_NAME/follower.param
SYSID_THISMAV 3
FOLL_ENABLE 1
FOLL_OFS_X -5
FOLL_OFS_Y 0
FOLL_OFS_Z 10
FOLL_OFS_TYPE 1
FOLL_SYSID 2
FOLL_DIST_MAX 1000
FOLL_YAW_BEHAVE 2
FOLL_ALT_TYPE 1
EOF
(cd sitl/$COPTER1_NAME && $COPTER -S --model JSON --home=$HOMELAT,$HOMELONG,$HOMEALT,0 --speedup 1 --instance 2 --defaults $COPTER_DEFAULTS,follower.param) &
wait
There’s an issue with the orientation - some of the models (including the truck) had the wrong mapping from Gazebo ENU to ArduPilot NED. If all the models are consistent you don’t notice until using a compass or navsat sensor. It looks like the iris and runway (which have been fixed in ardupilot_gazebo) are inconsistent with the truck. The model pose needs a 90 deg z rotation, and the transform pose in the ArduPilotPlugin needs an extra z-rotation by 90 deg as well. This is why the copter is zooming off to the east in the map when the truck goes north. In Gazebo the iris is on the trailer.
Update:
Oh - that will be easy to set up. We can add another camera sensor to the gimbal on the iris with gimbal model.
That we can do also. We have a nice wave simulation - if you have a CAD model for the boat I can set something up. I put together a model for a large research vessel for tridge when investigating the quadplane, the physics didn’t scale quite right for that vessel (70+m), but something intermediate may behave better.
Wow, impressive response! Thank you.
I have ship motion data, can that be used in the simulation. I would just scale the existing tugboat model. Put the tugboat in waves and let me control the amplitude of the waves. And let the tugboat be driven by data in a file.
Could do, or we can use the wave simulation I developed where you can specify the wave amplitude via a parameter (and control wave direction relative to the wind). The boat motion is governed by non-linear hydrostatic restoring physics, so it’s fairly realistic. The advantage then is that you can command a mission for the boat and the boat motion takes care of itself.
Updated in the branch given above:
The following params enable the gimbal with direct RC control
MNT1_TYPE 1.000000 0.000000 # Servo (DEFAULT: None)
SERVO5_MIN 1000.000000 1100.000000
SERVO5_MAX 2000.000000 1900.000000
SERVO5_FUNCTION 8.000000 0.000000 # Mount1Roll (DEFAULT: Disabled)
SERVO6_MIN 1000.000000 1100.000000
SERVO6_MAX 2000.000000 1900.000000
SERVO6_FUNCTION 7.000000 0.000000 # Mount1Pitch (DEFAULT: Disabled)
SERVO7_MIN 1000.000000 1100.000000
SERVO7_MAX 2000.000000 1900.000000
SERVO7_FUNCTION 6.000000 0.000000 # Mount1Yaw (DEFAULT: Disabled)
RC6_OPTION 212.000000 0.000000 # Mount1 Roll (DEFAULT: Do Nothing)
RC7_OPTION 213.000000 0.000000 # Mount1 Pitch (DEFAULT: Do Nothing)
RC8_OPTION 214.000000 39.000000 # Mount1 Yaw (DEFAULT: PrecLoiter Enable)
Config details:
Update
You may also be interested in: Add camera zoom plugin by srmainwaring · Pull Request #57 · ArduPilot/ardupilot_gazebo · GitHub which just merged and provides a zoom capability to the simulated camera.
@rhys Now I can’t run simulation. The block
<include>
<uri>model://gimbal_small_3d</uri>
<name>gimbal</name>
<pose degrees="true">0 -0.01 0.070 90 0 90</pose>
</include>
generates error
[Err] [Server.cc:159] Error Code 14: [/sdf/world[@name=“truck_quad_landing”]/model[@name=“quad”]/include[1]/uri:/home/john/ardupilot/sitl/worlds/truck_quad_iris_landing.sdf:L1469]: Msg: Unable to find uri[model://gimbal_small_3d]
path is
/home/john/simulation/SITL_Models/Gazebo/models/gimbal_small_3d
Tried fixing with
export GAZEBO_MODEL_PATH=/home/john/simulation/SITL_Models/Gazebo/models
@rhys Never mind, wrong version of gazebo.
This path command works
export GZ_SIM_RESOURCE_PATH=$GZ_SIM_RESOURCE_PATH:/home/john/simulation/SITL_Models/Gazebo/models
To add models and worlds to the resource path in Gazebo Garden use:
export GZ_SIM_RESOURCE_PATH=$GZ_SIM_RESOURCE_PATH:/home/john/simulation/SITL_Models/Gazebo/models
GAZEBO_MODEL_PATH
is for Gazebo 11 and earlier.
Beat me to it!
Too funny, lets just say great minds think alike
@rhys I just go from one error to the next.
Now qGroundControl doesn’t connect
and mavyproxy gives the following error
$ cd ~/simulation && ./SITL_Models/Gazebo/launch/mavproxy-multi-vehicle.sh 3
Connect tcp:127.0.0.1:5760 source_system=255
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
Failed to connect to tcp:127.0.0.1:5760 : [Errno 111] Connection refused
Can we do a screen share?
@rhys, never mind again. I just killed it all and tried it again, and it worked. But, circle mode crashes.
@jvorwald - sorry missed the screen share - was late in my location (UK). In future, if you are on Discord you can find me in the simulation and ros channels and the screen share / video conf setup there works well.
Not sure why CIRCLE mode would be failing? By crash do you mean the simulation crashes, or does the vehicle crash? (if the later you may need to manually set rc 3 1500
).