Torque passthrough/feed-forward

#1

Hello!

I have been using the ROSflight firmware for about a month now, and really enjoy the minimalism of the plattform. I was hoping to use ROSflight for some class projects, because I want to be able to do these projects in hardware using a minimal setup. So far I have written a few simple outer-loop controllers as individual ROS nodes publishing on the /command topic, which works great.

However, now I am planning on implementing an MPC controller setup, where the controller would be directly calculating the input torques. This means that I will not be needing the attitude controller in ROSflight, and I was hoping that I could just do a passthrough of the desired torques to the rotors. I do however still want to keep all the functionality with hardware setup, communication, RC setup, trimming etc. that comes with ROSflight, which is why I want to still use ROSflight, despite not using the actual attitude controller that comes with it.

My question is this: Will the MODE_PASS_THROUGH pass the x, y and z inputs directly through to the system as torques, or is this mode only ment for fixed-wing actuator control? Or would I need to modify the ROSflight Firmware to achieve what I am looking for?

And also: does my plan sound reasonable to you, or would you go with another software than ROSflight for something like this?

Thank you for help!

Best,
Bernhard

#2

Hi @bernhardpg, glad to hear ROSflight has been helpful!

Yes, MODE_PASS_THROUGH will be treated as torque inputs for multirotors. Some things to keep in mind:

  • These are “normalized torques,” for lack of a better term, between -1 and 1. They represent the fraction of the total possible thrust differential to create about each axis. Be sure to limit them to this range in your code or our saturation algorithm might do weird things
  • The RC trim values get added to the torque commands you send, if you’ve set them

I think that plan sounds reasonable; this was a use case we had in mind as we were developing the firmware. I’m not aware of other software that would be easier for that application, although there’s plenty I’m not aware of.

My primary concern I’d think about if you proceed would be latency. Since you’re operating at the torque level, where the dynamics are very fast, any delay in the control setpoints could become problematic. I’ve not tried this myself so I don’t know if would become an issue or not, but it’s probably worth keeping in mind and doing what you can to minimize delays.

Hope that helps, and best of luck!

1 Like
#3

I know of other projects that have done what you’re proposing, and it has worked well for them!

I would second Dan’s advice, but have a few more pointers:

1 - Latency on the USB/VCP is going to be lower than over a UART connection
2 - We only update our ESCs at 490Hz. (So if you’re able to compute control commands faster than that, it will be wasted)
3 - We “timeout” communication with the onboard computer by default at 100ms. (This is configurable using the OFFBOARD_TIMEOUT parameter). If you’re unable to produce commands faster than 10Hz, you’ll definitely want to change this.

Good luck! MPC is the coolest, and I’d be super excited to see your system in action/read your approach if you’re going to publish it!

#4

Thank you for your responses, I very much appreciate it!

It sounds to me like ‘MODE_PASS_THROUGH’ is the way to go, then. I want the RC trim values to get added to the torques, so that is perfect. I will keep what you said regarding the latencies and update frequencies in mind.

Regarding the ‘normalized’ torques (and the thrust value ‘F’ which is between 0-1): Where is the maximum motor thrust and the maximum normalized torque defined/calculated? I tried to look at the source code and the ROS parameters, but I could not find it. Is this something that is determined by hardware, or is it set by the user through the rosflight_io userface?

Also, on a whole other note: Does ROSflight currently support connecting a GPS to the FC? I have seen multiple parameters and source code files hinting that this is the case, but I have not been able to find anything in the docs on this. I also found some github issues suggesting that this is not yet fully supported, which made me a bit unsure.

Thank your for your help!
Best,
Bernhard

#5

Hi @bernhardpg,

So we never define the actual values for torque and thrust, we just use throttle values. So the maximum thrust is just whatever you get at full throttle, and the maximum torque is just what you get if you throttle the motors on one side all the way up, and the motors on the other side all the way down. If you need thrust and torque values in actual SI units, you’d need to obtain them by testing your motor/prop combo.

Support for GPS is coming soon (we’re currently reviewing the pull requests that should complete the support). We’ll be supporting recent ublox modules. We don’t use the GPS data in the flight controller, it’s mostly just a pass through. The one thing we will do is publish a message that includes the GPS time and the microcontroller time since boot, to help with more accurate time stamping of other data.

#6

Hey @bernhardpg

Re normalized torques:

I did the inversion from normalized inputs to forces/torques in my dissertation: link (page 54)

and I collected the force and torque data with one of these

If you’re using the rosflight_sim package to simulate your system before putting it on hardware, and you have computed these parameters, you can plug them in the simulation

here https://github.com/rosflight/rosflight/blob/ebc29c455be18fa4e6d648ec4a232ceb9531ff2f/rosflight_sim/params/multirotor.yaml#L24
and here https://github.com/rosflight/rosflight/blob/ebc29c455be18fa4e6d648ec4a232ceb9531ff2f/rosflight_sim/xacro/multirotor.urdf.xacro#L18

#7

@dpkoch I see, when I think about it it makes sense that the actuators are implemented that way. Regarding the GPS: So far I have been using an individual ROS node connecting to my Ublox GPS over uart from the RPi, and then reformatting and publishing the data to the desired channel (i.e. for ROScopter). It will be nice when it is supported natively by the FC, even if it’s just a simple pass through!

@superjax Thanks for the tip, I appreciate it. I will look into it and let you know if I run into any problems!

#8

@superjax okay, so I am still running into some problems with this.

Currently, I am working purely in simulation, without modifying the default multicopter simulation model.

I have designed a controller which calculate the desired input torques, and have been passing them to the rosflight attitude controller using the feedthrough mode, scaling the thrust and torques by what I calculated to be the maximum thrust and torque values.

I calculated the max thrust like this: rotor_max_thrust * 4, and max torque like this: rotor_max_thrust * 2 * arm_length. I found rotor_max_thrust here. For arm_length I used the euclidean norm of the rows in rotor_position.

I am not sure if this would be the right way to go about doing this. What do you think?

#9

I’m so sorry @bernhardpg. For some reason my email notifications stopped coming through!

That looks right to me, what was the problem you observed?

#10

Don’t worry about it, @superjax!

My controller design worked well when simulating the equations of motion of the quadrotor. However, I could not make it work in the rosflight simulation, and figured that my calculations of max thrust might be the problem. If those were right, I may have to incorporate the first-order dynamics of the motors in my simulations too, to see if maybe this is the problem.

I am currently taking a break from this project, but I will let you know when I continue working on this. Thanks for being willing to help out!

Bernhard

#11

Dear all,

I was also curious about how rosflight could help to implement attitude controllers for multirotors, and this thread was of much help, thanks.

I have been visiting the code and I am still not sure how the mode “MODE_PASS_THROUGH” would command forces and torques. If i am not wrong , after resolving the mixing (which does not contain any geometric info nor propeller model), the outputs of the controller are the pwm sent to the controller to control the individual velocity.

However, in the simple case of wanting half of the total max available thrust, will this mode command exactly this or the thrust equivalent to half of the maximum velocity?

Best regards,

#12

Hello Bernhard,

Our lab worked on a very similar project last summer which involved a MPC controller for our quadcopter. Our code was recently published on github. We created ROS topics to publish and subscribe to the torque commands you are referring to. This code is also available on our github page. Let me know if that is useful.

#13

Great, I will check it out. Thanks for helping out!