15 replies to this topic

[peabody124]

So the gyro/mag/accel data goes into an object called attitudeRaw.

While I'm working on revo I'd like to rename this to something intuitive.  (Sensors?)  

Also the grouping is a bit weird.  The baro is a separate object and then the mag/gyro/accel are clumped together.  I could separate all of them into independent UAVOs but this is less memory efficient for CC.

Alternatively we could make a mega sensor object which contains mag+baro+gyro+accel.

Thoughts?

[peabody124]

As I think about it more, I'm tempted to replace the old "Altitude" module with a "Sensor" module for revo, and the attitude module can switch in various attitude algos.

Along this line I'm tempted to separate all the sensors into individual UAVO.  This will allow the attitude module to simply connect a queue to the appropriate object and get all the missed updates.  CopterControl will take a small memory hit but probably worth it for revo code cleanliness.

[K Wells]

I like separate UAVO sensors, even with the memory hit on the CC board....It would be a benefit to testers and ultimately end-users, when troubleshooting and initial configurations

[dankers]

Makes a lot of sense for sure. We will also Sonar and Pitot pressure sensors also, plus who knows what people will add, good call.

[D-Lite]

peabody124, on 12 December 2011 - 05:28 AM, said:

So the gyro/mag/accel data goes into an object called attitudeRaw. While I'm working on revo I'd like to rename this to something intuitive. (Sensors?)

I think the term "raw" isn't appropriate also because the data already has offsets and (in the case of gyros) drift compensation applied. Another thing: the bias values for CC are stored in the attitudesettings object while the AHRS uses ahrscalibration for this. Maybe it would make sense to unify this in the future for CC/Revo?
The wording "sensors" seems to be  a good one. About the questions if it's better to have independant objects instead of one big object containing all sensors, I would vote for independant objects. This makes it more flexible e.g. for tuning the telemetry link and make better use of the available bandwidth by enabling only those sensors updates that are of interest instead of having to decide between "all or nothing".

[jes1111]

On a tangent to this thread:

How would this proposed change relate to your intention to review/rearrange the code/logic in the Actuator module? It seems to me that it was designed on the assumption that all output would be PWM and subsequent additions to the code have rendered it somewhat clumsy. It updates the ActuatorCommand object and then effects the channel outputs itself (kinda like having a dog and doing all the barking yourself). Would it be more appropriate to rename the Actuator module to "Mixer", or somesuch, and then have a module for each actuator type, listening for ActuatorCommand updates?

Incidentally, there also seems to be an implicit assumption that actuators have a one-to-one relationship with "axes", whereas (in my own application) I need a one-to-many, e.g. the gimbal roll axis may have two servos driving it, each of which may have different end- and neutral- points.

(Hoping my ramblings make sense )

EDIT: Oops! Sorry, ignore this - I was going off half-cocked before I'd even read the other thread

[Kenn Sebesta]

peabody124, on 12 December 2011 - 05:28 AM, said:

While I'm working on revo I'd like to rename this to something intuitive.  (Sensors?)  

Typically, in the controls domain we'd call those "measurements" or "outputs". The second is perhaps too confusing, but the first might be worth considering. The argument for "measurements" could be that it would also provide room for "sensors", where "measurements" are things that affect the state estimation and "sensors" are things that don't, e.g. radiation, pollution, light, acoustics, etc...

My concern is the same as D-Lite's: there are going to be more and more sensors added and it would be good to be able to individually control which sensor gets sent over telemetry. However, I don't really have a firm mastery of how much less efficient this would be, and whether CC can handle it.

[K Wells]

My comments and thoughts were primarily regarding the New Revolution board.....realizing the CC board memory issue.....and the commonality


Possible other terms:

FoR (Field of Reference), SoS (Scope of Sensor), SS (Sensor Span)......just a few I thought of  

[Crubier]

AttitudeRaw is indeed a bad name, which confused me at first as I said it here.

As a newcomer here is my "fresh" opinion about this problem :
- A good thing would be to break "attituderaw" into different UAVObjects called "accel" "gyro" "mag", which could be used in conjunction with "baroaltitude" and other future measurements... (as said peabody and K Wells)
- In the case of grouping of all these objects into a big UAVObject, "measurements" seems to be the best name. "motionmeasurements" and other variations can be nice too. (as said Kenn)
- Use of "Raw" in the name is confusing, because these aren't actually Raw measurements, and (almost) no one wants the exact raw measurements anyway. (as said D-Lite)
- To comply with the common use of that word in the domain of UAVS and Aerospace, "sensors" should be reserved for Payload sensors, i.e. sensors that are not used for flight control. (as said Kenn)
- It would be great to have a module which would take all measurements as input, perform any kind of "sensor fusion" algorithm based on available measurements, and output estimated position, attitude, speed in a sensor-independent way. I would call this module "Motion Estimation" (basically the idea of peabody)

To conclude, I'd like to say that having a good architecture and a clear code is more important than optimizing memory footprint for a specific platform.
I believe that, in the end, having a good architecture allows to make a more efficient use of the hardware resources, even if doesn't seem to be the case at first.
That's why the memory of the CC should be taken into account, but shouldn't be the central driver of coding efforts.

That was only my personal opinion

Edited by Crubier, 13 December 2011 - 02:13 PM.

[peabody124]

Yeah I've basically refactored it just like that for Revo already.  I haven't backported yet to CC yet so I'm not 100% it will fit but it should and only burn 100 bytes or so.

[RoyLB]

It makes sense to me to have a Sensor Fusion or Motion Estimation module that provides the best available state estimation to the rest of the code (based on available sensors and you favorite algorithm)

How much memory overhead does a UAVObject take (over and above the actual sensor data words themselves)?

- Roy

[peabody124]

IIRC it's ~100 bytes which is a lot but it comes because of all the meta information and such and linked list headers.

[jes1111]

Would "transducers" be a suitable parent name for the "sensors" group? I agree "sensors" should be reserved for payload devices.

[RoyLB]

peabody124, on 13 December 2011 - 05:26 PM, said:

IIRC it's ~100 bytes which is a lot but it comes because of all the meta information and such and linked list headers.

Wow! Does this mean, for example,  that if we wanted individual access to each of the three roll rate sensors that it would require 300 bytes?

[peabody124]

If you wanted to use three separate objects for roll, pitch and yaw gyro, then yes.  I don't know why you'd do that though.  I've swapped Revo over to using a Gyros, Accels, Magnetometer object and it works fine.  I'll backport this to CopterControl later.

[Brian Gou]

It is a bad name, co's it confuses me, too.