Gravity Offload System for Microgravity Testing of Deployable Spacecraft

I am a fresh university graduate and was recently hired at an aerospace company that designs and tests a lot of deployable structures. They have developed an active gravity offload system for testing deployments to simulate microgravity (search AIAA GOLF Cart). The system was developed by people much smarter than I, but it still has issues, and I think Odrive could be the solution to many of them. For example, the stepper motors used are slow and the offload force is a custom built constant force spring (with no z-travel).

Since I’ve been tasked with leading the support for this effort, I want to replace both the components I mentioned with BLDC motors and perhaps add a third axis as well. Replacing the stepper would help with speed and accuracy, and replacing the spring would allow for easily programmable vertical force and z-axis motion. Unfortunately, I’m a structural engineer and have a long way to go to get up to speed on mechatronics. But! I just got my first Odrive and motors and everything seems to be running great so far.

If I can actually get my vision implemented, there will be many more ODrives to come (I could easily see 40-60 units on some of the largest structures that we’ll be potentially testing in the future). I have seen many projects similar to what I’m trying to accomplish, so there’s definitely hope. Here’s a visual of the current concept:

Each unit in the Odrive version will have a raspberry pi, a camera, two BLDC motors and an Odrive (or 2 ODrives if V4.0 is single board as I read somewhere).

My first question: I think the current units use grbl as a gcode interpreter for motion/location control. I’m trying to understand if this would even be necessary in an odrive version (I don’t think it’s entirely necessary in the stepper version to be honest). If I have a target location that I found by using a camera, I imagine with some fancy code I could just use the position control system in the odrive directly to get there, yes? (with some math to equate pixels to encoder steps of course).

Anyway, sorry for the super long post, I’m just trying to wrap my head around what is possible with the odrive.

Thanks

Yes of course, if you update the input position e.g. from some computer vision system, ODrive will follow it as quickly and as closely as it can.
Best of luck with your interesting project! :smiley:

1 Like

Yep, what Towen said. We also have a “Trapezoidal Planner” that can take acceleration and speed limits and interpolates between its current position and the target position. That may be sufficient for your application, as long as you are commanding from stop to stop. grbl and other motion planners have more derivatives so are less likely to excite frequencies in the system, but steppers do that themselves anyway…

One thing to keep in mind - these motors like to run faster than steppers. They tend to be somewhat difficult to control at very low speeds (< 50rpm or so). If you want smooth behavior in that range, stick reduction ratios on them (gearbox etc).

1 Like

Wonderful. I’m excited to get it going. Thank you both for the info and useful advice.