The Combine Forum banner

1041 - 1060 of 4139 Posts

·
Registered
Joined
·
788 Posts
imu

Hi Brian! This is the code for imubrick v2 i will get the next few days.
For using in c# only a .dll is needed.

could you help me to place the code in your system? the object/class thing still overrules my programming skills. :11:

UID = "XXYYZZ" is the adress of the brick - this could be in settings

thank you very much!



Code:
using System;
using Tinkerforge;

class Example
{
    private static string HOST = "localhost";
    private static int PORT = 4223;
    private static string UID = "XXYYZZ"; // Change XXYYZZ to the UID of your IMU Brick 2.0

    // Callback function for quaternion callback
    static void OrientCB(BrickIMUV2 sender, short heading, short roll, short pitch)
    {
        string s = "heading: {0:F02}, roll: {1:F02}, pitch: {2:F02}";
        string f = String.Format(s, heading, roll, pitch);
        Console.WriteLine(f);
    }

    static void Main()
    {
        IPConnection ipcon = new IPConnection(); // Create IP connection
        BrickIMUV2 imu = new BrickIMUV2(UID, ipcon); // Create device object

        ipcon.Connect(HOST, PORT); // Connect to brickd
                                   // Don't use device before ipcon is connected

        // Register quaternion callback to function QuaternionCB
        imu.OrientationCallback += OrientCB;

        // Set period for quaternion callback to 0.1s (100ms)
        imu.SetOrientationPeriod(100);

        Console.WriteLine("Press enter to exit");
        Console.ReadLine();
        ipcon.Disconnect();
    }
}
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,042 (Edited)
that would be a really big job :(

I think before a line of code is written, make sure the thing works in a moving vehicle. On a desk in front of the monitor everything works, but after a couple hours of bouncing around and moving fast, does it lose its way needs to be determined.

Going thru their API, i notice a Convergence(time) function that set the degrees/sec the gyro uses to bleed down drift. Not sure if they are using their own fusion software or the one in the BNO055. although if it is set to zero, gyro drift is not compensated for.
 

·
Registered
Joined
·
788 Posts

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,044
wonder why Brick doesn't drift? Wonder why the Adafruit does.

You may be best to write a completely separate winforms app and learn the API setting events (which they call callbacks - obviously C++ programmers lol).

A good learning exercise!

Would be pretty cool to have a plug in USB solution to the IMU thing - ich habe eine bestellt von Deutschland!
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,046 (Edited)
? c++ there are are examples in c#
C# use events, C++ uses the term callbacks. They are very much the same.

I've put up a new version on Dev. It has a built in simulator, that even works with autosteer. If you attach the GPS to the serial port, it shuts it off.

I know, its about frickin time!!!! Should have done it long ago.

Edit: i should add, it now has full antialiasing of lines, points, and polygons. Smoooooooth.
 

·
Registered
Joined
·
21 Posts

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,048 (Edited)
Caution..... Lots of whining and complaining ahead!

Believe me when i say, it just doesn't look complicated........ Also, it has to run on the arduino. Unless someone posts a working EKF with heading and GPS - and it actually works perfectly in a moving tractor on rough ground - i'm not going there any time soon. Its a frustrating and complex problem!

The complimentary filter used in AOG seems to work very well. The EKF will "fix" the motion of the tractor when it shouldn't when it bounces over uneven land. The complimentary filter uses the strength of minimal drift of the imu heading and speed of it and only corrects drift if going in a perfectly straight line. It also seems immune to magnetic interference as the IMU can put right beside the steer motor and it still goes straight. And a tractor and air seeder are a whole lot of interference.

I think Andreas can attest based on his experience too, this is a super complex problem with huge engineering tradeoffs. Here is an industrial AHRS, and expensive - brand new. Even so the claim is still 1% error on heading and drift of 0.5 degree per minute. Auto steer goes off line very quickly even at 0.1 degree. So what are we left to fuse? A drifty inaccurate heading with a wiggly GPS heading because the antenna moves sideways from tractor wheels going over bumps. Also, it needs that info in 200 msec minimum, not an longer term average as typical robots in ROS do - they aren't using it for cm level guidance, rather in meters. Its a very very complex problem.

But if someone will do it up and works - that would be awesome.

http://www.hillcrestlabs.com/products/fsm300

The 10 bit A/D converter in the Arduino with a steering sensor is limited to around 15 kmh control and heading accuracies of 0.1 degree. we need at least 0,02 degree resolution to go any faster, i'm afraid the days of the UNO or Nano will be numbered on this project.

Put new version on github this morning.Sim remembers where it left off, and can be turned off in options.

Perhaps a post on how AOG does heading correction with an IMU would be of benefit.
 

·
Registered
Joined
·
788 Posts
i also stop the working on imu. like brian it´s to complicated. so much problems so different types of breakout boards of 9250.
the calibration thing is the major goal to have success - but its a really big process if you will do it perfect. so i will wait for my imu brick v2 which i did use in the past with cerea and will do some tests.

look here: :) Advanced hard and soft iron magnetometer calibration for dummies - DIY Drones


steering angle:

maybe this has a better resolution:(could be easy connected to imu)

https://www.tinkerforge.com/en/doc/Hardware/Bricklets/Analog_In_V2.html
or better
https://www.tinkerforge.com/en/doc/Hardware/Bricklets/Industrial_Dual_Analog_In.html


my next thing is to have a stable and solid steer angle sensor (pics for my john deere)
sometimes i use my tractor in the forest....
 

Attachments

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,052
Brian you are working hard!

When I set the tool widht less than 12 meters, you turn dont execute well
Any idea?
Yes, you have to change some things.

Push the "Autosteer config" button and that brings up settings for autosteer (the one with chart etc)

change the "max Steer angle" to like 40

change the "Safe turn" to about 3.0

Those settings are default quite low so you can't turn very fast or sharp initially. Safe turn limits the rotational velocity based on speed and steer angle. Steerangle max just limits the steering angle of the wheels.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,053
M,N right left and J,K slow down speed up. Key control for Sim. Groundwork for editable choices for Functions in Youturn. Code cleanup.

Up on the nightly AgOpenGPS_Dev Github
 

·
Registered
Joined
·
1,393 Posts
I don't have much to offer at this point, but just thinking out loud. If arduino is going to start being a limiting factor would it be worth while just running everything through windows and a breakout board of some sort? Less hardware=more reliable?
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,055
I think we are pretty much there Beer. All the arduino has to do is read and set steering motor/valves based on the steer angle its given, and read the imu. Even the rate stuff is all done in aog. If the USB Brick v2 imu works out, even that will be read directly by aog.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #1,057
would this system be adaptable to tile plowing ??
all you need is rough direction, no imu needed, and depth ??

and some how to enter wanted depth and choice of degree drop ?
I would think position and altitude would be all that is needed.

Old buggy operators never needed any GPS lol
 

·
Registered
Joined
·
788 Posts
finally i did test imu brick v2! looks very good with agopengps.

my only code changes in ag was:

i commet out in serial com:
//int.TryParse(words[2], out mc.gyroHeading);
//int.TryParse(words[3], out mc.rollRaw);

Code:
 //rate object
            rc = new CRate(this);

            seq = new CSequence(this);

            sim = new CSim(this);
             void OrientCB(BrickIMUV2 sender, short heading, short roll, short pitch)
            {

               // string s = "heading: {0:F02}, roll: {1:F02}, pitch: {2:F02}";
              //  string f = String.Format(s, heading / 16, roll / 16, pitch / 16);
                mc.gyroHeading = heading;
                mc.rollRaw = roll;
               // Console.WriteLine(f);
            }

            IPConnection ipcon = new IPConnection(); // Create IP connection
            BrickIMUV2 imu = new BrickIMUV2(UID, ipcon); // Create device object

            ipcon.Connect(HOST, PORT); // Connect to brickd
                                       // Don't use device before ipcon is connected

            // Register quaternion callback to function QuaternionCB
            imu.OrientationCallback += OrientCB;

            // Set period for quaternion callback to 0.1s (100ms)
            imu.SetOrientationPeriod(100);
            
            //start the stopwatch
            swFrame.Start();
 

·
Registered
Joined
·
4,065 Posts
i -think- rtk would be neccesary though, to allow for the +/- 1 cm distance on the tile ??
a radio modem perhaps ??
My understanding is that with any GPS system the altitude error is double that of position error. That is to say, if you used John Deere SF1 with it's 0.5 metre accuracy, the altitude would be at best within 1m. But that's accuracy, not precision. Meaning that if you go out at a random time and measure altitude in a particular spot, it will vary by up to a metre.

But for most things we care far more about precision than accuracy[1]. I don't care what the reading is from day to day, provided that over the course of a period of time, my reading doesn't drift very much (precision). So it may in fact work fine with a decently-corrected signal, such as Deere's SF1 or SF2, without needing RTK. But certainly RTK would be much better, especially with repeat-ability day to day, if you're working on a larger project.

Now back before the days of GPS, lasers were common (I have one of those). Laser-controlled hydraulics would be one way to go too, not necessarily tied into AOG.

[1] think of accuracy as how close I can get back to the same spot, and precision as measuring the distance between where I am now and where I was a moment ago.
 
1041 - 1060 of 4139 Posts
Top