Add Stick_Mixing to Rover?

[Chris Anderson]

Rover team, 

Daniel Nugent and I are adding computer-vision lane following to an ArduRover (running Navio2 on RasperrryPi 3) and we're trying to decide how best to use the output of the CV routines to help steer the rover using Dronekit. 

What seems to make the most sense to us is to pipe the CV corrections (augmenting the GPS) into Rover via the RC_Override commands in Dronekit. But as far as we can tell, this won't work because you can't "nudge" the vehicle in Auto the way you can in Plane because Stick_Mixing has not been implemented in Rover. 

How to you all feel about adding Stick_Mixing to Rover? It would make this sort of higher-level sensor integration a lot easier. 

-Chris

--

◤CHRIS ANDERSON

    CEO 

    3D Robotics

    website | twitter | facebook | instagram

[Randy Mackay]

Chris, Dan,

 

     I’m not the owner of Rover and if this is for AVC and avoiding barrels, I suspect that the stick mixing approach is the quickest way to get what you want.  Still, in general I think we recommend against using rc-overrides where possible.  Also I’m personally against mixing autopilot + pilot controls whenever possible because I think adds confusion as to who is in control.  … I think it could be better to enhance Guided mode into Rover so that it supports mavlink commands (like SET_ATTITUDE_TARGET or SET_GLOBAL_POSITION_INT) which more directly relate to the controls that the companion computer is happy to send.

 

     If you mostly want to get around the track in Auto mode, but want to have the companion computer assist just for short periods of time, there are ways to do that of course (with a bit of effort).  For example, the companion computer could switch the vehicle into Guided mode if it sees and obstacle and then return the vehicle to auto afterwards (it should continue the mission from where it left off) or you could get very fancy and add support for the NAV_GUIDED_ENABLE mission command (like we have in copter) which allows handing over control to a companion computer for just a certain period of time or distance during a mission.  This is how I setup the red-balloon-popper.

 

     Here’s one final option – how about making a new range finder driver that is actually vision based?  Rover already supports some object avoidance using sonar – the main code doesn’t need to know if it’s actually coming from a range finder or a camera.

 

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Nugent]

Randy,

Thanks for the input. I agree that RC overrides aren't ideal but ardurover doesn't have as many mavlink hook-ins as copter which makes things a bit difficult.

If modificatiom to ardurover is required I think extending the functionality of guided mode is probably a good way to go. Something lower level than GPS. Similar to velocity control on copter but applicable to rover. Absolute XY velocity control might work. Forward velocity control with desired heading could also work. Not sure what makes the most sense with the current mavlink messages and navigation controller. I'll have to read up on the specifications of the messages you suggested.

Daniel

[David Mathias]

For work we're doing with path planning, an improved guided mode in rover would be fantastic.  We have it working in copter.  When we decided to try moving it to rover, we were surprised to find that support for some kind of velocity control is absent.  Has there been any progress?

David

[Randy Mackay]

 

     There’s a plan to add support for controlling the heading and/or yaw-rate and speed which is close.  I don’t think we’ve decided on which messages to use but it could be set-attitude-target but I guess we could use set-position-target-local-ned or set-position-target-global-int which would pretty much be the velocity controller.  The only question is whether we’d support a global frame (i.e. where vy is north?) or just a local frame (i.e. vy is forward).

-Randy

--

[David Mathias]

I think we could work with any of the options you mentioned, Randy. Thanks, that's great news.

David