|
|
|
|
|
by rikeanimer
1210 days ago
|
|
Did no one notice the balls? Those are there so a set of external cameras [think motion capture] can feed in an absolute, essentially perfect state estimate to the control algorithm. It's probably a run of the mill system from Vicon [company]. Essentially if you're running vicon you can make flying things do things like you could make them do programming them in Blender or similar, subject to the [pretty minimal to the human eye] time constants of the mechanical systems. Brushless speed controllers are pretty fast, servos are as well [but way slower]. The end-to-end control loops we are talking about are in the ballpark of 1khz easy and have been for quite some years. If they had balls they'd take off the balls ;) Other than that it is essentially CGI in real life ;) Sorry don't mean to be negative it looks cool guys. Now go make it actually cool. I ain't got no darn PhD in control theory from some fancy skool er nuthin but my gut tells me for this situation it's the state estimation that actually composes the beavers tail under the wattuh of dis dat der prollem. |
|
It is not quite that easy though. Yes having an external tracker will give you a reliable, high quality source of position and orientation.
But that does not mean that you can “program them in Blender”. You still need to figure out what kind of trajectories your system can or can’t follow and how to map from position and orientation errors to actuation outputs.
If you can’t control the robot with external tracking then you have no hope of controlling it with internal state estimation, so if you already have the test facilities it makes sense to start with that. That way you are not debuging two crappy subsystems depending on each other and failing spectacularly.