33 replies to this topic

[Scott]

Perhaps a generic module is useful to report a sensor value back to the GCS where it can be observed or some ground-side code can do something useful with it. Down-side is that the GCS currently uses the field names from UAVObjects as the text label inside generic widgets.This means the labels would be "Sensor 1", "Sensor 2", "Sensor 3", "Sensor 4" and not very descriptive or intuitive.

This could be solved by adding custom labels to the generic widget options in the GCS (dials, bargraghs, etc.). Otherwise, we could write custom UAVObjects that contain specific sensor names. eg. PitotAirspeed, UltrasonicHeight. A Settings UAVObject could be used to set the conversion factor to translate the voltage into real measurement units.

In the case of the GasEngine module that needs to add the cold junction temperature to the hot thermocouple temperature I don't see an easier way (right now) than to use a custom flight module and custom UAVObject.

[Kenn Sebesta]

Scott, on 02 November 2011 - 07:31 PM, said:

Perhaps a generic module is useful to report a sensor value back to the GCS where it can be observed or some ground-side code can do something useful with it. Down-side is that the GCS currently uses the field names from UAVObjects as the text label inside generic widgets.This means the labels would be "Sensor 1", "Sensor 2", "Sensor 3", "Sensor 4" and not very descriptive or intuitive.

This could be solved by adding custom labels to the generic widget options in the GCS (dials, bargraghs, etc.). Otherwise, we could write custom UAVObjects that contain specific sensor names. eg. PitotAirspeed, UltrasonicHeight. A Settings UAVObject could be used to set the conversion factor to translate the voltage into real measurement units.

In the case of the GasEngine module that needs to add the cold junction temperature to the hot thermocouple temperature I don't see an easier way (right now) than to use a custom flight module and custom UAVObject.

Both those approaches seem complementary. Custom names and UAVObjects make a lot of sense for integrating sensor measurements into flight dynamics. That way, it doesn't matter where the data comes from, i.e. analog sensors, digital sensors, etc...

Then there are sensor readings that one might want on the ground, for non-flight related tasks.

[A*Morale]

Not sure if this can interests you: I've found this nice paper from allegro: http://www.allegromi...vider/index.asp

Basically it is a simple idea as just spliting the current in two paths, one going to ACS and  the other through a shunt.trace.
This mean that you can use a very cheap and tiny ACS712 hall current meter ic for current gauge for more than the 30A in specs. As a side effect you don't have any ground coupling problem given how hall sensors works.

Edited by A*Morale, 22 November 2011 - 11:23 AM.

[Scott]

Just commited a V2 version of the mcp3424 branch to the repository. Re-factored the code. Now includes a generic module for the mcp3424 device and another module customised for gas engine sensors that uses both the mcp3424 and the mcp9804 devices - all on the I2C bus.

Both modules are set up to be optional - same as GPS and CameraStab.

The I2C address must be specified in the related settings fields via the UAVObject browser. Tested on CC flexiport. Very handy for keeping an eye on the main battery voltage. Just make sure the A2D gain is set to "1" so the AD input is not saturated.

[Kenn Sebesta]

Doh! I was just in the middle of changing your code to do something similar. I was starting to abstract your code even a little further, with the goal of getting it into the OP main branch. I'm worried it will otherwise languish for lack of renown. Perhaps since you're actively working on it, you might be in a better situation to do it?

Basically, I would like to have UAVObjects that control a generic I2C protocol, one where the goal is to get I2C sensor data and beam it back via telemetry. Nothing else, no interpretation of the data or anything. It just gets it and sends it home. The idea is that an I2C sensor almost certainly follows the below scheme

• Initialize
  
• wait
  
• Configure
  
• wait
  
• Write register value
  
• wait
  
• Read register value
  
• run clock several times in order to clock in all the bytes of data
  
• wait
  
• Go to 5

Which hex values you have to use are arbitrary, but the wait cycles and whatnot are, in my experience, very minor variations on the above theme.

What do you think?

[Reddog]

I have been following this thread with interest but not quite understanding how this works. Are you guys able to put up instructions for an idiot to connect his DragonLink current sensor or other peripheral device (if those current sensors work) to CC please?

[Kenn Sebesta]

Reddog, on 23 November 2011 - 12:13 AM, said:

I have been following this thread with interest but not quite understanding how this works. Are you guys able to put up instructions for an idiot to connect his DragonLink current sensor or other peripheral device (if those current sensors work) to CC please?

^^^
| | |
| | |
THIS

Thanks Reddog, the timing couldn't have been more perfect.

P.S. Scott, are you aware of the fact that your branches won't compile due to a missing watchdogstatus.xml? I don't know why it's missing, but I think it must have happened by accident. Try running a make all_clean and then recompiling and you'll see what I mean. I think you've imported the compiled uavobject from a make in another branch. I fixed it by simply adding the file back in, but I wanted to make you aware, and also to ensure that you didn't have some reason I wasn't seeing for removing watchdogstatus.xml.

[Scott]

@Kenn
Hmm... thanks for testing so quickly. I'll have to add that watchdogstatus file back in. Don't know how I manage to keep dropping files from my git branches. Something to do with the merging process probably. This time I did a rebase with Next to bring it up to date before checking in.

With respect to the generic I2C sensor interface, I suppose your scheme could work but for many sensors there is probably some likelihood that the sensor value will be used onboard the aircraft. eg. GPS, sonar, exhaust gas temp, to name a few. If this is the case then the conversion to real values should happen on the aircraft.

An alternative to a generic scheme would be to build up a library of I2C sensors as optional modules. The code is very similar so writing the code is not difficult at all.

I'm curious what the I2C sensors are that the members here can foresee adding?

Putting this into the next branch would be great. What is the best process for that?

[Kenn Sebesta]

Scott, on 23 November 2011 - 01:06 AM, said:

@Kenn
Hmm... thanks for testing so quickly. I'll have to add that watchdogstatus file back in. Don't know how I manage to keep dropping files from my git branches. Something to do with the merging process probably. This time I did a rebase with Next to bring it up to date before checking in.

I think you might be having more trouble than you realize with git file branches. Try

git diff next >> i2c.diff

from the mcp3424_V2 branch. When you open i2c.diff, you'll see that there's a load of files that have been added to your branch that likely shouldn't be there. Things like eclipse crash logs, etc...

Quote

With respect to the generic I2C sensor interface, I suppose your scheme could work but for many sensors there is probably some likelihood that the sensor value will be used onboard the aircraft. eg. GPS, sonar, exhaust gas temp, to name a few. If this is the case then the conversion to real values should happen on the aircraft.

You're absolutely right about the need to use some values onboard. I would suggest that we get a patch for generic I2C into next, and then we can have our own individual branches which will slightly modify onboard code for our needs. This has several advantages, one of which is that if the I2C starts moving with next/master there's little chance that upgrade paths will become burdensome because there will be fewer differences between the branch and next/master.

Quote

An alternative to a generic scheme would be to build up a library of I2C sensors as optional modules. The code is very similar so writing the code is not difficult at all.

I think it's very important that the user not have to recompile or download branches in order to use these modules. It should be something that can be explained in a simple text file, for which we could indeed have several configuration files for commonly used I2C sensors. Otherwise, the average user will simply feel overwhelmed by the process.

Quote

I'm curious what the I2C sensors are that the members here can foresee adding?

Pollution, light, radiation, temperature, pressure, humidity, RF signals, comms, etc... The ability to field flying sensors is the reason that UAVs are taking off today. We've had R/C planes for 50 years, but it's only now that they could do something useful.

Quote

Putting this into the next branch would be great. What is the best process for that?

First I think you'll have to figure out what needs to be cleaned up in the git merge. Sorry to be the bearer of bad tidings, but perhaps there's a very quick way with git to see which files are added to your branch vs. next, and then you could clearly see log files and things like that that don't belong.

Secondly, in order to be in next, the dev team has to be convinced that this is something that will have a wide user base. Thus my idea to stream i2c sensor data back to ground, without having specific interpretations. That way any user can use an i2c sensor without having a specific processor need, which fulfills peabody124's requirement that the OP code base not be clogged up with modules that are so specific they will only be used by one or two people.

Lastly, once this is done you can submit your code for review. Peabody124 is already favorable to the scheme that I mentioned in this thread, so if the code is well done the review process should be painless.

If you can clean up the git files problem, I can clone your new branch and start working on the suggested path. I think you understand module building a lot better than I do, so you can perhaps monitor my changes and help with testing, esp. since I don't have the sensor you're using here to test against.

[Scott]

Thanks for that git diff tip! I'll go through my git branch tonight and see what I can do to clean it up.

FYI, I added a page to the wiki a while back that explains the module building process. I actually refer back to it myself when I forget one of the 10 different parts of the process.

http://wiki.openpilo...opment tutorial

[Kenn Sebesta]

Scott, on 23 November 2011 - 01:06 AM, said:

With respect to the generic I2C sensor interface, I suppose your scheme could work but for many sensors there is probably some likelihood that the sensor value will be used onboard the aircraft. eg. GPS, sonar, exhaust gas temp, to name a few. If this is the case then the conversion to real values should happen on the aircraft.

I should also mention that the OpenPilot Revolution (as the OpenPilot Pro is called in the latest revision) supports PyMite scripting, so the big deal is to get the data in to the system. After that, there really won't be a need to have specific code modifications in order to act on the data.

[Kenn Sebesta]

Scott, on 23 November 2011 - 02:25 AM, said:

FYI, I added a page to the wiki a while back that explains the module building process. I actually refer back to it myself when I forget one of the 10 different parts of the process.

http://wiki.openpilo...opment+tutorial

Oh, hej, thanks for that tutorial. That really makes modules a lot easier to understand.

[Scott]

"scott/mcp3424_V3" pushed to git. I started from next and cherry-picked all the files so this should be a clean, single commit at the head of next. Let me know how it looks. Seems to build and work correctly on the CC.

[Kenn Sebesta]

Scott, on 23 November 2011 - 03:53 AM, said:

"scott/mcp3424_V3" pushed to git. I started from next and cherry-picked all the files so this should be a clean, single commit at the head of next. Let me know how it looks. Seems to build and work correctly on the CC.

Great! I'll take a look at it at home tonight.

In the meantime, I didn't want to hijack your thread anymore, so I started a new one to discuss the generic sensor reading module: http://forums.openpi...reading-module/

My biggest problem is how to get memory usage down.