Three Piksis on same network, for position+orientation ?

[Charles Fox]

Hi all,

We would like to mount two Piksis on a vehicle as well as run one at a base station, so that we can estimate orientation as well as RTK positions.

Does anyone know if it's possible to do this and if so how?    Would they all connect to the same 433 frequency and select the same set of satellites on all three, or is there some other system ?

What would happen if we wanted to have say 10 Piksis running together in this way to estimate relative locations and angles of many parts of vehicles ?

Charles

[José Antonio Vázquez Espinosa]

I read on the wiki that it is possible but you should change the communication frame of the system because the provided one only support point to point and you'll need a point to multipoint one. I´m aeronautical engineer so I could not help you with this topic. The FAQ says:

"Can one base station service multiple rovers?

Currently, one base can provide corrections to multiple receivers provided you communicate with the rovers and read position and velocity information from each rover. The radio modems provided with the RTK kit do not support point to multipoint broadcast in their current form, so another inter-device communication method should be used."

By the way, my mean task on my job is to design a system that allow to know the degree of freedom that you mentioned. I used some kalman filter performing AHRS and INS algorithms to estimate them. Depending on the vehicle that you may use you'll get a better measure about the attitude, for example: 

In my test with Piksi I saw an altitude 2DRMS of 3cm so in worst case using both piksi you'll have 2*3=6cm of error. Using a car with the 2 piksi separate 2m in a configuration that gives observability about the pitch angle, the error in degrees will be [ atand(2*3/ 200) = 3.4336º ]. The observability configuration means the alignment of the "Piksis" line with the body frame ("giving observability about the pitch angle" means that the piksi line is aligned with the x-axis). Ideally a 45 degrees with x and y  will give you the same resolution in roll and pitch angles, but in general is hard to have a long distance this way. 

You should think about that before trying anything, is this enough for your application? In my case, an UAV it isn´t if we try to perform automatics take off and landing.

I'm interested in this application with 2 Piksi to have a new feeder for my kalman filters, so if it is possible, I'll appreciate getting updated from you

Best regards. 

[Clive Turvey]

I think the term you're looking for is Attitude Determination.

On bulldozer applications you can have two left and right of the blade, on cars front and back. On planes and boats, there are applications with 3 or 4. There is generally a rigid understanding of the baselines between the antennas and this is used to contain/constrain the solution space. On a 4-up arrangement a 1-metre separation is sufficient, and limits the solution space to 5 carrier cycles. I don't think the Piksi has explicit support for these applications, but it has been discussed here before.

Ten on a single vehicle would seem excessive, unless you expect some physical deformation to change the geometry.

In a three-up Piksi arrangement you'd look to have one as a Base with a radio link transmitting observations to a Remote-Primary, the Remote-Primary would send it's observations via a direct wired connection to a Remote-Secondary UartA-TX (Primary) to UartA-RX (Secondary). The Secondary unit would be able to provide a NED or XYZ vector with respect to the Primary, and the Primary would provide a LLH position with respect to the base, and then you can infer position of other points on the vechicle through it's inherent geometry. You could send the UartA-TX (Primary) to multiple other Piksi as required.

A single Base can send it's observation to multiple Remote-Primaries, you'd want to enforce a one-way transmission (Base to Remote) so you don't clutter the band, and the Base has no need to do the Symmetrical RTK mode the Piksi's demonstrate. The computation load is at the Remote/Rover, it is solving for both sets of measurements.

[Charles Fox]

Thanks for these replies.   There' actually two applications we're looking at here, one is determining orientation of a single robot with two rtk's onboard;   the second is operating a swarm of robots in the same area, each with either one or two rtk's.    We do a lot of turning on the spot and tight u-turns which means that satnav-like orientation from motion is not so good.

So looks like this is possible but not with the radios then?   Can we run the comms over wifi somehow ?    I've not got into alternative comms yet but will try to find info in the docs on this then.

charles

[Clive Turvey]

The radios are capable of a one-to-many scenario, what you want to do is prevent the Rovers from jamming up the channel with noise. The symmetrical RTK used to demo the Piksi's really isn't how most RTK application work. The base really has no need/benefit from knowing where each of a dozen rovers are. You might want to know where they are, but that's separate from the RTK architecture.

What RTK needs is Base Broadcasts, Rover(s) Listen. You can suppress the Rovers squawking by zeroing out the UARTA SBP mask.  

A lot of UAV applications have a compass for orientation. For things that turn tight circles, or on top of themselves, place the antenna well off-centre.

You can run the comms over whatever type of link you want, the packets are agnostic to the transport method. The packet sizes are kept below 256 bytes to accommodate the buffer sizes on the Si1000 radios, and similar short range radios. You could probably do it with ESP8266 Serial-to-Wifi, or GainSpan, Digi or RedPines equivalents.

The Si1000 radios are half-duplex, there are some multi-point firmwares. I've had multiple units with the default firmware listen to data on the channel, but I've not done any exhaustive testing.

[Mark Fine]

Hi Charles,

You can run comms over networking with the experimental feature announced on the list in December:

https://groups.google.com/d/msg/swiftnav-discuss/lhmb7gMR53w/KR6m6rQhCAAJ

​

In a configuration with a base station and multiple rovers, the base station would leave the "Hide observations from other receivers" box unchecked, while the rover stations would check the "Hide observations from other receivers" box - this will enable the rover stations to find the base station's observations. The underlying functionality to connect over networking is also available programmatically. Hope this helps!

Mark

--
You received this message because you are subscribed to the Google Groups "swiftnav-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftnav-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jd22...@dal.ca]

Since the base station is sending correction data to the rovers. Should you not UNCHECK the "Hide Observations from other receivers" on the rovers, and CHECK the "Hide Observations from other receivers" on the base station. OR are the "Observations" and the 'correction data' separate things..?