Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High-Level Commander Design #293

Closed
whoenig opened this issue Feb 6, 2018 · 7 comments
Closed

High-Level Commander Design #293

whoenig opened this issue Feb 6, 2018 · 7 comments
Milestone

Comments

@whoenig
Copy link
Contributor

whoenig commented Feb 6, 2018

This issue is to discuss the design of a high-level commander (@jpreiss , @mgreiff , @mikehamer).

Goal

The current commander allows for different high-frequency setpoints, such as attitude control, velocity control, or trajectory control. A high-level mode would allow to set high-level goals, while the low-level setpoints are generated on-board. Such a mode can, for example, include:

  • Takeoff
  • Landing
  • GoTo waypoint (where a smooth trajectory is planned on-board)
  • Execute Trajectory (that might be built into the firmware, uploaded on demand, or stored on an SD-card)

Challenges

  • The current generic commander can only switch between low-level/high-frequency setpoints. A different layer is needed for high-level commanders.
  • A backup pilot should be able to take over control at any point

Proposed Design

  1. A new task for the high-level commander will be created. The task handles new CRTP commands using a new CRTP port. Commands can include takeoff, landing, etc. New commands can be added, similar to the current crtp_commander_generic. The task also provides a function to fill-in the current setpoint.
  2. The logic of commanderGetSetpoint will be changed such that the high-level setpoint is returned if a) no low-level command was received for a specific time, and b) the high-level commander is enabled (a parameter and perhaps a compile-time flag). Check a) will allow backup pilots to take control. Also, once a low-level commander packet was received we should disable the high-level mode, until it gets explicitly enabled again (by setting a parameter).

We can discuss the actual CRTP packets later; the first step is to agree on how to integrate such a on-board setpoint generator properly. We already successfully use such a high-level commander for the Crazyswarm.

@jpreiss
Copy link
Contributor

jpreiss commented Feb 6, 2018

The interface of the Crazyswarm high-level commander on the firmware side is summarized in planner.h. The PC side is close to a 1:1 wrapper.

The manual backup is the main component missing from our implementation, I think.

krichardsson referenced this issue in bitcraze/crazyflie-lib-python Feb 9, 2018
Using velocity control for take off and landing to avoid problems if the crazyflies are not on the correct starting points
@ataffanel
Copy link
Member

ataffanel commented Feb 9, 2018

Hi, thanks for starting a ticket about that!

  1. Sounds good. I guess there also needs to be a 'fifo' mechanism to be able to send the next commands. Do you see that as a generic FIFO memory that holds raw packets and feed them to the decoding functions at regular interval?

  2. The current low-level setpoint implementation has a 'priority' argument. The idea behind this argument was to be able to have multiple source for setpoint and automatically switch to the highest priority source. If the high priority setpoint has not been received for a while (0.5s currently), a lower priority setpoint can be used instead. If the high-level commander is set with a priority lower than the low level crtp_generic_commander setpoint, it seems to me that the existing design fulfills you point a), for b) a parameter or the high-level commander packet can be used to enable the high-level commander.

@whoenig
Copy link
Contributor Author

whoenig commented Feb 18, 2018

  1. So far we have not used any buffer. Instead, the client can send a new command any time to start execute it. For complex maneuvers, trajectories can be uploaded and executed.

  2. I saw the priority argument. However, I want to avoid that the high-level commander generates low-level setpoints at a fixed rate: this will be less accurate in terms of latency and will make it much more complicated to run the control loop at a higher or lower frequency. Instead of letting the high-level commander actively push data, I want the stabilizer to query the setpoint whenever needed. In particular, the stabilizer calls commanderGetSetpoint periodically. In case the high-level setpoint is enabled (and no low-level setpoint is available), we compute the current setpoint (which in case of trajectories means evaluating a polynomial function).

Edit: An example implementation is available here.

whoenig added a commit to USC-ACTLab/crazyflie-firmware that referenced this issue Mar 7, 2018
The initial high-level commander supports takeoff, landing, stop, and goTo. Each CF can be part of one of 8 groups, and commands can be broadcasted for specific groups, only.
Tested in a mocap system with kalman estimator and mellinger controller using crazyflie_ros (high-level-setpoints branch; test_high_level.py).
ataffanel added a commit that referenced this issue Mar 16, 2018
@ataffanel
Copy link
Member

ataffanel commented Mar 23, 2018

Thanks for the PR @whoenig!

My understanding is that with the code already merged is that we have to send the commands when needed. How do you upload and execute a series of command, is there a separate module implemented for that?

@jpreiss
Copy link
Contributor

jpreiss commented Mar 24, 2018

@ataffanel in the Crazyswarm architecture, we have the python script that sends commands to the crazyflie-ros server. The commander messages are implemented as ROS services (aka remote procedure calls) that return immediately, even if the commanded action takes a long time. The script sleep()s for the appropriate amount of time before issuing another command. (it would be easy to write a wrapper library that does the correct sleep for you.)

Since we work with multi-robot teams, we have never wanted to upload any complex sequence because we need all the robots to stay coordinated. If we were to upload sequences, we would still need a mode where we can tell all the robots to advance to the next command at the same time, to ensure synchronization. Given this requirement, it is not any easier than just sending the commands at the right time.

However, I can see how a command queue would be useful for other kinds of research, or for operation without a PC.

whoenig added a commit to USC-ACTLab/crazyflie-firmware that referenced this issue Mar 25, 2018
This adds the possibility to upload polynomial trajectories using the existing memory interface.
Trajectories can be executed with the high-level commander.
Tested with crazyflie_ros (test_high_level.py).
See issue bitcraze#293.
@whoenig
Copy link
Contributor Author

whoenig commented Mar 25, 2018

Just a few more comments:

@whoenig
Copy link
Contributor Author

whoenig commented Apr 7, 2018

Another update on the current status:

@krichardsson krichardsson added this to the next-version milestone Oct 17, 2018
cafeciaojoe pushed a commit to cafeciaojoe/crazyflie-firmware that referenced this issue Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants