Driving omni vehicles

1

I wonder if I should write my own controller or extend the currently available controller modules.
I’m trying to set up a USV (Unmanned Sufrace Vehicle) with OmniX frame in PX4.

I was able to set it up in Gazebo, only to find out that available controllers don’t work well, or behave in strange ways. This is what I found out:

rover_pos_control – is able to drive differential drivers like the RoboX model with two motors. It behaves like a fixed-wing aircraft in the way it takes turns. Maybe because it extends fw controllers.

uuv_att_control & uuv_pos_control – I’m not sure if I’m doing something wrong with my setup. Maybe some sort of regression was introduced with the new dynamic mixing system? They do not support all flight modes and I found simulating them troublesome.

What I want to achieve is functionality similar to what ArduRover supports. Which should be possible with recent developments with the new dynamic mixing system. I have seen the omnicopter demo, which shows that driving a 6DOF frame is possible. 6DOF is even defined in airframe reference. As I understand, my case would drop 2 degrees and I would end up with a 4DOF Omni-directional frame.

I also won’t hide the fact, that this is motivated by the RoboBoat competition that will take place in two months. We have settled on the OmniX design, but ArduPilot SITL happened to be in a strange place when it comes to ROS Ubuntu and Gazebo version compatibility.

1 Like
2

I have started picking apart this problem. Starting from attitude controller. Here are some requirements that I thought may be useful:

  • Must control FCU through vehicle_thrust_setpoint and vehicle_torque_setpoint
  • Must read desired heading from vehicle_attitude_setpoint (or attitude_triplepoint???)
  • Must expose PID parameters for in-water testing (as with every other controller)
  • Must be controllable through MANUAL, gamepad
    • At least in UUV I see this implemented as direct control bypassing PID
  • Should expose command for setting heading
    • Something along “look in this direction” available through QGC
  • May expose command to lock heading to compass
    • As omnidirectional craft is not constrained by the need of turning it would be nice to take advantage of that.
  • May expose command to lock heading to the global position.
    • Ex. use case: inspecting an object by going around it.

Also, my slow attempts are available here: Comparing PX4:main...not7cd:usv-control · PX4/PX4-Autopilot · GitHub

Not much implemented yet. Just got this module running in SITL. I would be happy if you could pick apart these requirements, as I may not know everything about PX4. One thing I know is to really split those controllers by pos and att. I could use the rover position controller if it wouldn’t be so tightly coupled.

3

@not7cd Most of the infrastructure is available with control allocation: PX4 SITL Omnicopter flying mission mode - YouTube

You just need to modify the position/velocity controllers to command 3d thrust setpoints

4

Control allocation works quite well. It looks like the attitude controller was quite simple to modify based on uuv_att_control.
For the position controller, I’m looking at PositionControl in mc_pos_control. Maybe I could reuse a lot of math here, and get rid of take-off logic?

For the record, I started draft PR:

5

We have created an Engineering Model with the desired motor configuration. Real-life tests showed behaviors not present in SITL. I’m unsure if this is related to the usv_att_control that I’m writing, a bug in PX4/QGC, or misconfiguration.

Joystick control configuration

When using a joystick with Full down stick is zero throttle I’m unable to arm, because of the “high throttle” error. If I change it to Center stick is zero throttle, then I’m unable to arm, but immediately the drone starts to put half of the throttle on all motors!. This is a no-go, we can’t go on the water with such a problem.

When manual control is lost switches mode to “Return”

When the joystick becomes disconnected for any reason, it switches to “Land/Return” mode putting a full-throttle on the motors. This is unacceptable, I would prefer for it to become disarmed, as there is no reason for it to land. It should.

I will report more after Monday. As we have arranged the model pool.

image
image1920×1440 136 KB

1 Like
6

Hey btw I came across this post and was teminded of this post u made!

7

Together with @JakubWilk we are beginning to develop a controller from scratch.

Over the year we have tested control allocation and it works well for this use case.

This issue has been removed at some point in the main.